On this page: Separate authentication from mailbox migration · Find the domain-specific settings · Configure SPF without disconnecting other senders · Publish and retain all three DKIM CNAMEs · Check application sending separately · Add DMARC only after checking existing policy · Verify public DNS and receiver results · Troubleshooting and frequently asked questions
To authenticate a custom domain in Proton Mail, add Proton's SPF authorization to the domain's existing SPF policy, publish all three domain-specific DKIM CNAME records shown in Proton, and verify a delivered message against your DMARC policy. Do not replace other senders' records or remove the two DKIM selectors that are not currently signing.
This guide covers customer-owned domains sending through Proton Mail, including supported SMTP submission. It does not configure DNS for addresses on Proton-owned domains, and it is not a SimpleLogin alias guide. Custom domains require a paid Proton plan. Proton custom-domain requirements
Separate authentication from mailbox migration
Start with a list of addresses and sending applications. Record the visible From domain, the account administering it, the DNS host, and whether mail originates in Proton's interface, a client using Bridge, or a business application. A working staff mailbox does not establish that the website's password-reset system uses the same route.
If you are moving incoming mail, create the necessary Proton users and addresses before changing MX records. MX controls where incoming mail goes; changing SPF or DKIM does not migrate an inbox. Keep the old mailbox service available during the planned transition, and coordinate any later removal of its sending authorization with the person who owns that service. Proton migration sequence
Only for an approved mailbox migration, obtain separate routing-owner approval of the complete full-owner, numeric-priority and MX-target set. Reconcile the provider packet with that plan and compare the complete approved set at authoritative and recursive DNS before activation; stop on unapproved destinations or mismatches. Preserve other mail services. Authentication-only repair does not authorize changing MX.
Find the authoritative nameservers before editing DNS. The registrar that sold the domain may not host its active zone. Export the current records and TTLs, including existing SPF, DKIM selectors, domain-verification TXT records and DMARC policy. Keep a dated rollback copy, not just a screenshot of the proposed new values.
Find the domain-specific settings
In Proton Mail, open Settings, All settings, Domain names, then Review beside the correct domain. Use its SPF and DKIM tabs rather than values from another account or a tutorial screenshot. Complete domain verification first so that the values correspond to your domain. Proton authentication settings
For the change request, record each full DNS owner, record type and complete value. Also record the account status and who can approve the DNS edit. A domain being listed in the account is not the same as all authentication checks being complete.
Do not treat DNS ownership verification as a mail-routing instruction. A verification TXT record can coexist with an SPF TXT record at the same owner because they serve different purposes. The restriction is one SPF policy beginning v=spf1 at that owner, not one TXT record of any kind.
Configure SPF without disconnecting other senders
Proton's authorization mechanism is include:_spf.protonmail.ch. Add it to the existing SPF policy before its terminal all mechanism. If Proton is the only authorized service and no SPF record exists, this illustrates a starting policy:
Owner: example.com
Type: TXT
Value: v=spf1 include:_spf.protonmail.ch ~all
Replace example.com with your domain. Keep an existing policy's other legitimate authorizations and its established failure qualifier; this example does not authorize weakening -all to ~all. Proton's settings show the domain's recommended record. Proton SPF instructions
If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.
SPF checks the SMTP envelope sender, often recorded as smtp.mailfrom in receiver results, not simply the address displayed to the recipient. Publishing at the apex cannot repair an unrelated service's envelope domain. Use a delivered message to determine which domain is actually checked.
A second v=spf1 record at the same name is an error, not an extension. SPF also limits DNS-query-causing terms to ten during evaluation, including nested includes. Counting only the includes visible in your own TXT value can miss the problem. Avoid manually copying Proton's current IP addresses into a supposedly permanent replacement. SPF processing rules
For terminology and further troubleshooting, see EmailAuth's SPF overview.
Publish and retain all three DKIM CNAMEs
Copy all three owner-and-target pairs from Proton's DKIM tab. The targets are generated for the domain; there is no universal public key or CNAME destination to paste from this guide. Proton uses the three records for managed key rotation. Preserve all three even when today's message references only one selector. Proton DKIM rotation
Enter CNAME records, not TXT records containing the destination hostname. A CNAME owner cannot also host unrelated TXT or other ordinary record data. If a generated owner is already occupied, establish what uses it before changing anything. Do not delete another service's active signing record to make the DNS editor accept the change.
Where the actual authoritative DNS host offers these controls, use DNS-only aliases, not HTTP proxying or redirects, and keep a literal CNAME answer to each required target. Turn the relevant per-record Flatten option off when available, and ensure applicable zone-wide settings do not conceal the issued aliases. For Cloudflare specifically, flatten-all cannot be overridden per record; apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are Cloudflare behaviors, not assumed controls in another provider’s panel. If mandatory behavior or shared settings prevent the required CNAME answer, stop and coordinate a supported configuration without breaking dependent records. Do not blindly change the whole zone or remove an NS delegation; publish at the delegated authority when appropriate. Cloudflare CNAME verification, flattening controls. For an issued signing domain such as news.example.com, the illustrative full owner is ISSUED-SELECTOR._domainkey.news.example.com. In an editor relative to the parent example.com zone use ISSUED-SELECTOR._domainkey.news; in a separately delegated news.example.com zone use ISSUED-SELECTOR._domainkey; in a delegated _domainkey.news.example.com zone use only ISSUED-SELECTOR. Replace the placeholder with the issued selector and preserve the exact account type and value. These mappings do not establish product eligibility for a new domain. Publish at the actual authority, preserve NS delegation and check the resulting full owner. DKIM owner construction, relative DNS names.
Check how the DNS host interprets names. Some editors append your zone automatically: entering a full name into a relative-name field can produce a doubled domain. For Cloudflare, Proton's walkthrough specifies copying each DKIM target from the domain console. Follow that DNS host's record controls rather than guessing whether a field accepts a relative or fully qualified name. Proton's Cloudflare walkthrough
If your DNS service cannot create the required CNAMEs, contact Proton support before proceeding; do not convert a target hostname into a TXT value. Proton's troubleshooting page discusses moving legacy TXT-based DKIM to CNAMEs. Coordinate that transition with the current signing configuration, and resolve any same-owner TXT conflict before publishing the required CNAME, rather than assuming the old record remains interchangeable. Proton CNAME troubleshooting
For the documented legacy TXT-to-CNAME migration, Proton warns that removing the old TXT record stops DKIM signing. Prepare the complete replacement CNAME set before the approved change window, coordinate the interruption with the service owner, publish the required replacement promptly, and verify Proton status plus a controlled delivered message before closing the change. Do not remove the old record as an unplanned cleanup. Proton’s explicit migration warning.
After publication, return to the domain review screen and check verification. A verified DNS record establishes publication, not the result of every message. How DKIM signatures and public keys fit together
Check application sending separately
Proton's current SMTP submission documentation says the feature is available on all paid Proton Mail plans with custom-domain addresses. Older business-only descriptions should not decide eligibility. In Settings, All settings, IMAP/SMTP, SMTP tokens, generate a token for the active custom-domain address and use a separate token per client. The documented endpoint is smtp.protonmail.ch, port 587, with STARTTLS. Use the SMTP token, not the normal account or mailbox password. Proton SMTP submission
Obtain separate security-owner approval before creating a persistent SMTP token or granting an application ongoing sending access. SMTP-submitted messages are not end-to-end encrypted, even though Proton stores them with zero-access encryption. Check whether this route meets the message’s confidentiality requirements before enabling it; token authentication is not an end-to-end encryption guarantee. Proton SMTP security and token scope.
SMTP submission sends mail; it does not fetch your inbox through IMAP. A third-party desktop client receiving Proton mail uses a different integration, such as Bridge. Do not mistake an application that successfully authenticates to the submission server for a message that passes domain authentication at its destination.
Check the application's From setting and its actual route after configuration. A contact form may still send through the web host while staff mail uses Proton. A fallback transport can create the same discrepancy. Capture one example from each important application rather than declaring the entire domain finished after a single webmail test.
Add DMARC only after checking existing policy
DMARC passes when either SPF passes with an aligned envelope domain or DKIM passes with an aligned signing domain. Relaxed alignment permits an organizational-domain match; strict alignment requires the exact domain. Both mechanisms passing for unrelated domains is insufficient. Current DMARC standard, RFC 9989
First look up _dmarc for the visible From domain and inspect applicable parent policy. Preserve existing reporting destinations, alignment settings and enforcement. Do not add a subdomain p=none record that overrides inherited protection merely because a setup wizard suggests monitoring.
Only for a domain with no existing or inherited policy, and an approved monitoring rollout, this is a concrete example:
Obtain the domain owner’s explicit approval of this first policy and its monitoring/review plan before publication. Preserve any applicable direct or inherited policy rather than using the example to replace it.
Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
In an example.com zone whose editor appends the zone name, enter _dmarc as the relative owner. For a From address such as alerts@news.example.com, the exact-domain policy owner is _dmarc.news.example.com, or _dmarc.news relative to that zone. Check inheritance before creating this more-specific record.
For the full child policy owner _dmarc.news.example.com at a separately delegated news.example.com authority, enter relative _dmarc. Preserve that delegation and the applicable inherited policy.
Create and monitor the reporting mailbox before using your equivalent address. Semicolons separate tags; a comma separates multiple reporting URIs within rua. If using EmailAuth or another external report processor, use its assigned address and required destination authorization, not a made-up address. Publish one DMARC policy at each owner. External report-destination authorization, RFC 9990 section 4
Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4.
p=none requests monitoring rather than DMARC enforcement; it does not force delivery. Review reports across staff mail, applications and other authorized services before an approved enforcement change. RFC 9989 replaces RFC 7489 and removes pct; do not use percentage enforcement as a current-standard rollout control. EmailAuth's DMARC explanation
Verify public DNS and receiver results
These read-only commands are examples. Replace the domain and selector with your actual values; repeat the CNAME query for every Proton-issued selector.
dig +short NS example.com
dig +short TXT example.com
dig +short CNAME SELECTOR._domainkey.example.com
dig +short TXT _dmarc.example.com
Expect one SPF policy containing the required authorization, each DKIM CNAME pointing to its issued destination, and the intended DMARC policy. Query the CNAME target's TXT record to inspect the public key. A blank answer may indicate an incorrect name, unpublished record or resolver problem; it is not proof that signing is disabled. Compare an authoritative answer with a recursive resolver before attributing every delay to propagation.
Then, in an authorized implementation, deliver representative messages to a controlled external mailbox. Inspect receiver-added Authentication-Results from that mailbox's trusted system, not an arbitrary header inserted by a sender. Record header.from, SPF's smtp.mailfrom, DKIM's header.d and selector, and the DMARC verdict. The desired evidence is an aligned pass and dmarc=pass for the intended From domain. Authentication-Results trust boundaries
Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust. For this branded-DKIM deployment, require the intended provider signature itself to have trusted dkim=pass and a d= domain aligned with the intended unchanged visible From under effective adkim, plus the trusted receiver’s dmarc=pass for that From. A DMARC pass through SPF alone does not complete the DKIM task. DMARC alignment. Diagnose the actual smtp.mailfrom result independently: fail or softfail calls for checking the connecting sender against the approved authorization; temperror is a transient evaluation failure, often DNS; permerror requires checking malformed or duplicate policies and the evaluated lookup budget. An aligned DKIM pass does not repair these SPF faults. Do not change an unrelated apex policy to fix a provider-controlled envelope domain. SPF result definitions.
Retain the timestamp, route and redacted header evidence. EmailAuth's diagnostic tools can help inspect public records, but a DNS lookup cannot prove an unseen message's result or guarantee inbox placement.
Troubleshooting and frequently asked questions
Why did DKIM fail after a DNS cleanup?
Check whether someone removed an apparently unused rotation CNAME. Restore the exact required record from Proton, then verify all three. Also check for an owner with the zone suffix appended twice or a target entered as TXT.
Why does Proton webmail pass while my website fails?
They may use different sending systems. Inspect the website message's route and identities before adding more SPF mechanisms. Configure that application's real sender rather than assuming its mailbox address determines transport.
Can I keep another sender alongside Proton?
Yes, provided each route is authorized and aligned. Preserve its SPF authorization where applicable and its distinct DKIM selector. Test both services after changes; do not move MX merely to add outbound authentication.
Does a green domain check prove delivery?
No. It does not prove every application signs with the intended domain, nor that forwarding preserves authentication. Public DNS, provider status and trusted receiver headers answer separate questions.
What was verified for this guide?
No customer account, DNS change or message-sending test was performed. Implementers must verify their issued records, application routes and receiver evidence before treating setup as complete.