Using a custom domain with Proton Mail means your email address lives at a domain you own — not @proton.me. That distinction matters more than it sounds. If you ever need to move providers, your address moves with you. The contacts and services that have your email don't need to be updated. The domain is yours permanently.
The setup involves four DNS records: a verification TXT record, two MX records, an SPF record, a DKIM set, and a DMARC record. Five steps total. Most of the time is waiting for DNS propagation.
Prerequisites
- Proton Mail Plus or higher — custom domains aren't available on the free plan. Any paid Proton plan (including Mail Plus, Visionary, or Family) supports at least one custom domain. Check Proton's support page for current plan-specific domain limits.
- A domain you own — registered anywhere: Namecheap, Porkbun, Cloudflare, your registrar of choice.
- Access to your domain's DNS settings — this is the DNS management panel at your registrar or wherever your nameservers point.
- Any existing email on that domain disabled or migrated — if the domain currently points to another mail provider, you'll need to redirect or migrate before switching MX records.
Step 1: Add the Domain in Proton Settings
- Log in to Proton Mail at mail.proton.me
- Go to Settings → All settings → Proton Mail→ Domain names
- Click Add domain and enter your domain name
- Add this TXT record to your DNS at your registrar
- Come back to Proton and click Verify. If DNS hasn't propagated yet, wait a few minutes and try again. Proton checks automatically and shows a green checkmark once confirmed.
Proton will give you a TXT record for domain verification — something like:
Type: TXT
Name: @ (or your domain root)
Value: protonmail-verification=xxxxxxxxxxxxxxxxxxxx
TTL: 3600 (or your registrar's default)
Step 2: Set MX Records
MX records tell the internet where to deliver email for your domain. Proton uses two:
| Type | Name | Value | Priority |
|---|---|---|---|
| MX | @ | mail.protonmail.ch | 10 |
| MX | @ | mailsec.protonmail.ch | 20 |
Before adding these, delete or disable all existing MX records pointing elsewhere. This is the most common mistake. If you leave old MX records in place alongside Proton's, some mail will route to your old provider and some to Proton — a silent split delivery problem that's annoying to diagnose.
If your previous MX records had a long TTL (say, 86400 seconds / 24 hours), expect up to 48 hours for full global propagation. Plan accordingly.
Step 3: SPF Record
SPF tells receiving servers which mail servers are authorized to send email on behalf of your domain. Without it, email you send from Proton can be flagged as spoofed.
Add this TXT record at your domain root:
Type: TXT
Name: @
Value: v=spf1 include:_spf.protonmail.ch ~all
If you already have an SPF record for other services (say, you also send from a transactional email platform), don't create a second TXT record — just append include:_spf.protonmail.ch to the existing v=spf1 line before the final ~all or -all. One SPF record per domain. Two records break validation.
Step 4: DKIM Records
DKIM lets Proton cryptographically sign every outgoing email with your domain's private key. Receiving servers verify the signature — confirming the email actually came from Proton, not someone forging your address.
Proton requires three CNAME records for DKIM. Why three? Key rotation. Proton automatically retires and regenerates signing keys on a rolling basis — having multiple active records means there's always a valid key in use during the transition.
The exact hostnames and values are generated for your domain in the Proton settings interface after domain verification. Go to your domain's settings in Proton → DKIM tab → copy all three CNAME records and add them at your registrar.
They'll look like this pattern (with your actual generated values):
Type: CNAME
Name: protonmail._domainkey
Value: protonmail.domainkey.xxxx.domains.proton.ch
Type: CNAME
Name: protonmail2._domainkey
Value: protonmail2.domainkey.xxxx.domains.proton.ch
Type: CNAME
Name: protonmail3._domainkey
Value: protonmail3.domainkey.xxxx.domains.proton.ch
Step 5: DMARC Record
DMARC ties SPF and DKIM together and tells receiving servers what to do when one or both checks fail. It also enables aggregate reports so you can see if anyone is attempting to spoof your domain.
Type: TXT
Name: _dmarc
Value: v=DMARC1; p=quarantine; rua=mailto:[email protected]
The p=quarantine policy tells receiving servers to send failed messages to spam rather than deliver them. If you're cautious and want to monitor first before enforcing, start with p=none — it collects reports without taking action. Move to p=quarantine after a few weeks once you've confirmed your own mail is passing cleanly.
The rua= address receives aggregate reports. You can use any address on your domain — or omit it entirely if you don't want reports. For anti-spoofing purposes, the p= policy is what matters.
Also Read:
Frank Line Tech
Step 6: Verify Everything
MXToolbox has free lookup tools for all of these:
- MX Lookup: confirms your MX records point to Proton's servers
- SPF Lookup: confirms your SPF record is syntactically valid
- DMARC Lookup: confirms your DMARC record is readable
For an end-to-end test — SPF, DKIM, and DMARC all verified together — send a test email to the address generated by mail-tester.com. It sends back a deliverability score and itemizes which authentication checks passed or failed.
Catch-All Address (Optional but Useful)
A catch-all address receives all email sent to your domain, regardless of what address it was sent to. If someone emails [email protected] — even an address that doesn't exist — you get it.
To set it up: Settings → All settings → Proton Mail → Domain names → Actions (dropdown on the domain name) → Set catch-all → enter any address at your domain.
Proton's recommendation is to use a dedicated address for catch-all delivery (e.g., [email protected]) rather than routing everything into your main inbox. Keeps things readable.
The practical use case: you can use [email protected] when signing up for any site, without pre-creating that address. Everything routes to you through catch-all. If a service starts sending spam, you know exactly which service sold your address.
SimpleLogin Integration
Proton acquired SimpleLogin in 2022, and the two products complement each other well. You can add your custom domain to SimpleLogin separately from your Proton account, which gives you something catch-all doesn't: per-alias tracking with individual disable.
With SimpleLogin's catch-all enabled on your domain, you get a unique alias automatically created for every signup — and you can disable any one alias without affecting the others. For privacy-forward email management (covered in detail in the email aliases guide), this is the more powerful setup.
Frank Line Tech
Why This Matters
Your email address is the key to almost everything else. Password resets, account verification, identity recovery — all of it routes through email. A @proton.me address is encrypted and private, but it's permanently tied to Proton as a provider.
A custom domain is portable. If Proton raises prices, changes policies, or shuts down a plan — you update your MX records and move. Every service that has your address keeps working. That portability is the real value here, separate from any privacy benefit.
The data broker problem runs through email too. Every site you sign up for gets your address. Every breach that exposes it is another entry on lists that get sold and recycled. Compartmentalizing with aliases per service — especially for sites you don't fully trust — is exactly the kind of incremental damage limitation that the data broker opt-out guide talks about at the identity layer.
Frank Line Tech
The DNS setup is the fiddly part. Once those records propagate and the green checkmarks appear in Proton's settings, everything runs automatically. Mail arrives encrypted, signatures verify, DMARC reports show clean. After that, it genuinely fades into background infrastructure — which is exactly what it should be.
