SimpleLogin is an email aliasing service in the same category as addy.io – purpose-built for creating a fresh, disposable email address for every service a person signs up to, and routing the mail back to a real inbox. It is fully open-source under AGPL-3.0, self-hostable on a Docker host if the operator prefers to run their own infrastructure, and since 2022 has been owned and operated by Proton AG out of Switzerland.
The service occupies a specific niche within the wider forwarding category. Where ImprovMX and Forward Email are built for the “one domain, a handful of role addresses” case (admin@, support@, contact@ all landing in the operator’s real inbox), SimpleLogin is built for the “one unique alias per service” case. The mental model is different, and it affects everything else: how many aliases the tiers allow, whether the free tier supports custom domains, what “sending from an alias” means, and how the mail flow is designed to prevent the destination inbox from being linked back through the alias.
Where SimpleLogin fits in a WordPress stack
SimpleLogin handles inbound routing for custom domains and personal aliasing. For a WordPress operator, three uses are typical.
The first is per-vendor aliases for the sites and services the operator signs up to as part of running the business – the hosting control panel, the CDN dashboard, the plugin licence portals, the analytics tools. [email protected], [email protected], [email protected] each become a unique alias that forwards to the real inbox. If one of those vendors leaks or sells the list, the operator sees which alias got the spam and can shut it off without disturbing the others. This is aliasing’s original use case, and it works well for a solo operator or a small agency running a handful of client accounts.
The second is contact-form endpoints. Instead of hardcoding [email protected] into every client site, generate a unique alias per site and route them all through SimpleLogin. When a client relationship ends, the alias gets disabled without touching the client’s site or the operator’s inbox.
The third is the reverse – initiating email from an alias, so the reply to a vendor arrives at the alias rather than at the real inbox. This is where the Premium tier’s “reverse-alias” mechanism matters, and it’s covered separately below.
SimpleLogin is not a WordPress transactional relay. There is no SMTP endpoint for bulk sending, no per-domain reputation to manage, and no capacity for wp_mail() traffic. WordPress sites should use a dedicated sending service (Postmark, SMTP2GO, Mailgun) for transactional email, and treat SimpleLogin as the inbound-routing layer alongside it.
SimpleLogin is also not a mailbox provider. Mail arrives at SimpleLogin’s servers and forwards to whatever real inbox the alias points at – typically Gmail, Fastmail, Proton Mail, or Google Workspace. The alias itself has no stored mailbox, no IMAP access, no webmail. If the operator wants a real mailbox at [email protected] with IMAP and stored history, that comes from Fastmail, Google Workspace, Proton Mail, or Forward Email; SimpleLogin sits in front of it, not in place of it.
Pricing
The free tier is designed as a trial and a light-use option, not as a serious operator tier. It allows 10 aliases, one destination mailbox, and no custom domains – aliases must be on SimpleLogin’s own domains (@slmail.me, @simplelogin.com, and similar). This is enough to try the reverse-alias flow and see whether the mental model fits, but any real deployment on a custom domain requires the paid tier.
Premium is $4/month or $36/year and removes essentially every limit that matters: unlimited aliases, unlimited destination mailboxes, unlimited custom domains with catch-all and wildcard support, five subdomains for aliases like [email protected], and PGP encryption of forwarded mail using a key the operator uploads. The Premium tier also bundles Proton Pass Premium (vault sharing, 2FA authenticator, dark-web monitoring) – a real inclusion since the 2022 Proton acquisition rather than a marketing bullet, and worth noting for an operator who already uses or is evaluating Pass.
Multiple concurrent subscriptions receive a 30% discount (useful for agencies running SimpleLogin across a team), and the service accepts payment in Bitcoin and Monero in addition to standard credit-card and PayPal rails – the same anonymous-payment posture Proton offers on its other products.
Pricing verified against 
simplelogin.io/pricing on 2026-09-01.
DNS setup
Four record types cover a custom domain: MX for inbound routing, SPF and DKIM for authenticating the forwarded mail, and DMARC to declare policy. The exact values, taken from the SimpleLogin registrar guides:
| Record type | Host | Value | Priority |
|---|---|---|---|
| MX | @ |
mx1.simplelogin.co |
10 |
| MX | @ |
mx2.simplelogin.co |
20 |
| TXT (SPF) | @ |
v=spf1 include:simplelogin.co ~all |
– |
| CNAME (DKIM) | dkim._domainkey |
dkim._domainkey.simplelogin.co |
– |
| TXT (DMARC) | _dmarc |
v=DMARC1; p=quarantine; pct=100; adkim=s; aspf=s |
– |
The MX records take over the domain: any existing MX records for the same host must be removed first, or the domain will split-brain between the previous mail server and SimpleLogin. For a WordPress operator on a domain that has never had a mail server (typical for domains registered specifically for a site), the setup is additive and safe. For a domain that already handles mail through Google Workspace or Proton Mail, migrating to SimpleLogin means moving that mail off first – and at that point the operator should be sure they want SimpleLogin as the primary inbound path.
The DKIM setup is a single per-domain CNAME rather than a rotating key pair; SimpleLogin manages the private key on its side. The DMARC record uses strict alignment (adkim=s; aspf=s) with a quarantine policy – firm but not the outright reject that would leave no recovery path if authentication failed during propagation. Most operators can leave this exactly as documented; more aggressive DMARC configurations (p=reject) are appropriate later, after two or three weeks of quiet operation confirms nothing is being dropped.
If the domain already has an SPF record (common when a sending service like Postmark or SMTP2GO is already in use), add the SimpleLogin include: before the terminator: v=spf1 include:sendgrid.net include:simplelogin.co ~all. SPF permits up to 10 DNS lookups per RFC 7208; SimpleLogin’s include consumes one.
Reverse aliases: sending “from” an alias
The reverse-alias mechanism is what separates aliasing services from pure forwarding services, and it’s the mechanic to understand before committing to the model. The user-facing behaviour: reply to a forwarded message from the normal inbox, and the reply arrives at the original sender as if it came from the alias, not from the real inbox address.
How it works underneath: when SimpleLogin forwards [email protected] -> [email protected] -> the destination inbox, it rewrites the From: header to a per-contact reverse alias (something like [email protected]). When the operator hits reply, the message goes to that reverse alias. SimpleLogin’s server receives it, looks up which real alias and which contact the reverse alias corresponds to, then re-sends the message from the alias to the vendor. The vendor sees mail from [email protected] and has no visibility into the destination inbox.
This is fundamental to the aliasing threat model: the real inbox address is never exposed to services the operator interacts with through aliases. It also means the operator can revoke an alias at any point without needing to change or forward from a different address; the alias goes away and the vendor’s mail stops arriving.
The free tier supports reply-from-alias for existing conversations. The Premium tier adds initiate-from-alias for the case where the operator needs to start a new conversation from a specific alias (contacting the vendor to change plans, for instance).
Self-hosting
SimpleLogin is the only service in this category with first-class self-hosting support. The full server, browser extensions, mobile apps, and JS libraries are AGPL-3.0 on GitHub at 
simple-login/app, with a documented Ubuntu-plus-Docker deployment guide. An operator running their own instance handles Postfix, Nginx, PostgreSQL, DKIM key rotation, and the DNS setup for their alias domains directly – not a small commitment, but the option exists for operators who don’t want a third party in the mail path even one that’s Proton-owned.
The AGPL licence is worth reading in full for anyone considering commercial self-hosting; the copyleft provisions extend to network-served applications, meaning modifications must be shared back if the modified instance is offered as a service to other users. For a solo operator or a single-team internal deployment, this is not a constraint. For an agency planning to resell SimpleLogin as a service under their own brand, it is.
Self-hosting also removes the Proton Pass bundling, the mobile apps’ hosted-account integration, and the automatic security and abuse-handling updates SimpleLogin’s hosted service handles centrally. For most operators the hosted Premium tier at $4/month is the pragmatic choice; the self-hosting option is a real fallback rather than the default.
Where SimpleLogin sits in the class
Within the privacy-aliasing subclass of forwarding services, SimpleLogin and addy.io are the two serious options. Both offer unlimited aliases, custom domains, reverse-alias sending, self-hosting under an open licence, and reasonable pricing on the paid tier.
The differences are jurisdictional and structural. SimpleLogin operates under Proton AG in Switzerland, benefits from Proton’s payments, mobile apps, and infrastructure, and comes with Proton Pass Premium as part of the tier. addy.io operates as an independent Australian company under founder ownership, without the Proton bundling but also without the acquisition-integration questions that come with being part of a larger platform. Operators who already use or trust Proton products land on SimpleLogin as the natural default; operators who prefer independent providers or want to avoid concentrating multiple services under one company land on addy.io.
Neither is well-positioned for the “many role addresses on one domain” use case that ImprovMX and Forward Email are built for. If the operator needs admin@, support@, and sales@ on yourdomain.com all forwarding to the same inbox, the generalist forwarding services handle that more naturally. Aliasing services can do it, but the mental model is per-vendor uniqueness, not shared role addresses, and the tier limits and dashboards reflect that.
Verdict
For a WordPress operator who wants per-service aliases as a habit – a different email address for every hosting account, plugin licence, analytics tool, and marketing service they sign up to – SimpleLogin at $4/month is the current default in the privacy-aliasing subclass. The Proton bundling makes it more compelling than addy.io for operators already in the Proton ecosystem; addy.io is the alternative for operators who prefer smaller-vendor independence.
For a WordPress operator who only needs one or two role addresses on a custom domain forwarded to Gmail, Forward Email (unlimited on the free tier) or ImprovMX (one domain free) are better fits. SimpleLogin’s model is designed around volume of aliases, not volume of forwards on a small number of role addresses.
SimpleLogin is never the WordPress transactional relay – the site’s wp_mail() traffic goes through Postmark, SMTP2GO, or Mailgun regardless of what SimpleLogin is doing in front of the inbound side.