Email authentication for Proton Mail: SPF, DKIM and DMARC

29 April 2026 · 12 min read

Proton Mail is built around end-to-end encryption and privacy, but when you put it on your own domain it becomes an ordinary outbound sender as far as Gmail, Outlook, Yahoo and Apple are concerned. Those receivers do not care that your message body was encrypted in transit. They care whether the domain in your visible From address passed SPF, DKIM and DMARC, and whether it did so in an aligned way. Proton handles a lot of the cryptography for you, but the DNS records still live in your zone, and one specific quirk of how Proton routes outbound mail decides whether you reach p=reject cleanly or lock yourself out of your own inbox.

This guide is specific to Proton Mail on a custom domain (for example you@yourcompany.com), not the free @proton.me or @pm.me addresses, which you cannot authenticate yourself. It covers the exact SPF include Proton uses, how Proton's three DKIM CNAME records work and why they are CNAMEs rather than TXT, the return-path alignment quirk that makes DKIM load-bearing, and a safe sequence to take a Proton-hosted domain from no protection to enforcement without an email outage.

How authentication works when Proton Mail sends your mail

When a Proton user sends a message from you@yourcompany.com, Proton's outbound servers connect to the recipient and present three things a receiver can check independently:

• The envelope sender (also called the return-path or MAIL FROM). The receiver uses the domain here for SPF. With Proton, this is a Proton-controlled domain, not yours. Hold that thought, because it is the single most important fact in this article.
• A DKIM signature in the message header, signed with a private key Proton holds and rotates, verifiable against a public key published in your DNS.
• The From header your recipient actually sees, which is you@yourcompany.com.

DMARC ties these together. A message passes DMARC only if at least one of SPF or DKIM both authenticates and aligns with the domain in the visible From address. Alignment is the part people miss. SPF can authenticate perfectly for Proton's own domain and still contribute nothing to DMARC, because the domain that passed SPF is not the domain in your From header. We will return to this repeatedly, because with Proton it determines your entire strategy.

If any of these terms are unfamiliar, our glossary defines each one, and /blog/dmarc-alignment-explained walks through alignment in detail. For the rest of this article we stay focused on Proton.

Step 1: Add and verify your domain in Proton

Authentication cannot work until Proton knows the domain is yours. In your Proton account, go to Settings → All settings → Domain names (on Proton Mail Business and Visionary plans this sits under Organization → Domain names). Add your domain, and Proton gives you a verification TXT record to publish at the root:

yourcompany.com.   TXT   "protonmail-verification=a1b2c3d4e5f6..."

Publish that at host @ (some registrars want the bare domain, or an empty host field). Proton checks for it, and once it sees the record the domain flips to verified. Nothing about authentication or mail delivery happens yet; this record only proves control.

Step 2: Publish Proton's MX records

If you want to receive mail at the domain, you publish Proton's MX records. These do not affect SPF, DKIM or DMARC directly, but a verified, mail-routing domain is the foundation everything else sits on. Proton's MX records are:

yourcompany.com.   MX   10   mail.protonmail.ch.
yourcompany.com.   MX   20   mailsec.protonmail.ch.

The 10 and 20 are priorities: receivers try mail.protonmail.ch first and fall back to mailsec.protonmail.ch. Copy the exact hostnames Proton shows you in the panel rather than trusting any third-party list, because Proton occasionally adjusts infrastructure. If you are only sending through Proton and receiving elsewhere, your MX may differ, but the authentication records below are unaffected either way.

Step 3: Publish the Proton SPF record

SPF declares which servers may send mail using your domain in the envelope sender. Proton publishes its entire outbound infrastructure behind a single include, so you never list individual IP addresses. The record Proton directs you to publish is:

yourcompany.com.   TXT   "v=spf1 include:_spf.protonmail.ch ~all"

Publish this as a TXT record at the root of the domain (host @). Three rules catch people out here:

• A domain may have only one SPF record. If a v=spf1 record already exists, from a previous host or a marketing tool, do not add a second. Two v=spf1 TXT records is a permanent error and SPF then fails for every sender, including Proton. Merge the includes into one record instead.
• Note the ~all at the end. Proton's own documentation recommends soft fail (~all) rather than hard fail (-all). This is deliberate and unusual, and it is tied directly to the alignment quirk in the next section. We will explain why ~all is the safer choice with Proton, and when you might still move to -all.
• Every include you add later costs a DNS lookup. Proton's include is lean, but SPF permanently fails (PermError) above ten lookups, so keep an eye on it as you add other senders.

If you also send through other services

Real domains rarely send through one platform. You might use Proton Mail for staff mailboxes plus a separate provider for invoices, newsletters or a help desk. Each of those needs to be in the same single SPF record:

yourcompany.com.   TXT   "v=spf1 include:_spf.protonmail.ch include:_spf.example-esp.com ~all"

If you stack several third parties and start nudging the ten-lookup ceiling, our explainer at /blog/spf-10-lookup-limit covers the rule and /blog/fix-spf-permerror covers the fix. Automatic flattening, described in /docs/how-spf-flattening-works, keeps the record under the limit without you re-editing IPs every time a provider changes theirs.

Once published, confirm the record resolves and counts correctly with our SPF checker.

Step 4: Enable Proton DKIM (three CNAME records)

DKIM is the stronger mechanism, and with Proton it does almost all of the work for DMARC. A DKIM signature is cryptographic and travels with the message, so it survives relaying in ways SPF does not. Proton signs every outbound message with a private key it holds and never exposes.

What makes Proton different from most providers is that it does not give you a static TXT record to paste. It gives you three CNAME records, and it manages the public keys behind them so it can rotate keys automatically without you touching DNS again. In Proton, go to Settings → Domain names, click Review (or the actions menu) next to your domain, and open the DKIM tab. Proton shows three host and value pairs that look like this:

protonmail._domainkey.yourcompany.com.    CNAME   protonmail.domainkey.dXXXXXXXXXXXXXXXXXX.domains.proton.ch.
protonmail2._domainkey.yourcompany.com.   CNAME   protonmail2.domainkey.dXXXXXXXXXXXXXXXXXX.domains.proton.ch.
protonmail3._domainkey.yourcompany.com.   CNAME   protonmail3.domainkey.dXXXXXXXXXXXXXXXXXX.domains.proton.ch.

The dXXXXXXXXXXXXXXXXXX portion is unique to your domain, so copy the exact targets from your own Proton panel rather than from this article. Publish all three exactly as shown.

Why three records, and why CNAMEs

The two design choices both serve the same goal: rotation without breakage.

• Three selectors let Proton keep more than one key live at a time. During a key rotation, an old key can keep verifying mail that is already in flight while a new key starts signing, so there is no window where signatures fail. You publish three pointers once; Proton decides which key is active behind them.
• CNAMEs, not TXT. Because each record is a CNAME pointing into domains.proton.ch, the actual public key lives on Proton's side. When Proton rotates a key, it updates the target zone and your CNAME automatically follows. If Proton had given you a TXT record with the literal key, every rotation would require you to log in and paste a new value, and a missed rotation would silently break DKIM. The CNAME approach trades a little visibility for hands-off reliability.

A few practical notes when publishing:

• Some registrars reject CNAME values that end in a trailing dot, while others require it. If the record is refused, try removing or adding the final . on the target.
• Do not enable Cloudflare's orange-cloud proxy on these CNAMEs. They must resolve as plain DNS, not be proxied, or DKIM lookups break. Leave them grey-clouded (DNS only).
• Some DNS panels try to append your domain to the target automatically, producing a doubled ...domains.proton.ch.yourcompany.com. Paste the target exactly and check the saved record.

Once all three resolve, Proton marks DKIM active, and you can confirm the signature publishes with our DKIM checker using the selector protonmail.

Step 5: The return-path quirk, and why DKIM carries DMARC

This is the section that matters most for Proton, and it is where generic DMARC advice goes wrong.

When Proton sends your mail, the envelope sender (return-path) is a Proton-owned domain, not yours. SPF is evaluated against that envelope domain, so SPF authenticates against Proton's domain and passes. But DMARC does not care that SPF passed in isolation. DMARC requires the SPF-authenticated domain to align with your visible From domain. Because Proton's return-path is a Proton domain and your From is yourcompany.com, the two do not match, and SPF alignment fails.

Proton does not currently offer a custom return-path or MAIL FROM that you can point at your own domain. There is no setting that makes SPF align. That is not a misconfiguration you can fix; it is how Proton's outbound routing is built. The consequence is direct and important:

With Proton Mail, DKIM is the only mechanism that can satisfy DMARC alignment for your domain. SPF will authenticate but will not align. Your entire DMARC pass depends on the three CNAME records from Step 4 being correct and active.

This also explains Proton's own recommendation of ~all rather than -all in the SPF record. Because the return-path is a Proton domain, the receivers checking SPF against it are checking Proton's posture, and a softer qualifier avoids unhelpful hard-fail edge cases on forwarded or relayed mail without weakening the protection that actually counts for you, which is DKIM-based DMARC alignment.

The strategic takeaway is simple: do not chase SPF alignment with Proton. Make absolutely sure DKIM is verified and aligned, then build your DMARC policy on that. DKIM alignment with Proton is straightforward because the DKIM signature carries a d= value of your own domain, which matches your From header under DMARC's default relaxed alignment.

If you want the deeper background on why one aligned mechanism is enough, /blog/dmarc-alignment-explained covers it, and /blog/spf-vs-dkim-which-aligns addresses exactly this situation where one mechanism aligns and the other does not.

Step 6: Publish DMARC at p=none and collect reports

Now publish a DMARC record, but start in monitoring mode. DMARC lives at a fixed subdomain, _dmarc, as a TXT record:

_dmarc.yourcompany.com.   TXT   "v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com; fo=1; adkim=r; aspf=r"

Breaking that down:

• p=none tells receivers to enforce nothing yet, only to report. This is the safe starting point. It changes nothing about delivery while you gather evidence.
• rua=mailto: is where aggregate XML reports are sent. Point it at a mailbox you actually read, or better, at an analyser. You can generate a complete record with our DMARC generator.
• fo=1 asks for a failure report whenever any mechanism fails, which is useful while you confirm DKIM alignment.
• adkim=r and aspf=r set relaxed alignment for DKIM and SPF. Relaxed is correct for Proton and is the default; it lets an organisational-domain match count, which is what Proton's DKIM signature gives you.

Leave this running for a week or two. The aggregate reports will tell you, source by source, what is passing and what is aligning. For Proton mail specifically, you are looking to confirm that messages show DKIM pass and DKIM aligned, and you should expect to see SPF aligned = fail for Proton itself, which is normal and expected given Step 5.

Reading raw DMARC XML by hand is miserable. Paste a report into our DMARC report analyzer, or use /monitor to ingest reports continuously and alert you when a record changes or a new sending source appears.

Step 7: Move to quarantine, then reject

Once your reports show that your Proton mail (and every other legitimate sender on the domain) is passing DMARC through an aligned mechanism, tighten the policy in two stages. Do not jump straight to reject.

First, move to quarantine, optionally on a percentage:

_dmarc.yourcompany.com.   TXT   "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@yourcompany.com; adkim=r; aspf=r"

pct=25 applies the quarantine policy to a quarter of failing mail, so any surprise lands softly. Watch the reports for a week, raise to pct=100, then move to full enforcement:

_dmarc.yourcompany.com.   TXT   "v=DMARC1; p=reject; rua=mailto:dmarc@yourcompany.com; adkim=r; aspf=r"

At p=reject, anything that fails DMARC for your domain is rejected outright at the receiver. Because Proton mail relies entirely on DKIM for its DMARC pass, the thing that would break you at this stage is a DKIM failure, so confirm DKIM is solid before you reject. Validate the live policy any time with our DMARC checker, and see /requirements for what Gmail, Yahoo, Apple and Microsoft now expect from bulk senders.

The forwarding and mailing-list caveat

One honest warning that applies to every provider, Proton included. When your message is forwarded or passes through a mailing list, SPF breaks (the forwarder is a new source) and some lists modify the subject or body, which breaks DKIM too. If both break, DMARC fails, and at p=reject that mail is dropped. With Proton this bites harder than usual, because you cannot fall back on SPF alignment; DKIM is your only aligned mechanism, so a list that mangles the body removes your last line of defence. This is not a reason to avoid enforcement. It is a reason to reach p=reject deliberately, watching reports, and to know which of your flows touch mailing lists before you get there. For the mechanism, see /blog/dmarc-forwarding-problem.

Step 8 (optional): MTA-STS and BIMI

With DMARC at enforcement you have the core in place. Two optional layers build on it:

• MTA-STS tells sending servers to require TLS when delivering to your domain and to refuse to downgrade, which closes a man-in-the-middle gap on inbound mail. It is independent of Proton's outbound setup. Check a policy with our MTA-STS checker.
• BIMI can display your brand logo beside authenticated mail in supporting clients, but only once you are at p=quarantine or p=reject. It is a reward for reaching enforcement, not a step toward it. Validate a BIMI record with our BIMI checker.

A safe order of operations for Proton Mail

To put the whole sequence in one place:

1. Add the domain in Proton and publish the protonmail-verification= TXT record.
2. Publish Proton's MX records (mail.protonmail.ch, mailsec.protonmail.ch) if Proton hosts your inbox.
3. Publish one SPF record: v=spf1 include:_spf.protonmail.ch ~all.
4. Enable DKIM and publish all three protonmail._domainkey CNAME records, unproxied, then confirm they resolve.
5. Accept that SPF will not align with Proton, and make DKIM your aligned mechanism for DMARC.
6. Publish DMARC at p=none with a working rua and read the reports.
7. Confirm Proton mail shows DKIM pass and DKIM aligned, then step through p=quarantine (with pct) to p=reject.
8. Add MTA-STS and BIMI once enforcement is stable.

The practical takeaway

Proton Mail is unusual in one specific, decisive way: its outbound return-path uses a Proton domain you cannot change, so SPF will authenticate but never align with your From address. That makes DKIM the load-bearing mechanism for DMARC, and it makes Proton's three rotating CNAME records the part you must get exactly right. Publish one SPF record with include:_spf.protonmail.ch ~all, publish all three protonmail._domainkey CNAMEs unproxied, then prove DKIM alignment in your DMARC reports before you tighten anything. From there the path to p=reject is the ordinary, careful one: monitor, quarantine a percentage, then reject.

If you would rather not babysit the rollout, our DMARC checker and DKIM checker confirm each step in seconds, and our done-for-you service takes a Proton-hosted domain from p=none to p=reject for you, with continuous report monitoring and change alerts so a silent DKIM rotation or DNS edit never quietly breaks your mail.