How long does DNS propagation take for custom domain MX records?

DNS propagation typically takes anywhere from 5 minutes to 4 hours, though it can occasionally take up to 24 hours globally. The duration depends heavily on the TTL value set on your DNS records prior to making changes. Lowering your TTL value before updating records helps speed up propagation times.

Can I use a root domain for email while keeping my website hosted elsewhere?

Yes, absolutely. MX records only dictate where email traffic is routed for your domain name. Your A and AAAA records can still point to your web hosting provider's IP address (such as 192.0.2.1), allowing your website and email to function independently on the same domain.

What happens if I forget to delete my old provider's MX records?

If you leave multiple provider MX records active, incoming mail delivery becomes unpredictable. Senders may experience random bounce backs, or messages might be delivered to your old mailbox instead of your new secure inbox. Always ensure legacy records are completely removed.

Why are my DKIM CNAME records showing as invalid?

DKIM validation failures usually happen because the domain registrar automatically appends the root domain name to the end of the host field or value. Ensure you are not duplicating your domain name in the DNS management console when pasting the values provided by your email host.

Should I set my DMARC policy to reject immediately?

It is strongly recommended to start with a DMARC policy of p=none for the first few weeks. This monitoring mode allows you to receive authentication reports and verify that all legitimate mail streams pass SPF and DKIM checks before you switch to p=quarantine or p=reject.

ProtonMail Custom Domain MX Setup Guide for Secure Email

Setting up a personalized email address requires precise configuration of your domain's DNS records to route mail securely. For a successful protonmail custom domain mx setup, you must add specific MX, SPF, DKIM, and DMARC records to your domain registrar's management console. Without these exact records, your custom domain cannot receive or authenticate messages reliably.

Understanding Custom Domain Email Architecture

When you migrate your domain's email to a secure provider, you are telling the global domain name system where incoming messages should be delivered and how outgoing messages should be signed. Email delivery relies entirely on DNS lookups. If a sending mail server cannot resolve your MX records, it bounces the message back to the sender.

Before you begin the configuration process, you should verify your current mail exchange configuration using the MX Lookup tool to check existing records and ensure a clean slate for your new setup.

The Core DNS Record Types

Configuring secure custom email requires four primary DNS record types. Each serves a distinct purpose in routing and security:

MX (Mail Exchange) Records: Direct incoming email traffic to your provider's mail servers.
TXT (SPF) Records: Specify which mail servers are authorized to send email on behalf of your domain.
CNAME (DKIM) Records: Cryptographically sign outgoing messages to prove they were not altered in transit.
TXT (DMARC) Records: Define policy actions for messages that fail authentication checks.

Step-by-Step ProtonMail Custom Domain MX Setup

To configure your domain, log into your email provider's administrator settings, navigate to the domain management section, and add your custom domain. The system will generate specific DNS values tailored to your account. Then, log into your domain registrar or DNS hosting provider.

Step 1: Add the MX Records

Delete any existing MX records that point to your old mail provider to prevent delivery conflicts. Add the two required mail exchange records with their assigned priorities.

Host/Name: @ (or leave blank for root domain, e.g., example.com)
Type: MX
Priority: 10
Value/Target: mail.protonmail.ch
Host/Name: @
Type: MX
Priority: 20
Value/Target: mailsec.protonmail.ch

Step 2: Configure SPF Authentication

Sender Policy Framework prevents spoofing by listing authorized sending IPs. If you already have an SPF record, append the provider mechanism to it rather than creating a duplicate record.

Host/Name: @
Type: TXT
Value: v=spf1 include:_spf.protonmail.ch ~all

Step 3: Set Up DKIM CNAME Records

DomainKeys Identified Mail adds a digital signature to every email sent. Your provider will supply three unique CNAME keys (often labeled protonmail1, protonmail2, and protonmail3). You must create all three.

Host/Name: protonmail1._domainkey
Type: CNAME
Value: protonmail1.example.com.domains.proton.ch.
Host/Name: protonmail2._domainkey
Type: CNAME
Value: protonmail2.example.com.domains.proton.ch.
Host/Name: protonmail3._domainkey
Type: CNAME
Value: protonmail3.example.com.domains.proton.ch.

Step 4: Implement DMARC Policy

Domain-based Message Authentication, Reporting, and Conformance tells receiving servers what to do if SPF or DKIM checks fail. Start with a monitoring policy before moving to strict enforcement.

Host/Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Verifying Your DNS Configuration

After adding your DNS entries, propagation can take anywhere from a few minutes to 24 hours depending on your TTL (Time to Live) settings. You can verify your settings using command line utilities.

Run a command prompt or terminal window and use dig to query your MX records:

dig example.com MX +short

Expected output:

10 mail.protonmail.ch.
20 mailsec.protonmail.ch.

To check your SPF and DMARC text records, use nslookup on Windows or Linux:

nslookup -type=TXT example.com

Comparison of DNS Records for Email Setup

Record Type	Host / Name	Target / Value	Purpose
MX	`@`	`mail.protonmail.ch` (Priority 10)	Primary mail routing
MX	`@`	`mailsec.protonmail.ch` (Priority 20)	Secondary backup mail routing
TXT	`@`	`v=spf1 include:_spf.protonmail.ch ~all`	Authorize sending servers
CNAME	`protonmail1._domainkey`	`protonmail1.example.com.domains.proton.ch.`	DKIM message signing key 1
TXT	`_dmarc`	`v=DMARC1; p=none;`	Authentication failure policy

Common Mistakes and How to Fix Them

Even experienced engineers occasionally make configuration errors during domain migrations. Watch out for these frequent pitfalls:

Conflicting MX Records: Leaving old mail provider records (like Google Workspace or Microsoft 365) active alongside your new settings causes mail to split-deliver or fail randomly. Always purge legacy MX records.
Incorrect CNAME Targets: Many registrars automatically append your root domain name to the end of CNAME values. If your control panel automatically adds .example.com to your entry, inputting the fully qualified domain name will result in duplicate suffixes like protonmail1.example.com.example.com. Check your registrar's behavior carefully.
Multiple SPF Records: A domain can only have one active SPF record. If you combine multiple services, merge them into a single string (e.g., v=spf1 include:_spf.protonmail.ch include:spf.protection.outlook.com ~all).
Low TTL Not Set: If you encounter issues, high TTL values will delay DNS updates. Lower your TTL to 300 seconds before making major routing changes.

Pre-Launch Checklist

Work through this checklist to ensure your custom domain is fully optimized and ready for production email traffic:

Old MX records completely removed from DNS registrar.
Primary and secondary MX records added with exact priorities.
SPF TXT record validated and checked for syntax errors.
All three DKIM CNAME records correctly populated without duplicate domain suffixes.
DMARC record created with a safe initial policy (p=none).
Test email sent and received successfully from an external address.

Setting Up ProtonMail Custom Domain with Correct DNS Entries