Proton Mail · Custom domain · Setup

Proton custom domain: the quiet overachiever (if you finish the setup)

First published 20 October 2026 · Records, statuses and recommendations from Proton's support documentation read in full. Host names and values in your console outrank every example printed anywhere — Proton demands an “exact match,” and its own guides prove why (§2).

The record set (Proton's specification)

The ladder

1. Settings → Domain names → add domain → Verify (TXT above; Proton suggests TTL 300 for the verification step).
2. MX tab: publish both records; remove rival MX.
3. SPF tab: merge the include into your existing single SPF record. Other senders on this domain? Their includes join the same record (Articles #3/#18) — Proton's include plays by the same lookup economy.
4. DKIM tab: publish all three CNAMEs exactly as your console lists them. Why “exactly”: Proton's own Cloudflare guide prints the hosts as protonmail/protonmail2/protonmail3, while its Hostpoint guide prints protonmail plus protonmail._domainkey1/_domainkey2 — the vendor contradicts itself across guides, so the console is the only authority. At Cloudflare: DNS only, or the records “will not propagate” (Proton's words). If a registrar balks at a trailing dot, strip it. A legacy manual-DKIM TXT must be deleted first — expect signing to pause until the CNAMEs resolve.
5. DMARC tab: publish the record — with §3's policy choice, not the default's.
6. Confirm five green tabs (Proton re-checks automatically; minutes to hours. Proton warns other platforms may cache your old settings 1–3 days — judge by Proton's readbacks + public lookups, not by a third party's stale cache).

§3 — DMARC: Proton's two voices

The wizard's supplied value starts at p=none. Proton's anti-spoofing article recommends p=quarantine for most domains, advancing to p=reject once confident. Both are Proton; the article is the considered guidance and the wizard is the on-ramp. Our house method (Article #4) lands in the same place: monitor at none briefly with reports actually being read (Article #36), then quarantine, then reject. What matters is that p=none is a phase, not a destination — Proton's own text says so.

What Proton does better than almost anyone: rotation

The three CNAMEs aren't ceremony. Behind them Proton keeps one key active while the others are automatically retired and recreated — a fresh 2048-bit key every six months. That's the overlap discipline of Article #39, industrialised: you will never hand-rotate a Proton key, never publish a p= value, and never face the delete-first sin. When a client's IT department asks about your key hygiene, “our provider rotates 2048-bit keys automatically on a six-month cycle, keys delegated by CNAME” is a genuinely strong answer — and it's Proton's own description.

Encryption ≠ authentication (Proton's own boundary)

Proton↔Proton mail is end-to-end encrypted. Proton→outside is TLS in transit and readable by the recipient's provider by default; E2EE to outsiders requires password-protected messages or PGP, and subject lines are never end-to-end encrypted. None of that proves anything to a receiving server about who sent it — that's SPF/DKIM/DMARC's job, and it's why a privacy-led choice still needs this whole guide. Sophisticated clients ask both questions; now you can answer both.

Plan facts (Proton's pages)

• Custom domains: paid plans only (“All paid plans support adding custom domains”). Domain allowances: Mail Plus 1 · Unlimited/Family/Mail Essentials 3 · Workspace Standard 15 · Workspace Premium 20.
• Catch-all: any paid plan (older “Visionary/Professional only” claims are stale).
• Bridge (desktop IMAP/SMTP): paid feature. SMTP submission (apps/CRMs/printers sending through Proton) is positioned by Proton as a business feature — plan eligibility beyond that is inconsistently documented by third parties, so confirm on your plan before architecting around it.
• Proton's one deliverability claim, quoted as a claim: mail sent through Proton servers benefits from their “high sender reputation” (its SMTP business post). Independent data isn't published by Proton — treat as vendor voice.

Verify

• Console: five tabs green (Verify/MX/SPF/DKIM/DMARC) — the platform's own suite.
• Readbacks: both MX, one merged SPF containing the Proton include, three CNAMEs answering as CNAMEs, one _dmarc.
• Headers: external test mail shows dkim=pass with d= your domain (the documented design outcome) and DMARC passing; your aggregate reports (Article #36) list Proton as an aligned source.

Traps

FAQ

Should I use -all since Proton defaults to ~all?

Proton's caution is about forwarded mail breaking under strict endings. The DMARC-era answer: with DKIM aligned (it is, here) and reports watched, many domains run -all safely — but adopt it as a decision after your reports are clean, not as a default copied from another platform's guide.

BIMI / MTA-STS on Proton?

Proton's custom-domain documentation never mentions them. BIMI would be your own records + enforcement (Article #37) — Proton neither helps nor blocks at the DNS level; MTA-STS hosting is likewise yours to arrange or skip.

Sources

Proton Support — custom domain setup guide (records, plan domain counts) · DKIM guide (three-CNAME model, six-month 2048-bit rotation) · registrar guides incl. Cloudflare (DNS-only warning) and Hostpoint (the host-name contradiction) · anti-spoofing article (p=quarantine recommendation) · encryption explainer (E2EE boundary) · Proton business post (SMTP submission; reputation claim, attributed).

Verification note: Proton's records and console behaviour were confirmed from Proton's documentation on 20 October 2026. Proton publishes no literal SPF string or sample signed header — the console's values govern, and the header expectation is stated as the documented design's outcome.