Skip to content
← MailMaid Academy
Authentication

After a DNS change, verify what receivers can see

Short answer

There is no single propagation timer for every sender and resolver.

Save the change details#

Record the exact old and new values, their TTLs and when the change was made. Identify the authoritative zone and the DNS provider that actually serves it. Editing a stale zone can make every subsequent wait unproductive.

Observe instead of guessing#

Compare authoritative answers with the recursive resolver used by your diagnostic tool. Cached responses may differ during a transition. MailMaid’s DNS check reports one resolver observation; it cannot establish what every receiver sees.

Validate the sending path#

Once the intended records are visible, send through the affected service and inspect the receiver’s authentication results. Use that evidence alongside DNS. A policy record appearing in a lookup is not the same event as a message passing alignment.

Primary references

Consult the current specification or provider guidance when applying these checks.

DMARC specification

Keep reading

Authentication

Audit SPF without guessing at DNS

Build an inventory before editing the record.

2 min read
Authentication

BIMI, MTA-STS and TLS reporting: different layers

A logo record, transport policy and delivery report solve different problems.

2 min read
Authentication

DKIM simple and relaxed: diagnose message changes

Look for transformations between signing and receipt.

2 min read