Lookproof Browse tools

DMARC, SPF and DKIM for Proton Mail

Updated 2026-11-06

Proton Mail lets paid plans send and receive mail with addresses on your own domain. You add the domain in the Proton web app, verify it with a TXT record, point MX at Proton, and then publish SPF, DKIM and DMARC at your DNS host. Proton documents this in a general custom domain article, an anti-spoofing article, and guides for many registrars and DNS hosts, such as Cloudflare, OVH and GoDaddy. For the background on each standard, see SPF explained, DKIM explained and DMARC explained.

What Proton Mail sends from

Mail you send as [email protected] leaves through Proton's servers. The visible From address is your own domain. Proton's SMTP submission article says apps that send through Proton use your address as the sender, "while respecting any anti-spoofing protections (e.g. SPF/DKIM/DMARC) you've set up for your custom domain".

Before mail flows, Proton asks for a verification TXT record on @ with a value of the form protonmail-verification=xxx, then its two MX records. MX controls inbound mail only, and says nothing about which servers may send (unless SPF lists mx, as Proton's record does).

The Proton docs do not state which domain appears as the envelope sender (Return-Path) of outgoing mail. They do tell you to publish the SPF include on your own domain, and they say it means "you allow Proton Mail servers to send on behalf of your domain". The docs mention no custom bounce subdomain, and they put SPF on @, so SPF belongs on example.com.

Once the CNAME records are in place, the docs say Proton will "start signing outgoing emails from your custom domain with DKIM". The selectors live under _domainkey.example.com, and a signature that verifies through those names carries d=example.com.

SPF

Publish one TXT record on the domain itself (host @ at most DNS hosts). The exact value is shown in the SPF tab of your domain settings in Proton. As of November 2026 Proton's registrar guides show this value:

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

include:_spf.protonmail.ch authorises Proton's servers. The docs add that "the mx also includes your domain's MX records". The Squarespace guide shows the same record without mx. Follow what your SPF tab shows.

To find the tab, as of November 2026 the anti-spoofing article says to go to Settings, All settings, Domain names, and click Review next to the domain. The general article puts it simply: "Make sure you have only one SPF record." If you already have one, add the include after v=spf1 in that record. A typical setup with Proton plus another service looks like this, where _spf.example.net is a placeholder for that other service's include:

example.com TXT "v=spf1 include:_spf.protonmail.ch mx include:_spf.example.net ~all"

That record uses 3 DNS lookups itself: two includes and the mx mechanism. Each include then adds the lookups inside its own record. Proton documents no number for it. When we counted it with real DNS on 7 November 2026, that record held one further include (_spf2.protonmail.ch) and otherwise only IP ranges, so include:_spf.protonmail.ch cost 2 lookups in total. Count your whole tree with the SPF lookup counter. RFC 7208 sets the limit at 10 lookups. Above that, SPF returns a permanent error (see too many SPF lookups).

The record ends in ~all (softfail). Proton's anti-spoofing article names -all (HardFail) as the alternative and says it makes receivers reject the mail, which "can cause delivery problems for legitimate emails", for example when SPF fails on forwarding. Prefer ~all. RFC 9989 warns that some receivers check SPF early in the SMTP transaction, so -all can get mail rejected before DMARC runs, even when aligned DKIM would have passed it. That mail never appears in your aggregate reports.

DKIM

Proton signs outgoing mail and hosts the keys. You publish three CNAME records that point at them. The steps, as documented as of November 2026:

  • Wait until the domain is verified. Proton says this can take a couple of hours, and it sends an email when the host names and values are ready.
  • In the web app, go to Settings, All settings, Organization, Domain names, and click Review in the Actions column next to the domain.
  • Select the DKIM tab. It shows three host names and three values.
  • At your DNS host, create three CNAME records with exactly those names and values.
  • Wait for the green tick on the DKIM tab. Proton then starts signing.

As of November 2026 the registrar guides name the hosts like this. The targets are your own values from the DKIM tab:

protonmail._domainkey.example.com CNAME <value from the DKIM tab>
protonmail2._domainkey.example.com CNAME <value from the DKIM tab>
protonmail3._domainkey.example.com CNAME <value from the DKIM tab>

Proton uses three records so that one key is always active while others are retired and recreated. The docs say Proton "will generate a new 2048-bit key every six months". The docs offer no key length option.

Two practical notes from the docs. Some registrars refuse a CNAME value with a trailing dot, and others require it. If yours refuses the record, delete the final dot and try again. On Cloudflare, set the proxy status to "DNS only", otherwise, Proton says, the record will not propagate.

If you set up DKIM earlier with a TXT record and manual rotation, delete that TXT record first, then add the CNAMEs at once.

DMARC alignment

DMARC passes when SPF or DKIM passes and the authenticated domain aligns with the From domain.

  • SPF alignment compares the RFC5321.MailFrom (Return-Path) domain with the From domain. Proton does not name its envelope domain. Proton asks for SPF on your own domain, which fits mail sent with example.com in the envelope, but the docs do not confirm it.
  • DKIM alignment compares the d= domain with the From domain. With the three CNAMEs in place, the keys sit under example.com, so a valid signature through them carries d=example.com and aligns.

Relaxed alignment, the default, only needs the same organisational domain. Strict alignment needs the exact same name. DKIM through the CNAMEs gives an exact match, so it aligns in both modes.

Without the DKIM records, alignment rests on SPF alone. Proton warns that mailing lists that forward mail break SPF, and that some lists change the content, which breaks DKIM too. DKIM survives plain forwarding more often than SPF, so publish both.

Step by step to p=reject

  1. Verify the domain and point MX. Add the domain in Proton, publish the protonmail-verification TXT record on @, wait for verification, and then add both MX records from the MX tab.
  2. Publish SPF. Add one TXT record on example.com with include:_spf.protonmail.ch, merged with the includes of every other service that sends as your domain. Keep the whole record at 10 DNS lookups or fewer.
  3. Publish the DKIM CNAMEs. Once the domain is verified, remove any old DKIM TXT record, then add all three CNAME records from the DKIM tab, as of November 2026 at protonmail._domainkey, protonmail2._domainkey and protonmail3._domainkey, and wait for the green tick.
  4. Start DMARC at p=none with reports. Publish a TXT record at _dmarc.example.com with v=DMARC1; p=none; rua=mailto:[email protected]. This policy does not protect the domain yet; it only turns on aggregate reports.
  5. Read the reports and fix other senders. For two to four weeks, look at which servers send as your domain. Give every legitimate service SPF and, where it offers it, DKIM for your domain, so that its mail aligns too.
  6. Move to quarantine. Change the policy to p=quarantine once reports show only aligned mail from your own services. As of November 2026 Proton recommends this policy for most domains. Failing mail is now usually placed in spam.
  7. Reject. Change the policy to p=reject when the reports stay clean. Proton presents reject as optional; we recommend it once reports are clean. Receivers then refuse mail that fails DMARC.

The record for step 4:

_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:[email protected]"

The final record:

_dmarc.example.com TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"

Proton shows a DMARC host name and value in the DMARC tab and says the default setting is none. You can use that value or write your own. Either way, only one DMARC record may exist at _dmarc.

Common mistakes

  • Two SPF records. Proton says to keep only one SPF record. Receivers return a permanent error when they find more than one (multiple SPF records).
  • Only one DKIM CNAME. Proton asks you to "add all three DKIM records". If a selector Proton signs with is missing, those messages fail DKIM (DKIM not found).
  • Names that differ from the wizard. The docs say the CNAME records "must be an exact match" with the ones in your setup wizard. The GoDaddy guide spells the names protonmail._domainkey1 and protonmail._domainkey2, unlike the other guides, so trust the DKIM tab.
  • An old DKIM TXT record. Proton says to delete it before entering the CNAME records. If it sits at the same name as a new CNAME, DNS will not accept both anyway.
  • Cloudflare proxy turned on. Proton says to select "DNS only" for the DKIM records.
  • Staying at p=none. Proton keeps none as the default because of mailing lists, but none does not stop spoofing (DMARC policy none).
  • Relying on a test flag. Some receivers support t=y (RFC 9989, DMARCbis) or pct (RFC 7489). Neither is a safety net. RFC 7489 says unknown tags must be ignored, so a receiver that implements only RFC 7489 can treat p=reject; t=y as a full reject. Let the reports decide each step instead.

How to check it

Run the email security check on your domain. It reads SPF, DKIM and DMARC in one pass. Use the SPF lookup counter to count every lookup behind include:_spf.protonmail.ch, mx and your other includes. In the DKIM selector finder, look for the selectors documented as of November 2026: protonmail, protonmail2 and protonmail3. Each should resolve through its CNAME to a key. Build or check your policy with the DMARC record generator.

Sources

Frequently asked questions

What SPF record does Proton Mail document?

As of November 2026 Proton's guides show v=spf1 include:_spf.protonmail.ch mx ~all as a TXT record on the domain itself (@). If you already have an SPF record, add include:_spf.protonmail.ch to it after v=spf1 instead of publishing a second record.

Which DKIM selectors does Proton Mail use?

As of November 2026 most of Proton's registrar guides (for example Cloudflare, OVH, Squarespace) name three CNAME records: protonmail._domainkey, protonmail2._domainkey and protonmail3._domainkey. The targets are generated for your domain and shown in the DKIM tab of the domain settings. Copy them exactly.

Why CNAME records and not a TXT record for DKIM?

Proton uses the CNAME records for automatic key rotation. As of November 2026 the docs say Proton generates a new 2048-bit key every six months. An older TXT record from manual rotation must be removed before you add the CNAMEs.

What DMARC policy does Proton Mail set by default?

Proton does not publish DMARC for you. You copy the DMARC value from the DMARC tab to _dmarc at your DNS host. The docs say the default setting is none and recommend p=quarantine for most domains. They suggest p=reject once legitimate mail passes DMARC, "if you think you are likely targeted for email spoofing". The path in this guide goes on to p=reject once reports are clean.