Madrid. — In a web crowded with trackers, breaches, and unsolicited mail, an email address is more than an identifier—it’s a breadcrumb trail. AnonAddy (addy.io) flips the script. Instead of handing your personal address to every site or service, you create disposable aliases that forward—and, if you wish, encrypt—messages to your real inbox. The project is open source and self-hostable, with its full codebase on GitHub and extensive docs that cover everything from basics to advanced setup.
The premise is simple and powerful: one alias per service. If a site leaks or sells your data, you simply deactivate or delete that alias. The rest of your digital life remains untouched. Behind the initiative is Will Browning, a UK developer and privacy/open-source advocate who uses the service daily and keeps the repository open to community contributions.
What AnonAddy is—and why it matters
AnonAddy acts as a gateway between senders and your real mailbox. It lets you:
- Protect your real address: hand out unique aliases and kill any that start receiving spam.
- Trace breaches: a distinct alias per service shows who leaked or sold your contact.
- Thwart cross-referencing of accounts after data breaches.
- Limit your email provider’s visibility: with GPG/OpenPGP, inbound mail stays encrypted until it reaches you.
- Reply from the alias without revealing your identity.
- Change your forwarding mailbox without updating hundreds of services—just modify it in AnonAddy.
Unlike closed alternatives, the project publishes its code. There are no ads, analytics, or third-party content, just basic server access logs. It ships browser extensions for Firefox and Chrome, official Android and iOS apps (by Stjin), and a Raycast extension—all open source.
Shared-domain vs. standard aliases: how the shield is built
AnonAddy distinguishes two main buckets:
- Shared-domain aliases use common domains (e.g.,
@anonaddy.me). These must be pre-generated (not created on the fly). Anyone can generate random character/word aliases at these shared domains. - Standard aliases can be created on the fly and live under your user subdomain (e.g.,
@johndoe.anonaddy.com), additional usernames, or a verified custom domain. This unlocks automations and catch-all behavior if you want it.
If you want even stronger compartmentalization, you can add extra usernames and segregate aliases by context (personal, work, hobbies). If you worry about a visible subdomain linking everything together, use random aliases on shared domains.
Using your own domain (and when not to)
Yes, you can. Verify ownership with a TXT record, point your MX to AnonAddy so it can handle inbound mail, and add a few extra records to enable sending from that domain.
One hard rule: don’t use the very same domain both as a custom domain and as a forwarding recipient inside AnonAddy—it creates loops. In that case, use a subdomain instead (e.g., mail.example.com) for aliases while keeping example.com with Proton, Gmail, etc. Email can’t be delivered to multiple mail servers simultaneously; the lowest-number MX (highest priority) wins.
Encryption, signatures, protected headers
You can upload a GPG/OpenPGP public key per recipient. From then on, all forwards are encrypted to that key. You can even hide and encrypt the subject using Protected Headers, which helps reduce spam/“phishing” false positives from providers that scan message content.
- Attachments: treated as part of the message and encrypted too.
- Signatures: when encryption is enabled, forwards are signed with
[email protected](fingerprint26A987650243B28802524E2F809FD0D502E2F695, available atkeys.openpgp.org). - Replying from aliases with encryption:
- If the recipient uses GPG/OpenPGP, encrypt to their public key.
- If not, you can encrypt to
[email protected]. The server decrypts and relays in clear to the final destination—useful to keep content hidden from your own provider.
- Metadata hygiene: AnonAddy strips attached public keys/signatures when you reply or send from an alias, preventing accidental leaks of your real address (often present in your key identity).
Replying (and sending) without exposing your real account
When a message is forwarded, AnonAddy adds a “coded” address in the From: header that arrives to you. Replying is as easy as hitting “Reply” in your client; the system translates and delivers to the original sender without exposing you. The dashboard shows reply/send counters so you can verify it worked.
You can also send from an alias without an existing thread by constructing the To: address as <alias+dest=domain@your_user_subdomain>. The web app helps: “Send from” builds the right address and, if you’ve enabled catch-all on a custom domain or subdomain, can create the alias on the fly.
Anti-spam, authentication, and safety banners
To curb abuse and spoofing, AnonAddy uses:
- Rspamd, DNSBLs (Spamhaus), SPF and DKIM checks;
- DMARC, to detect spoofing and reject failures;
- FQDN and valid PTR on senders.
If an inbound message fails DMARC, AnonAddy adds a red warning banner before forwarding; you can inspect X-AnonAddy-Authentication-Results headers to see why. To protect its MTAs, AnonAddy forbids marking forwarded mail as spam—if an alias is compromised, deactivate or delete it.
To reply from an alias, you must send from a verified recipient in your AnonAddy account (otherwise the mail “comes back” to you). If you see 550 5.1.1 Recipient address rejected, the alias doesn’t exist or was deleted. Another common cause: your verified recipient’s domain lacks DMARC. Fix: publish a DMARC policy (and ensure SPF/DKIM).
Limits, bandwidth, and plans
Reasonable guardrails keep the system healthy:
- Forwarding rate: 200 emails/hour per user.
- Alias creation: 10/hour (Free), 20/hour (Lite), 50/hour (Pro). Excess is deferred.
- Max email size: 25 MB (attachments included).
- Bandwidth: the size of each forwarded/replied email is counted and resets monthly. As a rough guide, an average email is ~75 KB; 10 MB allows ~140 emails, 100 MB (Lite) ~1.400. At 80 % you get a warning; beyond that, deliveries return
552 5.2.2 User over quotauntil the new cycle or an upgrade. - Recipients per alias: up to 10.
Multiple Free accounts or using aliases to mass-create accounts on other services is prohibited and can lead to deactivation.
Extensions, apps, and ecosystem
- Browser extension (Firefox and Chrome/Chromium: Brave, Vivaldi) to generate aliases on the fly.
- Open-source Android (Play Store, F-Droid) and iOS (App Store) apps by Stjin.
- Raycast extension by http.james for macOS workflows.
Where the servers are
AnonAddy reports its main server in Amsterdam, Netherlands with Greenhost (privacy-focused, powered by Dutch wind energy), and a backup in Warsaw, Poland with UpCloud. It participates in FBLs (feedback loops) to spot spam complaints and protect sender reputation.
Self-hosting: total control
If you “trust no one 100 %,” spin up your own instance. The repo documents requirements and deployment:
- Postfix 3.0+ (with
postfix-mysqlandpostfix-pcre) and TCP/25 open. - PHP 8.2+ with
mailparse,gnupg(for encryption),imagick(2FA QR codes); Nginx web server. - Redis 7.x+ (throttling/queues), MariaDB/MySQL; Rspamd for spam filtering.
- DNS: MX, SPF, DKIM, DMARC, plus reverse DNS.
- SSL/TLS (Let’s Encrypt).
- Proper FQDN (e.g.,
mail.yourdomain.tld).
Prefer containers? There’s a maintained Docker image. The project is licensed under AGPL-3.0 and includes 200+ PHPUnit tests. Self-hosting docs and images are linked in the README.
Governance, support, and continuity
Will Browning says the service will run long-term and has continuity plans (domains renewed >5 years out, designated operator, public notice if needed). Funding is user-driven; sponsorships now favor infrastructure partnerships (cloud, domains, hosting). The project thanks the community—including the mobile app authors—and invites bug reports, feature ideas, PRs, and doc improvements.
Common issues—quick fixes (from the FAQ)
- “I’m not receiving mail”: add
[email protected]and aliases to your address book, check spam; ensure the alias/domain/extra username is not disabled (disabled items silently drop mail). Verify sender passes SPF/DMARC, has reverse DNS and FQDN. Apple/Google may flag some mail: enable encryption, hide/encrypt subjects, or disable banners to reduce false positives. - “Reply keeps coming back to me”: you’re replying from an unverified address. Verify it in your AnonAddy account.
- “
550 5.1.1when sending from alias”: alias missing/deleted, or your verified recipient’s domain lacks DMARC. Publish DMARC (and ensure SPF/DKIM). - “I don’t want Stripe to see my real email”: you can use an alias for billing notifications.
A firewall against spam—and tracking
Day-to-day best practice boils down to three steps:
- One alias per site.
- Deactivate aliases that leak or misbehave.
- Encrypt so even your mailbox provider can’t scan contents.
The rest is sound engineering—SPF/DKIM/DMARC set correctly, a bit of operational hygiene, and a couple of clicks when something goes sideways.
FAQs (useful for families, freelancers, and IT teams)
How do I create disposable email aliases to protect privacy and block spam?
With AnonAddy, generate a unique alias for each site (under shared or custom domains). If it starts receiving spam, disable or delete it. You can reply from the alias without exposing your real address and enable GPG/OpenPGP to protect content and subjects.
How do I set up SPF, DKIM, and DMARC when using a custom domain with AnonAddy?
Verify your domain with TXT, point MX to AnonAddy, then publish SPF/DKIM/DMARC. DMARC is required so replies from aliases aren’t rejected by strict providers. If your root domain is already used elsewhere, attach a subdomain (e.g., mail.example.com) to AnonAddy.
What’s the difference between shared-domain and standard aliases?
Shared-domain aliases (@anonaddy.me, @anonaddy.com, etc.) are pre-generated and can’t be created on the fly. Standard aliases are created on demand under your user subdomain, extra usernames, or custom domains, support catch-all, and make replying/sending seamless.
How can I self-host AnonAddy and what are the technical requirements?
You’ll need Postfix 3.0+, PHP 8.2+ (mailparse, gnupg, imagick), Redis 7.x+, MariaDB/MySQL, Nginx, Rspamd, proper DNS (MX/SPF/DKIM/DMARC), reverse DNS, TLS, a valid FQDN, and TCP/25 open. Official Docker images and step-by-step self-hosting docs are in the GitHub repo.
Source: public repository and documentation of anonaddy/anonaddy (addy.io) on GitHub.
