Separate mailbox migration from authentication
Proton Mail, formerly commonly called ProtonMail, supports custom-domain addresses on paid plans. Its custom-domain guide separates domain verification, address creation, MX changes and authentication. Plan these as distinct acceptance items. Receiving a message at the new mailbox does not prove that outgoing mail has the intended signature, and a DKIM check does not prove that every business address exists after a migration.
Start with an address inventory: individual users, aliases, shared business destinations, automated senders and reply addresses. Identify any service that sends using the same domain without going through Proton. Assign one person to the mailbox cutover and another to review DNS where practical. Record the existing MX and authentication records, the approved change window, and the decision-maker who can stop the cutover.
Proton specifically advises creating corresponding addresses before moving MX records. This matters because messages for missing addresses will not continue reaching the previous service once inbound routing has changed. Use the migration sequence for the account, and verify critical destinations with controlled messages before declaring the receiving side complete.
Record the exact domain and issued values
Open the intended domain in Proton's domain settings and retain the authentication instructions displayed for it. Distinguish the domain-ownership verification record from SPF, DKIM and DMARC. They answer different questions and should have separate evidence fields. Never substitute another organization's published records for the values in the account.
The DNS administrator should record the full owner name, record type and expected value for each entry. Compare these with the DNS editor's suffix handling, then inspect the published answers. A label can be visually correct in a control panel but appear at the wrong fully qualified name. Keep unrelated TXT records and record any existing use of the proposed DKIM owners before making changes.
If the domain is already used by a CRM, website or billing system, list those senders now. Moving staff mail to Proton does not authenticate a separate application's direct delivery. Either that application's approved route must have its own valid authentication or an explicitly designed submission route must be implemented and tested. Treat uncertain senders as inventory gaps, not reasons to weaken the domain's policy immediately.
Preserve one coherent SPF policy
Proton's anti-spoofing documentation identifies include:_spf.protonmail.ch as its SPF authorization and explains incorporating it into an existing policy. Use the account's recommended record and the domain's complete sender inventory to prepare the final value. Do not publish a second policy for the same owner or discard the authorization for another legitimate route during a migration.
Evaluate the complete policy against SPF's DNS-lookup rules. Choose the final qualifier deliberately rather than treating a copied example as an organization-wide policy decision. An SPF result is authentication evidence; receiving systems make their own handling decisions. Keep the previous policy available for an approved recovery change and note when cached versions may still be in use.
Keep the complete DKIM rotation setup
Proton uses three CNAME records for automatic DKIM rotation. Its domain authentication guide instructs customers to keep all three, match the wizard exactly, and wait for detection before outgoing custom-domain signing starts. An apparently idle selector can be required for a later rotation. Do not remove it because a single test message uses only one signing selector.
If verification fails, compare each owner and target character for character. Proton's CNAME troubleshooting guide identifies incorrect values, registrar handling of a trailing period, and an old manually managed TXT record as possible problems. Investigate the actual conflict before deleting anything. A TXT record at a different selector may belong to another legitimate sender and is not automatically obsolete.
Where the account is moving from Proton's old manual-key arrangement, plan the documented transition carefully. Proton warns of a signing interruption when the old TXT record is removed. Prepare all replacement values and a controlled test beforehand, coordinate the change window, and publish the required replacement promptly. This is not a recommendation to delete every DKIM TXT record in the zone.
Test staff mail and application submission separately
Send fresh messages from representative custom-domain addresses through the routes the organization uses. Record the client or application, From address, time and Message-ID. At a controlled external receiver, capture the trusted SPF, DKIM and DMARC results, the SMTP return-path and the DKIM d= and s= values. The signature's domain and selector identify the public-key lookup described by RFC 6376.
For a device or business application, Proton documents a separate SMTP-submission feature for paid plans with custom-domain addresses. Its SMTP guide uses address-specific SMTP tokens, not the ordinary mailbox password, and explains that SMTP-submitted mail is not end-to-end encrypted. Confirm feature eligibility and the authorized address before configuring an application. Credential creation and persistent access require their own security approval; no token should appear in the evidence workbook.
Record a separate result for each application even if a staff webmail test passes. A successful login to a submission server proves neither the final visible sender nor the recipient's authentication result. If a printer or CRM fails before submission, resolve that connection problem before diagnosing DKIM. If it submits successfully, follow the resulting message to the controlled receiver.
Set DMARC policy from observed routes
Review the domain's existing DMARC policy and reporting destination with its owner. Preserve an established policy unless a separately approved change is needed. An aligned passing SPF or DKIM result can satisfy DMARC, as defined in RFC 9989. Check the actual alignment mode rather than assuming every related subdomain qualifies.
Before increasing enforcement, account for direct applications, forwarding arrangements and mailing-list use that the business relies on. A monitoring period should have an owner and a review outcome, not become an indefinite substitute for investigation. Aggregate reports can guide discovery, but they do not replace route-specific headers or prove inbox placement for each recipient.
Proton Mail acceptance worksheet
Create a row for each staff-mail or application route:
- Domain, tenant owner and address inventory revision: ____.
- Domain verification, address creation and MX cutover evidence: ____.
- Existing senders retained in the SPF review: ____.
- Issued DKIM CNAME set and all three published-owner checks: ____.
- Legacy manual-key conflict and approved transition plan, if any: ____.
- Route, client or device and authorized From address: ____.
- Application SMTP access approval reference, excluding secrets: ____.
- Message-ID, UTC time, Return-Path and DKIM d=/s=: ____.
- Trusted authentication results, alignment and business receipt checks: ____.
- Recovery owner, unresolved exceptions and review decision: ____.
Fictional diagnosis after a DNS cleanup
Fictional example only: Juniper Accounts removes two Proton CNAMEs because its latest message uses the third selector. Later, authentication becomes inconsistent. The mail administrator compares the zone with the complete issued set rather than adding a new root-domain SPF policy. The missing CNAMEs are restored through the approved change process, Proton's state is rechecked, and fresh messages establish whether signing has recovered.
This example illustrates why rotation dependencies belong in the inventory. It is not an observed Proton incident, and no Juniper mailbox or DNS zone was accessed.
Retain evidence for the next change
Keep issued records, public DNS checks and redacted received headers together. Reverify after DNS-host changes, address migrations, key-transition work or new application routes. Live account inspection, record publication, controlled sending, rendered visual review, human SME approval and publication have not been completed by this article. Those gates remain pending even when the documentary procedure is complete.
Separate sending access from inbox access
Proton describes SMTP submission as sending-only; receiving through a third-party desktop client is a separate Bridge workflow. A successful application submission test does not establish inbox synchronization. Keep a distinct approved token per application so a revoked device does not unnecessarily interrupt other clients. This is an access-design recommendation; no credential was created or configured.
Separate message acceptance from policy rollout
A passing aligned SPF result can satisfy a message evaluation, but does not alone justify moving an entire domain to reject. RFC 9989 Section 7.4 requires valid DKIM for domains publishing p=reject and warns about indirect-mail interoperability. Inventory all legitimate senders and indirect routes before the policy owner approves enforcement. No DNS change, tenant operation or received-message test was executed for this article.