Email DNS guide
Manage email DNS propagation without treating it as an instant switch.
DNS changes become visible through authoritative servers and resolver caches at different times. A safe email change identifies each record's role, TTL, verification evidence, and rollback value before editing.
Keep receiving and sending records separate
MX controls where inbound mail is delivered. Ownership TXT proves domain control to EmailDesk. SPF authorizes sending infrastructure for the envelope domain, DKIM publishes a provider-issued signing key, and DMARC evaluates aligned SPF or DKIM.
An outbound-only sender does not need an MX change merely to send. Likewise, changing MX does not authorize an outbound provider.
Read TTL as a cache window, not a deadline
A recursive resolver can reuse a cached answer until its TTL expires. Different resolvers may have fetched the old answer at different times, and negative answers can also be cached. The authoritative provider can also take time to publish a change across its own name servers.
Lowering TTL shortly before a cutover does not clear copies that were already cached with the previous higher TTL. Plan TTL changes at least one old cache window before the intended cutover when the provider permits it.
TTL 3,600 seconds = a resolver may reuse its cached answer for up to 60 minutes from when that copy was fetchedThis is a cache calculation, not a promise that every resolver will show the new record within exactly 60 minutes.
Publish one deliberate record set
Copy the existing records before editing. Publish the exact EmailDesk ownership value, intended MX priorities, one merged SPF policy, the provider-issued DKIM selector, and the reviewed DMARC policy at the authoritative DNS provider.
Do not publish a second SPF record. Preserve mechanisms for every legitimate sender that still operates, and do not tighten DMARC until all expected sending sources are aligned.
Verify authoritative and cached answers separately
First confirm the authoritative name servers return the intended values. Then check more than one public recursive resolver and rerun the separate EmailDesk domain requirements after the expected TTL window.
During an MX migration, monitor both old and new receiving systems until new delivery is consistently reaching the destination. For sending records, use a controlled test and inspect authentication plus provider evidence without assuming inbox placement.
- Check the exact host name, record type, value, and MX priority.
- Confirm public DNS returns only one SPF policy.
- Verify the active gateway's required SPF authorization and DKIM selector.
- Keep the prior values and service available through the agreed validation window.
Keep rollback and external control visible
EmailDesk can display required records and check public evidence, but it cannot force an external DNS provider or recursive resolver to refresh. Local cPanel DNS changes also have no effect when another provider is authoritative.
If the new record set is incorrect, restore the reviewed prior values where appropriate and revalidate. Another DNS change starts another cache transition; it does not instantly remove the incorrect answer from every resolver.
Frequently asked questions
Questions about this guide.
Why does one DNS checker show the new record while another shows the old value?
Different resolvers can hold copies fetched at different times. Confirm the authoritative answer first, then allow each recursive cache to expire.
Does lowering TTL immediately flush old DNS answers?
No. A resolver that already cached the old record can keep it for the old TTL. Lower the TTL in advance when planning a cutover.
Should I change MX to authorize EmailDesk sending?
No. MX controls inbound routing. Outbound authorization uses the sender identity and records such as SPF, provider-issued DKIM, and aligned DMARC.
Continue with evidence