Key takeaways: what to know in 1 minute ✅
- ✅ Inventory every sending source before transfer. Record ESPs, CRMs, cloud services, and internal mail servers with exact DNS record names and selectors.
- ✅ Use TTL reduction then dual-signing to prevent downtime. Lower DNS TTLs 48–72 hours before transfer and enable DKIM coexistence (old + new keys) during the cutover.
- ✅ Validate records pre-transfer and monitor rua/ruf reports during transfer. Run scripted checks with dig/nslookup and expect DMARC aggregate reports to show authentication ratios.
- ✅ Protect DKIM private keys and use DNSSEC where possible. Secure key material and enable DNSSEC signing for authoritative zones to avoid tampering during migration.
- ✅ Prepare rollback and communications playbook. Include exact DNS rollbacks, stakeholder notifications, and KPIs (bounce rate, spam folder rate, authenticated percentage).
Email deliverability during a domain transfer depends on meticulous DNS and operational planning. This guide focuses exclusively on how to Transfer DNS-based email authentication (SPF/DKIM/DMARC) safely with checklists, commands, tests, and rollback procedures.
Why this matters now ⚠️
Changing the authoritative DNS registrar or nameservers often breaks the chain used by SPF, DKIM, and DMARC. Even brief misconfigurations can cause legitimate mail to land in spam or be rejected, harming business continuity. The following sections provide a step-by-step operational playbook to avoid that outcome and keep mail flowing.
Preliminary checklist: collect the inventory 🛠️
- 🧾 Domain and DNS facts: current registrar, current authoritative nameservers, DNS provider, DNSSEC status.
- 📡 All sending IPs and services: transactional ESPs (SendGrid, Mailgun), marketing platforms (HubSpot, Mailchimp), CRM mailers, cloud services (GCP/AWS SES), internal SMTP hosts.
- 🔑 DKIM selectors and key types: list selectors, RSA/ECDSA type, key lengths, and where private keys are stored.
- 🧩 SPF flattening or include chains: exact SPF records and length, mechanisms using include: and redirect=.
- 📊 DMARC policy and reporting: rua/ruf addresses, policy (p=none/quarantine/reject), pct.
- 👥 Stakeholders: admin contacts for DNS, security, deliverability, and external vendors.
Plan the cutover window and TTL strategy 💡
- Phase A, stabilization (T minus 7 to 3 days): audit and inventory; request stakeholders to pause DNS changes.
- Phase B, pre-change (T minus 72 to 48 hours): lower DNS TTLs to 300–600 seconds for email-related records (spf, TXT, CNAME, DKIM selectors). This speeds propagation and reduces risk.
- Phase C, transfer day (T): perform DNS transfer and verify records. Maintain dual-signing for DKIM for 48–72 hours post-transfer.
- Phase D, post-change (T plus 72 hours): raise TTLs back to normal (3600–86400), retire old DKIM keys after verification, and monitor DMARC reports for anomalies.
Why TTL matters: long TTLs can keep an old, incorrect record cached for hours to days. Short TTLs reduce the window of inconsistent authentication.
Dual-signing for DKIM: how to avoid signature loss ✅
- Dual-signing concept: keep both old and new DKIM selectors active and sign outgoing mail with both private keys during the transition window.
- Implementation steps:
- 1) Generate a new DKIM keypair on the new outbound mail stack.
- 2) Add new DKIM public record to DNS at the current provider (keep old selector present).
- 3) Configure mail system(s) to sign with both selectors when possible, or route mail through a signing gateway that applies both signatures.
- 4) After 48–72 hours of stable delivery and DMARC reports showing >99% authenticated, remove the old selector record.
Notes on key rotation: use at least 2048-bit RSA keys or ECDSA P-256 for smaller keys with sufficient security. Ensure private keys never transit unencrypted channels.
Step-by-step DNS transfer playbook (technical) 🛠️
- Record current DNS zone: export full zone file and save securely.
- Lower TTLs to 300–600 for email-related records (TXT, CNAME, MX, and DKIM selector records) 48–72 hours prior.
- Notify stakeholders and schedule transfer during low-send volume window.
- Add new DKIM public keys at the current DNS provider and verify propagation before transfer with dig.
- Prepare the new DNS host with the full zone including DKIM selectors, SPF TXT, DMARC TXT, MX records, and any required CNAMEs.
- Transfer registrar/nameserver change. Wait for authoritative nameserver updates to propagate.
- Immediately verify DNS via targeted queries to authoritative servers and external vantage points.
- Keep DKIM dual-signing active until DMARC reports confirm authentication parity.
- Raise TTLs after 72–96 hours of stable results.
- Rotate keys and retire old selectors only after verification and historic log review.
Commands and scripts to validate records (copy-ready) ⚙️
- SPF TXT check (Linux/macOS):
dig +short TXT example.com @ns1.current-dns.com
- DKIM public record check (replace selector):
dig +short TXT selector._domainkey.example.com @ns1.current-dns.com
dig +short TXT _dmarc.example.com @ns1.current-dns.com
bash
DOMAIN=example.com
SELECTOR=selector
NS_CURRENT=ns1.current-dns.com
echo "SPF:"
dig +short TXT ${DOMAIN} @${NS_CURRENT}
echo "DKIM:"
dig +short TXT ${SELECTOR}._domainkey.${DOMAIN} @${NS_CURRENT}
echo "DMARC:"
dig +short TXT _dmarc.${DOMAIN} @${NS_CURRENT}
These commands verify that the correct public records exist at the expected authoritative servers before and after transfer.
Sample DNS records to add (templates) 💾
example.com. TXT "v=spf1 include:spf.sendgrid.net include:_spf.google.com ip4:203.0.113.45 -all"
- DKIM (example selector "s1"):
s1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
- DMARC (example monitoring policy):
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-rua@example.com; ruf=mailto:dmarc-ruf@example.com; pct=100"
Always check record length limits and split long TXT records per DNS provider guidance.
Table: compare transfer tactics and impact 📊
| tactic |
complexity |
downtime risk |
recommended window |
| lower TTL only |
Low |
Moderate |
48–72 hours before transfer |
| dual-signing DKIM |
Medium |
Low |
During transfer + 48–72 hours after |
| full zone pre-seed |
High |
Low |
Immediate validation pre-transfer |
| DNSSEC enablement |
Medium |
Medium |
Preconfigured before transfer |
| rollback ready |
Low |
Minimal |
Always available |
Security: protect DKIM private keys and use DNSSEC 🛡️
- Store DKIM private keys in a secure secret store (Vault, KMS). Restrict administrative access with MFA and audit logs.
- Do not email or store private keys in plaintext. Use encrypted transit and at-rest protections.
- Where feasible, enable DNSSEC on the zone and verify DS records are correctly published at the registrar. DNSSEC reduces the risk of DNS tampering during transfer.
- For registrars that support transfer locks and two-step authorization, enable transfer protection to reduce risk of unauthorized takeover.
Reference protocols: consult official RFCs: IETF RFC 7208 (SPF), IETF RFC 6376 (DKIM), and IETF RFC 7489 (DMARC).
Monitoring and KPIs to watch during transfer 📈
- Authenticated percentage: ratio of messages passing SPF and DKIM (target > 98%).
- DMARC aggregate trends: sudden drops or spikes in failure rates.
- Bounce rate: any increase beyond baseline indicates misconfiguration.
- Spam-filter placements: increase in spam-folder placements from major providers.
- ruf forensic alerts: analyze if present but ensure privacy handling with ruf addresses.
Use Google Postmaster Tools and Microsoft SNDS for visibility: Google Postmaster, Microsoft SNDS.
- If mail failures appear immediately after transfer:
- 1) Repoint nameservers to previous authoritative provider (use saved zone file).
- 2) Restore TTLs if necessary and monitor.
- 3) Re-enable old DKIM selectors and ensure signing is applied.
- 4) Notify stakeholders and escalate to ESP vendors for inbound whitelisting if required.
- Communication template for stakeholders (short):
- Subject: Domain transfer authentication incident
- Body: Brief timeline, impact (deliverability affected), actions taken, expected next steps, contact.
A quick rollback to previous nameservers is often the fastest way to restore authentication while diagnosing the root cause.
Example practical: how it really works ⚙️
📊 Case details:
- Domain: example.com
- Current DNS provider: ns1.current-dns.com
- New DNS provider: ns1.new-dns.com
- Sending services: SendGrid (sg), internal SMTP (10.10.10.5)
🧮 Process:
- Day -3: TTL lowered to 300 for TXT and DKIM selectors.
- Day -2: New DKIM public key (selector s2) added to current DNS and both s1 and s2 verified with dig.
- Day 0: registrar updated to new nameservers. Both DKIM selectors present on new DNS.
- Day +1: DMARC reports show 99.2% SPF/DKIM pass. No increase in bounces.
✅ Result: No measurable deliverability degradation; old selector removed Day +4.
This simulation mirrors real-world timings: short TTLs, pre-seeding of DKIM public keys, and a 48–72 hour verification window provide a safe transition.
Infographics: visual checklist 🎯
Transfer checklist: email authentication
🔎 Inventory
List ESPs, selectors, MX, SPF includes, DMARC rua/ruf
⏱️ TTL plan
Lower to 300–600s 48–72h before transfer
🔐 DKIM dual-sign
Add new public key, sign with both selectors
📊 Monitor
Track DMARC rua, bounce, spam rates
↩️ Rollback ready
Keep previous zone and contact lists on hand
Timeline recommended schedule 🔁
Migration timeline (recommended)
7–3 days
Audit inventory and notify teams
72–48 hours
Lower TTLs and pre-seed DKIM
Day 0
Switch nameservers and validate DNS
Day 1–3
Monitor DMARC and keep dual-signing
Day 4–7
Retire old selectors and restore TTLs
Advantages, risks and common mistakes ⚠️
Benefits / when to apply ✅
- ✅ Low-risk continuity for high-volume transactional and marketing email during domain moves.
- ✅ Faster recovery if rollback is required due to pre-seeding and TTL strategy.
- ✅ Better observability by keeping DMARC reporting active during transition.
Errors to avoid ⚠️
- ⚠️ Removing old DKIM selectors too early.
- ⚠️ Forgetting to update third-party ESP DNS records or include: entries.
- ⚠️ Using weak DKIM keys (512-bit) or exposing private keys in insecure storage.
- ⚠️ Not lowering TTLs: leads to cached stale records and authentication failures.
Update third-party providers: checklist 💼
- Contact each ESP and third-party vendor and confirm the exact DNS record name, selector, and required MX/CNAME changes.
- For platforms with clickable DNS instructions (e.g., Google Workspace), follow the provider's verification flow and then add records to both old and new DNS during transfer.
- Use vendor support tickets to speed verification if issues occur.
Troubleshooting quick wins 🩺
- If DMARC shows SPF failures: check that the envelope-from aligns with SPF and the IPs are included.
- If DKIM fails: verify selector record exists and the public key matches private key used by signer.
- If widespread bounces: inspect bounce codes and check MX records at authoritative servers.
FAQ: common questions answered ❓
How long should TTL be before transfer?
Lower TTL to 300–600 seconds (5–10 minutes) at least 48–72 hours before the transfer for email-related records.
Can DKIM be rotated during transfer?
Yes. Publish the new public key before switching nameservers and use dual-signing; retire the old key after 48–72 hours of stable reports.
What if DMARC reports stop arriving after transfer?
Check DNS MX and TXT records for the _dmarc record on the new authoritative servers and verify that rua addresses are reachable; review DNS propagation via dig.
Is DNSSEC required to transfer safely?
DNSSEC is not strictly required but recommended; enabling DNSSEC before transfer reduces tampering risk but must be coordinated with the registrar.
How to validate SPF after transfer?
Use dig to fetch TXT records from authoritative nameservers and run an SPF parser (or online SPF tester) to ensure include chains resolve and length limits are respected.
What KPIs indicate a successful transfer?
Authenticated percentage (SPF/DKIM) >98%, stable bounce rate, and no spike in spam-folder placements are primary indicators.
Should DMARC policy be set to reject during transfer?
No. Set DMARC to p=none during transfer for monitoring; move to quarantine/reject only after stable authentication metrics are confirmed.
- Reduce TTLs to 300–600s for email-related records and confirm propagation.
- Pre-seed new DKIM public keys at the current DNS provider and enable dual-signing.
- Prepare rollback zone file, contacts, and monitoring dashboards for DMARC and bounce metrics.
References and further reading 📚
