Email authentication for Proton Mail: SPF, DKIM and DMARC

22 June 2026 · 6 min read

Proton Mail on your own domain needs three kinds of DNS record to authenticate the mail you send: one SPF TXT record, three DKIM CNAME records and one DMARC TXT record. Proton generates all of them for you under Settings > Domain names, so the work is publishing them exactly, checking they resolve, and then tightening DMARC without blocking your own mail.

This guide is for custom domains such as you@example.com. Addresses on @proton.me and @pm.me belong to Proton, which already authenticates them.

The Proton Mail records at a glance

Copy every value from your own Proton panel. The DKIM targets contain an identifier unique to your domain, and Proton's anti-spoofing guide is the authority if anything here differs from what the panel shows.

Step 1: verify the domain

In Proton, open Settings, then Domain names, add your domain and copy the verification TXT record. Publish it at the root of the domain: host @, or an empty host field if your DNS provider rejects @. Proton will not route mail for the domain until it sees this record. Depending on the TTL of your existing records, the check can take from a few minutes to a few hours.

Step 2: add the MX records if Proton hosts your inbox

Add both MX records and remove the old ones, or make sure Proton's records have the lowest priority numbers. MX records decide where inbound mail goes. They do not authenticate the mail you send.

Step 3: publish one SPF record with Proton's include

SPF lists the servers allowed to send mail for your domain. Proton's include covers its outbound servers:

v=spf1 include:_spf.protonmail.ch ~all

• One SPF record only. If a v=spf1 record already exists, add include:_spf.protonmail.ch to it after v=spf1 instead of publishing a second record. Two SPF records is a permanent error under RFC 7208, and SPF then fails for every sender on the domain.
• ~all rather than -all. Proton's guide warns that a hard fail (-all) can cause delivery problems, for example with forwarded mail, and points you to soft fail (~all). DMARC counts both as an SPF failure, so the choice matters less once DMARC is enforced.
• Ten DNS lookups at most. SPF stops with a permanent error after ten lookups. At the time of writing Proton's include nests one more include, so it uses two of the ten. Each other sender you add uses more.

Check the published record and its lookup count with the SPF checker.

Step 4: publish the three DKIM CNAME records

DKIM adds a signature that lets a receiver confirm the message came from your domain and was not altered. Proton does not give you a key to paste. On the DKIM tab for your domain (Settings > Domain names > Review) it shows three CNAME records in this form:

protonmail._domainkey    CNAME  protonmail.domainkey.<your-id>.domains.proton.ch.
protonmail2._domainkey   CNAME  protonmail2.domainkey.<your-id>.domains.proton.ch.
protonmail3._domainkey   CNAME  protonmail3.domainkey.<your-id>.domains.proton.ch.

The public keys live on Proton's side of the CNAME, which lets Proton rotate them without you editing DNS. Proton says it generates a new 2048-bit key every six months, so publish all three records and leave them in place.

When you add them:

• Type only the host part, such as protonmail._domainkey, if your DNS provider appends the domain for you. Otherwise the record becomes protonmail._domainkey.example.com.example.com and never resolves.
• Some providers reject a trailing dot on the CNAME target and others require it. If the record is refused, remove or add the final dot.
• On Cloudflare, set Proxy status to DNS only. Proton's Cloudflare guide warns the record will not work if it is proxied.
• If you once set up DKIM by hand with a TXT record, Proton says to remove it when you move to the CNAMEs.

Proton shows a green tick once each record verifies. You can confirm the key yourself with the DKIM checker using the selector protonmail.

Step 5: check which mechanism aligns

DMARC passes when SPF or DKIM passes and aligns with the domain in the visible From address. Proton publishes your DKIM keys under your own domain, so its signature carries d=example.com and aligns with a From address on example.com.

Whether SPF also aligns depends on the envelope sender (Return-Path) on Proton's outbound mail, which Proton's documentation does not state. Send yourself a message at a Gmail or Outlook address, open the original and read the Authentication-Results header: smtp.mailfrom= is the domain SPF was checked against, and header.d= or header.i= is the DKIM domain. Whatever it shows, treat DKIM as the mechanism your DMARC pass depends on, because a DKIM signature survives forwarding and SPF does not.

Step 6: publish DMARC at p=none and read the reports

Start in monitoring mode:

_dmarc   TXT   "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

p=none changes nothing about delivery. rua= is where receivers send daily aggregate reports, with one row per sending source showing whether SPF and DKIM passed and aligned. For mail from Proton's servers you want to see DKIM pass and aligned on every row. Build the record with the DMARC generator and read the reports in the DMARC report analyser.

Step 7: move to quarantine, then reject

Proton's default DMARC policy is p=none, and Proton recommends p=quarantine for most domains. When the reports show every legitimate sender passing DMARC, change the record to:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com

and, once quarantine has run cleanly, to:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com

The current DMARC standard, RFC 9989, suggests at least a month at p=none and a similar period at p=quarantine. It also removed the old pct= tag. To trial a stricter policy, add t=y, which asks receivers to apply one level less: p=quarantine is treated as p=none, and p=reject as p=quarantine.

The same RFC says domains whose users post to mailing lists SHOULD NOT publish p=reject. A list that edits messages breaks the DKIM signature, and because the list sends from its own servers, SPF cannot rescue the message either. If your team uses mailing lists, p=quarantine may be the right place to stop.

Proton Mail checklist

1. Verification TXT record at the root.
2. Both MX records, if Proton hosts your inbox.
3. One SPF record containing include:_spf.protonmail.ch.
4. All three DKIM CNAME records, resolving and not proxied.
5. DMARC at p=none with a working rua address.
6. Reports showing Proton mail passing DKIM aligned, and every other sender accounted for.
7. p=quarantine, then p=reject where mailing lists allow it.

To check the live state of all three records at once, run your domain through the DMARC checker. For the theory behind step 5, read DMARC alignment explained and why DMARC fails when SPF and DKIM pass. If you would rather not stage the policy yourself, hosted DMARC publishes the record, moves it from p=none towards p=reject and reads the reports for you.