DMARC Analyzer

TL;DR

• DNS propagation is the time for a new or updated record to become visible to recursive resolvers across the internet. It is bounded by the TTL of the record being replaced, not by any property of the new record itself.
• There is no propagation wave. Authoritative nameservers do not push records anywhere; recursive resolvers PULL records on demand and CACHE them for the TTL declared on the authoritative answer (RFC 1035 + RFC 2181).
• Propagation completes in approximately the previous TTL plus a small operational overhead. A 300-second TTL propagates within 5 minutes; a 3600-second TTL within 1 hour; the conservative DNS-provider default of 86400 seconds within 24 hours.
• "DNS not propagated yet" is the wrong diagnosis 95 percent of the time. The actual cause is usually a wrong DNS label (DMARC records live at _dmarc.example.com, not example.com), a wrong DNS provider zone, a stale negative cache, or a record- syntax mistake. Dig the authoritative nameserver directly to bypass caches.
• Email-auth TTL recommendations: 300 seconds for DKIM keys being rotated; 3600 seconds for stable SPF and DMARC records; 86400 seconds for static BIMI and MX records. Avoid the 86400-second DNS-provider default for records you actively manage.
• Verification workflow: dig against three independent recursive resolvers (8.8.8.8 Google, 1.1.1.1 Cloudflare, 9.9.9.9 Quad9); dig +trace to confirm the authoritative answer; dig directly against the authoritative nameserver IP to bypass all recursive caches.
• CDN-proxied records carry overridden TTLs (Cloudflare returns a 5-minute TTL on every proxied record regardless of the operator-set TTL). DMARC and DKIM TXT records are not proxied by default and respect the operator-set TTL.
• Short TTLs enable fast emergency rollback. A 300-second TTL on a DKIM key lets a compromised key be revoked across the internet within five minutes. A 86400-second TTL leaves a 24-hour window of exposure.

1. Overview: what DNS propagation actually means

DNS propagation is the most-asked operator question when a freshly-published DMARC, SPF, DKIM, BIMI, MTA-STS, or TLS-RPT record does not appear to be working as expected. The framing of the question ("why has my record not propagated yet?") usually embeds a model of DNS that does not match the actual protocol: a sense that authoritative nameservers somehow push or distribute new records across the internet, and that propagation is a server-to-server process that takes hours or days to complete.

The actual protocol behaviour is much simpler. Authoritative nameservers (the servers operated by the domain owner or its DNS provider) hold the source-of-truth records for a zone and do not push anything to anyone. Recursive resolvers (the DNS servers operated by ISPs, public-DNS providers, and corporate networks) PULL records on demand whenever a client asks for a name they do not already have cached. The authoritative answer is stamped with a TTL (time-to-live) value that tells the recursive resolver how long the answer is valid. The recursive resolver caches the answer for the TTL duration and serves subsequent queries from cache; when the TTL expires, the next query triggers a fresh authoritative lookup.

"DNS propagation" is therefore not a server-to- server distribution wave. It is the resolver-cache-aging process by which recursive resolvers around the internet eventually re-query the authoritative nameserver and discover the new record. The maximum time for any given recursive resolver to discover the change is bounded by the TTL of the previously-cached record, not by any property of the new record itself. A resolver that has not cached any previous answer for the name sees the new record on its very first query.

This page is the cross-cutting operational reference for the help cluster on DNS propagation mechanics. For specific email-auth record syntaxes, see the pillar pages (DMARC record tags, SPF explained, DKIM explained); for live record verification against your domain, see the Domain Security Checker; for the operational rollback implications of long TTLs, see the DKIM key rotation deep dive whose canonical procedure assumes 300-second TTLs.

2. DNS propagation is not a wave — it is resolver-cache aging

The marketing-era term "DNS propagation" embeds a distribution-network mental model that is fundamentally wrong about how the DNS protocol works. Authoritative nameservers do not push, do not distribute, do not synchronize records across the internet, and do not have any notion of "neighbouring" resolvers. The authoritative server is a passive query-response engine: a recursive resolver sends a query; the authoritative server returns the current record with its current TTL; the conversation ends.

The reason a freshly-published record appears to take time to "propagate" is that recursive resolvers across the internet may have a previously-cached version of the name and refuse to re-query until the cached TTL expires. The recursive resolver makes this decision independently from every other recursive resolver in the world: each cache ages at its own pace, based on when each resolver happened to last query the authoritative server and what TTL was in effect at the time of that query.

The practical consequence is that propagation is not synchronous. A single user querying the same record from two different networks (home, mobile, corporate office) may see different cached answers at the same moment in time. This is not a bug or a delay or a propagation problem; it is the entire designed behaviour of internet DNS. The bounded-but-asynchronous propagation model is what makes DNS scale to billions of names without requiring any kind of distributed-consensus coordination protocol.

The corollary is that asking "has the record propagated yet?" without specifying "from which resolver's perspective?" is incoherent. A useful diagnostic always names the resolver being queried. The DMARC Analyzer Domain Security Checker queries an authoritative-perspective lookup so the answer reflects the current authoritative state, bypassing the recursive-cache layer.

3. TTL mechanics (RFC 1035 + RFC 2181)

The TTL (time-to-live) field on a DNS record is a 32-bit unsigned integer expressing the number of seconds a recursive resolver MAY cache the record before re-querying. The TTL is defined in RFC 1035 section 4.1.3 and clarified in RFC 2181 section 8 (which mandates that the TTL is a property of the resource record SET, not of individual records within the set).

The authoritative TTL is the upper bound on cache lifetime. A recursive resolver MAY cache for less time than the TTL declares (some resolvers impose a maximum TTL cap of 24 hours or 7 days to protect against runaway TTL values) but MUST NOT cache for longer than the TTL declares. The practical implication is that operator-set TTL values are the LONGEST time the operator must wait for a change to propagate; the actual propagation time is often shorter because some resolvers cap aggressively or had not cached the previous value at all.

The TTL applied to a recursive-resolver cache entry is the TTL the AUTHORITATIVE server returned at the time of the original query. If the operator changes the TTL from 86400 to 300, that change itself is subject to the existing cached record: resolvers that cached the 86400-TTL value before the change still cache until the 86400 expires; only after they re-query do they observe the new 300-second TTL. This is the structural reason DKIM key rotation procedures lower the TTL well in advance of the actual rotation: the TTL-reduction must propagate BEFORE the key rotation can take advantage of the shorter TTL.

Negative caching (caching of "name does not exist" responses) is governed by the SOA record's MINIMUM field per RFC 2308. A DNS query for a name that does not yet exist returns a negative-cache entry that the resolver holds for the SOA MINIMUM duration. This is why a brand-new record can appear to "not propagate" even though no previous version existed: resolvers may be serving a cached NXDOMAIN response from an earlier query against the same name. The SOA MINIMUM should be set low (300 to 3600 seconds) for any zone where new records are added frequently.

4. Authoritative nameservers vs recursive resolvers vs stub clients

Internet DNS has three operational roles that interact during every name lookup:

• Authoritative nameservers hold the source-of-truth records for one or more zones. The domain owner (or its DNS provider) operates the authoritative servers and defines what records exist and what TTL each record carries. Examples: AWS Route 53, Cloudflare DNS, Google Cloud DNS, NS1, AzureDNS, self-hosted BIND. The authoritative servers are listed in the NS records of the parent zone (the registry's nameservers for example.com publish NS records delegating to the operator's authoritative servers).
• Recursive resolvers operate the cache layer between authoritative servers and end-user clients. ISPs operate recursive resolvers for their subscribers; public-DNS providers operate them for the world (Google Public DNS at 8.8.8.8, Cloudflare at 1.1.1.1, Quad9 at 9.9.9.9, OpenDNS at 208.67.222.222, AdGuard at 94.140.14.14). Corporate networks often run internal recursive resolvers for their employees. The recursive resolver follows the delegation chain from the root down to the authoritative nameserver for the requested name, caches the result for the declared TTL, and returns the answer to the client.
• Stub clients are the operating system or application code on end-user devices that needs name resolution. The stub configures one or more recursive-resolver IPs in /etc/resolv.conf (Linux), DHCP-supplied DNS settings (Windows), or OS-managed defaults (macOS, iOS, Android, Chrome OS). The stub sends queries to its configured recursive resolver and accepts whatever the resolver returns. The stub does not perform recursion itself and does not contact authoritative servers directly.

Some clients introduce additional layers: DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) encrypt the stub-to-resolver path, but do not change the underlying caching model. Web browsers increasingly use DoH to a browser-selected resolver (Chrome and Firefox default to using DoH to Cloudflare or NextDNS) which can BYPASS the OS-configured resolver entirely; this is why "I set my DNS to my router" may not affect what DNS the browser actually uses. Application-layer DNS (browser-built-in DoH) is invisible to OS-level cache-flushing.

5. The actual propagation timeline

For a record being CHANGED from an existing value to a new value, the propagation timeline is:

1. T=0: operator publishes the new record at the authoritative server. The new record is immediately visible to any recursive resolver that queries the authoritative server starting now.
2. T=0 to T=<old TTL>: split-brain period. Recursive resolvers that had cached the OLD record before T=0 continue to serve the old record until their cache entries expire. Recursive resolvers that either never cached the old record or that cached it long enough ago that their cache has already expired return the NEW record on their first query. The two populations of resolvers serve different answers simultaneously.
3. T=<old TTL>: all caches have expired. All recursive resolvers that previously cached the old record now re-query the authoritative server on their next client request and pick up the new record. Propagation is effectively complete across all cache-respecting resolvers.
4. T=<old TTL> + epsilon: operational complete. The small epsilon accounts for clock skew between resolvers, the round-trip time for the authoritative query, and any resolvers using non-conforming cache extension behaviour (RFC 8767 serve-stale, used by Cloudflare and some others, can serve a stale answer beyond the TTL if the authoritative server is unreachable — usually irrelevant for propagation timing).

For a record being NEWLY ADDED (no previous record at the name), the propagation timeline is bounded by the SOA MINIMUM (negative-cache TTL, typically 300 to 3600 seconds on well-managed zones, up to 86400 on conservatively configured zones). Resolvers that had cached an NXDOMAIN response for the name continue to serve NXDOMAIN until the negative cache expires; resolvers that never cached an NXDOMAIN see the new record immediately.

For a record being DELETED (no replacement), propagation completes within the old record's TTL. Resolvers that had cached the old record serve it until expiry; on re-query they receive NXDOMAIN and cache that response for the SOA MINIMUM.

6. The operator verification workflow

To verify a record's propagation state across the internet, use the following workflow:

1. Confirm the authoritative state. Query the authoritative nameserver directly to confirm the record exists at the right name with the right value. Find the authoritative servers via dig +short NS example.com, then query directly: dig @ns1.dnsprovider.com _dmarc.example.com TXT. This bypasses all recursive-resolver caches and confirms the source of truth.
2. Confirm public-DNS visibility. Query against the three major public recursive resolvers to confirm the record is visible from the perspective of the most- used internet caching infrastructure: dig @8.8.8.8 _dmarc.example.com TXT (Google Public DNS), dig @1.1.1.1 _dmarc.example.com TXT (Cloudflare), dig @9.9.9.9 _dmarc.example.com TXT (Quad9). If all three return the new record, propagation is effectively complete across the largest cache footprint.
3. Confirm the delegation chain. Run dig +trace _dmarc.example.com TXT to follow the delegation from the root servers (a.root-servers.net etc.) through the TLD nameservers (a.gtld-servers.net for .com) to the authoritative servers for the zone. Confirm each step returns the expected NS records and that the final answer comes from the authoritative server, not from a recursive cache.
4. Confirm the answer TTL. Inspect the TTL field in the dig output: dig _dmarc.example.com TXT | grep -A1 ANSWER. The TTL field shows the REMAINING cache lifetime, not the original TTL: a 3600-second TTL queried 1000 seconds ago will show 2600 seconds remaining. If the TTL is decreasing on successive queries, the answer is being served from a cache that has not yet expired.
5. Flush local caches if needed. On Windows: ipconfig /flushdns. On macOS: sudo killall -HUP mDNSResponder. On Linux with systemd-resolved: sudo resolvectl flush-caches. Flushing only affects the local stub/cache layer and does NOT propagate to ISP or public-DNS recursive resolvers.

The DMARC Analyzer Domain Security Checker performs the equivalent multi-resolver lookup for SPF, DKIM, DMARC, BIMI, MTA-STS, and TLS-RPT records and reports both the authoritative-perspective state and the public- resolver-cache state in a single view, sparing the operator the manual dig invocations.

7. Recommended TTLs for email-authentication records

Different email-authentication record types have different operational change frequencies and therefore different recommended TTLs:

• DKIM public-key records: 300 seconds (5 minutes). DKIM keys are rotated periodically (monthly, quarterly, or in response to compromise) and a short TTL bounds the time required to revoke a compromised key. See DKIM key rotation for the canonical procedure.
• SPF records: 3600 seconds (1 hour). SPF records change infrequently (when adding or removing a sending source) and one hour balances cache-efficiency against operational agility.
• DMARC records: 3600 seconds (1 hour). DMARC policy changes (moving from p=none through p=quarantine to p=reject) typically happen on a deliberate timeline; one hour allows for quick rollback if the change causes unexpected damage. See DMARC policy rollout.
• BIMI records: 3600 to 86400 seconds (1 hour to 24 hours). BIMI records reference a static SVG logo and a VMC that rarely change, but logo updates should propagate quickly enough for branding consistency.
• MTA-STS DNS records: 3600 seconds. The MTA-STS policy ID (v=STSv1; id=...) changes when the policy file is updated, and operators benefit from fast propagation of the policy-version pointer.
• TLS-RPT records: 86400 seconds (24 hours). TLS-RPT reporting endpoints are stable for long periods.
• CAA records: 3600 seconds (1 hour). CAA records authorize specific certificate authorities; the issuance decision happens at the time of certificate request, and an hour-scale TTL ensures emergency CAA changes propagate before the next certificate renewal.
• MX records: 3600 to 86400 seconds. MX records define where mail for a domain is delivered and rarely change; longer TTLs improve sender-side cache efficiency.

The operational rule of thumb: set the TTL to the longest value you would accept waiting if you needed to roll the record back. If you can accept a 5-minute rollback window, use 300; if you can accept a 1-hour window, use 3600; if you can accept 24 hours, use 86400. Avoid the conservative DNS-provider UI default of 86400 on records you actively manage.

8. Emergency rollback and the case for short TTLs

The single best argument for short TTLs on actively-managed email-auth records is emergency rollback. When a change causes an incident (DMARC p=reject rolled out too aggressively and now legitimate mail is bouncing; a DKIM private key is suspected of compromise; an SPF record breaks because a sending source is missing) the operator's ability to revert is bounded by the TTL of the bad record. A 300-second TTL means the bad record is fully revoked across the internet within five minutes of publishing the rollback; a 86400-second TTL means a 24-hour exposure window during which receivers continue to apply the bad policy.

The classic rotation pattern for any actively-managed record is:

1. T = -2 × old TTL: lower the TTL. Publish the EXISTING record with the new shorter TTL. Wait two TTL cycles so the TTL change itself propagates across all recursive caches.
2. T = 0: publish the change. Publish the actual record change. Now bounded by the new shorter TTL.
3. T = +1 short TTL: confirm propagation. Verify the change via the multi-resolver workflow in section 6.
4. T = +<stable period>: raise the TTL back. Once the change is stable and you have no further changes planned, raise the TTL back to a longer value for cache efficiency.

The same pattern applies to DKIM key rotation, DMARC policy transitions, SPF source additions and removals, MTA-STS policy-ID changes, and any other operationally-critical record. The pre-emptive TTL reduction is the single most important step; without it, the short TTL on the new record is irrelevant because resolvers still cache the OLD long-TTL response until it expires.

9. DNS provider quirks that affect propagation

• Cloudflare proxied records: Any record marked "Proxied" (orange-cloud icon) in the Cloudflare DNS UI has its public-facing TTL forced to 300 seconds (5 minutes) regardless of the operator's TTL setting, because the public answer is a Cloudflare edge IP rather than the origin. DMARC, SPF, DKIM, BIMI, MTA-STS, and TLS-RPT TXT records are NOT proxied by default and respect the operator-set TTL.
• AWS Route 53 alias records: Alias records (Route 53's extension for pointing to AWS resources without an extra DNS hop) inherit the TTL from the target resource (ELB, CloudFront, S3) and ignore any operator-set TTL on the alias itself. Plain TXT records used for email auth respect the operator-set TTL normally.
• NS1 traffic management: NS1's filter chains and traffic-management rules can dynamically compute the answer per query, with TTLs that vary by filter. Email-auth TXT records served through plain NS1 DNS respect the operator-set TTL.
• GoDaddy + Namecheap UI defaults: The default TTL on the registrar UIs of both GoDaddy and Namecheap is conservative (1 hour or longer). Operators must explicitly change the TTL in the UI when creating new records.
• Microsoft 365 / Google Workspace partner DNS: Some Microsoft 365 and Google Workspace deployments use partner-managed DNS where the M365 or Workspace admin console writes records into the customer's DNS provider on the operator's behalf. TTLs on these partner-written records vary by provider; check the actual TTL via dig rather than assuming the configured TTL is honored.
• DNSSEC-signed zones: DNSSEC adds RRSIG records that have their own TTLs. The signed record set's propagation is bounded by the longer of the record's TTL and the RRSIG's TTL. DNSSEC-related propagation issues usually surface as SERVFAIL responses from validating recursive resolvers rather than as stale-cache issues.

10. Common misconceptions about DNS propagation

• "DNS propagation takes 24-48 hours." False as a general rule. The 24-48 hour folk-wisdom reflects the conservative DNS-provider default TTL of 86400 seconds (24 hours) and a worst-case cache scenario. Modern operators publish short TTLs on actively-managed records and see propagation in 5 to 60 minutes.
• "My ISP is slow to propagate." ISP recursive resolvers do not propagate anything; they cache. If the ISP's recursive resolver has cached a previous value, it serves the cached value until expiry. The cache lifetime is controlled by the ORIGINAL operator's TTL, not by the ISP.
• "I need to wait for global propagation before testing." False. Test against the authoritative server directly to verify the change is published correctly; test against the recursive resolvers you actually care about (typically Gmail and Outlook for email-auth purposes — their recursive resolvers are the ones that matter for inbox delivery).
• "DNS propagation depends on the new record's TTL." False. The propagation timeline is governed by the OLD record's TTL (the one being replaced) and the negative-cache TTL (the SOA MINIMUM). The new record's TTL only affects FUTURE changes.
• "Flushing my browser cache fixes DNS propagation." False. Browser caches are short (typically 1 to 5 minutes) and orthogonal to recursive-resolver caches. If you are testing whether a public resolver has picked up the new record, browser-cache flushing is irrelevant.
• "DNS changes affect the authoritative server's IP, not just the record." False (in normal operation). The authoritative server's IPs are determined by the NS records of the parent zone, set at the registrar level. Changing a record within a zone changes nothing about the nameserver IPs. Changing the nameserver IPs (delegation change) is a separate operation that follows a different propagation timeline at the registry level.

11. Troubleshooting "the record is not working"

When a freshly-published email-auth record does not appear to be working, work the diagnostic funnel from outside-in:

1. Is the record published at the right name? DMARC lives at _dmarc.example.com; DKIM lives at selector._domainkey.example.com; SPF lives at example.com; BIMI lives at default._bimi.example.com; MTA-STS DNS lives at _mta-sts.example.com; TLS-RPT lives at _smtp._tls.example.com. Querying the wrong name returns NXDOMAIN regardless of how long ago the record was published.
2. Is the record published in the right zone? If the domain's NS records delegate to one DNS provider but the operator edited records at a different provider's UI, the changes are invisible because no recursive resolver ever queries the second provider. Check dig +short NS example.com to confirm where the zone actually lives.
3. Is the record syntactically correct? Common mistakes: unbalanced quotes, missing semicolons, typos in DMARC tag values (p=qurantine instead of p=quarantine), missing v=DMARC1 or v=DKIM1 version anchor, BIMI records missing v=BIMI1.
4. Is the authoritative server returning the record? dig @ns1.dnsprovider.com _dmarc.example.com TXT confirms the authoritative state directly. If this returns the wrong answer, the problem is in the DNS provider UI; if it returns the right answer, the problem is downstream.
5. Are the public resolvers returning the record? dig against 8.8.8.8 / 1.1.1.1 / 9.9.9.9. If all three return the new record, propagation is effectively complete. If they return the old record, wait for the old TTL to expire or accept the split-brain period as expected behaviour.
6. Is the actual email problem caused by DNS, or by something else? The DMARC Analyzer's aggregate-report stream (RUA) is the authoritative source for what receivers are actually observing. If the record is correctly published and visible but RUA reports still show dkim=fail or spf=fail, the cause is not DNS propagation but a problem in the email infrastructure (wrong signing key, wrong From: domain, intermediate MTA breaking canonicalization, etc.).

12. FAQ — common questions about DNS propagation

What is DNS propagation?

DNS propagation is the operational term for the time it takes a new or updated DNS record to become visible to recursive resolvers across the open internet. Technically there is no propagation wave: recursive resolvers PULL records on demand and CACHE them for the TTL duration. A new record is visible immediately to any resolver that had not previously cached the name, and visible after cached values expire to resolvers that had cached a previous value. The maximum propagation time is bounded by the OLD record's TTL.

How long does DNS propagation take?

Approximately the TTL of the record being replaced, plus small overhead. A 300-second TTL propagates within 5 minutes; a 3600- second TTL within 1 hour; the conservative DNS-provider default of 86400 seconds within 24 hours. The folk-wisdom "24 to 48 hours" reflects the worst case where the previous record had a long TTL.

Why is my DMARC record not propagating?

"DNS not propagated yet" is the wrong diagnosis 95 percent of the time. Common actual causes: wrong DNS label (DMARC must be at _dmarc.example.com), wrong DNS provider zone, stale negative cache, record-syntax mistake, or the previous record had a long TTL still being cached. Dig the authoritative nameserver directly to confirm the published state.

How do I check if DNS propagation is complete?

Query against three independent public recursive resolvers (8.8.8.8 Google, 1.1.1.1 Cloudflare, 9.9.9.9 Quad9) and compare results. If all three return the new record, propagation is effectively complete across the major public-DNS infrastructure. For a definitive check, dig +trace from the root or dig directly against the authoritative nameserver IP.

What TTL should I set for email authentication records?

300 seconds for DKIM keys being rotated; 3600 seconds for stable SPF and DMARC records; 86400 seconds for static BIMI and MX records. Avoid the conservative DNS-provider default of 86400 on records you actively manage.

Why does dig show the record but my email is still failing?

If dig confirms the record is published but email authentication is still failing, the problem is not DNS propagation. Common causes: receiving MTA cached the previous lookup, record-syntax errors, wrong DNS hierarchy, the sending source is not authorised by SPF or signed by DKIM, or the receiver caches DMARC policy aggressively. Use the DMARC Analyzer RUA stream as the authoritative diagnostic.

How do I flush my local DNS cache?

Windows: ipconfig /flushdns. macOS: sudo killall -HUP mDNSResponder. Linux with systemd-resolved: sudo resolvectl flush-caches. Linux with nscd: sudo systemctl restart nscd. Flushing local caches does NOT propagate to ISP or public-DNS recursive resolvers.

Do CDN-proxied records propagate differently?

Yes. Cloudflare-proxied DNS records carry a fixed 5-minute TTL on the public-facing record regardless of the operator's TTL setting because the public answer is a Cloudflare edge IP. DMARC and DKIM TXT records are not proxied by default and respect the operator-set TTL.

13. Related guides

• DMARC record tags explained — every tag in the DMARC DNS record. DMARC records live at _dmarc.example.com and propagate per the rules on this page.
• Email security glossary — the DNS-PROPAGATION-AND-TTL-CACHE- COHERENCE-VOCABULARY-RESOLVES-TO-CROSS- CLUSTER-EMAIL-SECURITY-TERMINOLOGY-HUB companion to this DNS-propagation timing reference. Where THIS page documents the per-publisher per-zone DNS-propagation mechanics (per-RR TTL-bounded cache-fill cycle, per-resolver authoritative-vs- recursive resolution path, per-zone NS- delegation publication discipline, per- zone SOA-serial increment-discipline, per-RR negative-caching SOA-minimum-TTL bounding, per-publisher publish-and-verify propagation-window), the email-security- glossary spoke is the cross-cluster TERMINOLOGY-RESOLUTION reference whose per-term canonical definitions establish the shared vocabulary every DNS-publication- discipline discussion structurally depends on at FOUR per-term vocabulary-resolution dimensions: (i) per-term TTL-and- cache-coherence vocabulary canonical- definition reference — the glossary resolves per-RR TTL-vocabulary (TTL, cache-fill, negative-caching, SOA- minimum-TTL, per-resolver cache-eviction) without per-page re-definition; per- publisher operator cross-record-type propagation-coordination depends on consistent per-term TTL-vocabulary across every sibling SPF / DKIM / DMARC / MTA- STS / DANE / TLS-RPT / CAA spoke; (ii) per-term authoritative-vs- recursive-resolver vocabulary canonical- definition reference — the glossary resolves per-resolver-class vocabulary (authoritative resolver, recursive resolver, resolver-side cache, cache-fill latency, glue record, zone- cut, NS-delegation chain) so per- publisher operator cross-publisher per- receiver DNS-publication coordination preserves per-term resolver-class semantics across every sibling DNS- based-record spoke; (iii) per- term zone-publication-discipline vocabulary canonical-definition reference — the glossary resolves per-zone-publication vocabulary (apex record, subdomain record, wildcard record, CNAME-target chain, SOA serial, zone-version) so per-publisher operator cross-zone publication-coordination preserves per-term zone-publication- discipline semantics across every sibling SPF / DKIM-selector / DMARC-subdomain / MTA-STS / TLS-RPT publication spoke; (iv) per-term cross-protocol per-RR-class propagation-coordination vocabulary canonical-definition reference — the glossary resolves per-RR-class propagation- coordination vocabulary (per-publisher per-zone propagation-window, per-publisher per-RR cutover-coordination, per-publisher per-RR rollback-discipline, per-RR-class propagation-coupling) so per-publisher operator cross-protocol per-RR-class propagation-coordination preserves per- term cross-protocol propagation-coupling semantics across every sibling SPF-record cutover / DKIM-key rotation / DMARC- policy ramp / MTA-STS policy-rotation / TLS-RPT cadence spoke.
• DKIM alignment with DMARC — the DKIM-CNAME-DELEGATION-PROPAGATION- WINDOW-GATES-DKIM-ALIGNMENT-PASS-VERDICT companion to this DNS-propagation reference. Where THIS page documents the propagation mechanics (TTL-bounded publish-and-verify cycles, per-resolver cache-fill timing, authoritative-vs-recursive resolution path), the DKIM-alignment spoke is the RECEIVER-SIDE-DOWNSTREAM-CONSUMER of the DKIM-CNAME-delegation propagation whose alignment-pass-verdict is the load-bearing DMARC-evaluation outcome the propagation cycle gates. The DKIM-CNAME- DELEGATION-PROPAGATION-GATES-ALIGNMENT- VERDICT cross-reference establishes FOUR structurally-distinct DKIM-CNAME- propagation-dimension consumers: (i) per-selector CNAME-delegation chain propagation at publisher rotation boundary — when publisher rotates from selector1._domainkey.example.com to selector2._domainkey.example.com, the new selector's CNAME-delegation chain must propagate to the receiver's resolver BEFORE the signing-platform starts emitting messages signed with selector2; until propagation completes, receivers resolving the new selector at the OLD authoritative cache produce dkim=temperror or dkim= permerror, which collapses dkim-alignment=pass to dkim-alignment=fail per the spoke's evaluation rule; (ii) third-party-signer CNAME-delegation propagation at tenant- onboarding boundary — M365 / Google Workspace tenants onboarding new third- party signing platforms (SendGrid, Mailgun, Mailchimp) typically delegate s1._domainkey.example.com CNAME s1.domainkey.<platform>.com; the CNAME-delegation propagation window determines WHEN the third-party signer can start emitting platform-signed messages that achieve dkim-alignment=pass at the receiver (before propagation: dkim= none or dkim=temperror → dkim- alignment=fail; after propagation: dkim= pass + dkim-alignment=pass per the spoke's evaluation rule); (iii) per-receiver propagation timing skew producing aggregate-report DKIM-alignment-rate-divergence — different receivers (Gmail, Outlook.com, Yahoo, ProtonMail) operate independent resolver hierarchies with independent cache TTLs; during a DKIM-CNAME propagation window, the publisher's aggregate-report data shows DKIM-alignment- pass rates DIVERGING per-receiver (Gmail receives the new CNAME first → 95%+ DKIM-alignment-pass for Gmail-routed mail; Outlook.com 24 hours later → still at 60% alignment-pass) — the spoke documents this per-receiver alignment- rate-divergence pattern as a per-receiver DNS-propagation-window signature visible in the publisher's aggregate-report analysis; (iv) DKIM-alignment-pass-rate ramp predictability bounded by DNS propagation TTL contract — the publisher's expected DKIM-alignment-pass- rate ramp during a key-rotation or new- third-party-onboarding window is BOUNDED by the DNS TTL contract THIS page documents (worst-case propagation completes within MAX(TTL across all authoritative resolvers in the chain) — typically 24-48 hours for the global receiver population); the spoke's DKIM-alignment evaluation rule applied to the publisher's RUA-stream provides the empirical observation channel that confirms propagation completion has actually achieved its expected alignment-pass-rate-ramp outcome. Read the DKIM-alignment-with-DMARC spoke alongside this DNS-propagation reference when planning DKIM key-rotation or third-party-signer onboarding — the spoke documents the receiver-side evaluation rule whose per-CNAME-delegation propagation-window-aware ramp behaviour the publisher must observe in RUA data to confirm propagation has reached the expected alignment-floor.
• DKIM DNS TXT-record byte syntax — the DKIM-KEY-MATERIAL-PROPAGATION-WINDOW- CONSUMER companion documenting the byte- syntax of the DKIM public-key TXT record published at <selector>._domainkey.<domain> — the v=DKIM1; k=rsa; p=<base64> record form, the 255-byte chunk-boundary concatenation rule per RFC 1035 §3.3.14, the t=y testing-mode flag, the h=sha256 hash-algorithm acceptance list — whose PROPAGATION through the DNS infrastructure documented on THIS page is the operational gating constraint between a publisher's DKIM key-generation moment and the receiver's first successful DKIM verification of mail signed with that key. Where THIS page documents the propagation MODEL (SOA serial-number bump, per-zone refresh interval, secondary name- server polling, resolver-cache TTL countdown, the typical 48-hour propagation- completion rule of thumb, the dig +trace verification workflow), the DKIM-DNS-syntax spoke documents the BYTE-CONTENT being propagated and the byte-syntax that must be preserved end-to-end through the propagation path. The four-axis DKIM-KEY-PUBLICATION-VS- PROPAGATION-WINDOW comparison exposes the structurally-distinct OPERATIONAL-RISK roles: (i) the DKIM key-rotation overlap-window operator pattern (publish new selector → wait propagation window → switch signing to new selector → wait full TTL window → withdraw old selector) depends EXCLUSIVELY on the propagation model documented on THIS page — the overlap window must be at least 2 × max(zone-TTL, resolver-cache- TTL) per the propagation rules on this page; the DKIM-DNS-syntax spoke documents the BYTE-SYNTAX of the new selector's TXT record that must be published correctly BEFORE the propagation window begins; (ii) multi-string DKIM TXT records (where the base64-encoded public key exceeds the 255-byte chunk limit) propagate as concatenated adjacent-quoted-string DNS-master-file syntax — but some DNS hosting providers' web UIs misrepresent multi-string records as a single concatenated value during editing; the DKIM-DNS-syntax spoke documents the canonical multi-string byte-syntax, and the propagation-model rules on THIS page determine when the propagated record will be observable to receivers; (iii) the dig +short TXT <selector>._domainkey.<domain> verification command documented on THIS page is the canonical propagation- completion check for the DKIM key-material the spoke documents; operators rotating DKIM keys MUST verify the new selector resolves correctly via dig @8.8.8.8 / dig @1.1.1.1 / dig @9.9.9.9 across multiple resolver vendors before activating signing with the new key, per the propagation- verification workflow on THIS page; (iv) DKIM key-publication failures that do NOT propagate (DNS-provider auto- formatting corruption, missing v=DKIM1 tag, oversized TXT record exceeding DNS UDP-response budget, wrong record type — A vs TXT — at the selector label) produce permanently-undelivered DKIM key material regardless of propagation window length; the DKIM-DNS-syntax spoke documents the byte-syntax failure modes that NO amount of propagation-waiting can repair. Read the DKIM-DNS-syntax spoke when an operator says "the new DKIM selector should have propagated by now but receivers still fail verification" — the question is usually answered by checking the byte-syntax of the published TXT record (the DKIM-DNS-syntax spoke's domain) BEFORE re-checking propagation windows (THIS page's domain).
• DMARC for cPanel — the cPanel-tenant deployment guide (the DNS-PROPAGATION-TIMING-FOR-CPANEL-ZONE-EDITOR companion to this propagation reference) — the DNS-PROPAGATION-TIMING-FOR-CPANEL-ZONE-EDITOR companion documenting the cPanel-tenant-specific deployment workflow whose primary DNS interaction is via the cPanel Zone Editor — propagation timing is the load-bearing operational concern when publishing the _dmarc.<domain> TXT record from cPanel's UI. Where THIS page documents the DNS-propagation MODEL (the SOA serial-number bump, the per-zone refresh interval, the secondary name-server polling rhythm, the resolver-cache TTL countdown, the typical propagation-completion-within-48-hours rule of thumb, the dig +trace / dig @8.8.8.8 / dig @1.1.1.1 propagation-verification workflow), the dmarc_for_cpanel spoke is the CPANEL-SPECIFIC DEPLOYMENT REFERENCE documenting how the operator initiates the propagation window via cPanel's Zone Editor — the cPanel-specific propagation-affecting steps the cross-reference makes explicit: (i) the cPanel Zone Editor "Manage" → "Add Record" flow is what bumps the SOA serial number documented on THIS page; (ii) cPanel's default 14400-second (4-hour) TTL is what determines the propagation window for cPanel-managed zones — operators must lower TTL to 300 seconds 48 hours BEFORE the DMARC ramp per THIS page's TTL-discipline guidance; (iii) cPanel WHM-tier vs reseller-tier DNS publication paths differ — the WHM operator has direct named/BIND access while the reseller-tier operator only has Zone Editor UI; both paths trigger the same propagation model but the WHM operator can also force an rndc reload to skip the zone-refresh interval; (iv) cPanel with external DNS hosting (Cloudflare, Route 53 fronting a cPanel server) means the cPanel Zone Editor is inactive and DNS publication propagates per the external provider's propagation model documented in THIS page's per-provider section. Read the cPanel deployment spoke when the operator is on a cPanel-managed server — the spoke contextualizes every propagation-window step on THIS page to the cPanel UI surface.
• DMARC for shared hosting — the DNS-AUTHORITY-DELEGATION-AT-SHARED- HOSTING-PROVIDER-MANAGED-NAMESERVERS-VS- OPERATOR-OWNED-NAMESERVERS companion to this DNS-propagation TTL-bounded publish-and-verify cycle reference. Where THIS page documents the canonical operator- controlled DNS-propagation model (the SOA serial-number bump, the per-zone refresh interval, the secondary nameserver polling rhythm, the resolver-cache TTL countdown, the per-record TTL choice as the operator's per-stream propagation-window-control primitive), the shared-hosting spoke is the per-provider deployment companion documenting FOUR shared-hosting-DNS- authority-delegation dimensions: (i) shared-hosting provider-managed nameservers as the OPERATOR-EMPOWERMENT- CEILING — many cPanel / Plesk / DirectAdmin tenants delegate their domain's NS records to provider-managed nameservers (ns1.<provider>.com / ns2.<provider>.com), removing direct operator control over the SOA serial-number cadence and per-zone refresh interval that gate every DMARC / SPF / DKIM publication cycle — the shared-hosting spoke documents the canonical OPERATOR-EMPOWERMENT-CEILING where the per-zone-refresh-cadence is provider-managed (typically a 15-60- minute provider-side polling rhythm rather than the operator's preferred sub-minute publish-and-verify cycle) and the per-provider escalation paths to operator-managed nameservers (Cloudflare-as-DNS-only delegation, Route 53 / DigitalOcean / external-DNS- provider delegation, in-house BIND / PowerDNS / NSD operator-managed infrastructure); (ii) shared- hosting per-record TTL ceiling — many shared-hosting providers enforce a per-record TTL FLOOR (typically 14400-86400 seconds, 4-24 hours) that operators cannot lower below the provider's policy ceiling, removing the per-stream operator-controlled short-TTL-during-migration discipline operators in dedicated-DNS environments rely on — the shared-hosting spoke documents the canonical operator-side migration- cycle constraint where the shared- hosting TTL ceiling extends the publish-and-verify cycle from the operator's preferred sub-hour cadence to the provider-enforced 4-24-hour cycle, gating per-stream incident- response timelines at the shared- hosting boundary; (iii) shared-hosting zone-edit UI vs DNS- zone-source access — many shared- hosting control panels expose a constrained zone-edit UI (Plesk DNS Settings, cPanel Zone Editor, DirectAdmin DNS Administration) that accepts a subset of DNS record types and rejects per-record TTL overrides, forcing operators into DNS-zone-source escalation for advanced record publication discipline — the shared-hosting spoke documents the per-provider escalation paths to full DNS-zone-source access (the cPanel "Edit DNS Zone" admin-tier escalation, the Plesk "Custom DNS Records" per-zone source-edit affordance, the DirectAdmin per-account "Zone Editor" admin-tier escalation) that unlock the operator-controlled per-record TTL and per-zone publication discipline this page documents at the shared-hosting boundary; (iv) shared-hosting concurrent- publication coordination across the provider's per-tenant zone-publish cadence and the operator's per-record TTL countdown — when an operator publishes a per-record change via the provider's zone-edit UI, the per-zone publication cycle (provider's SOA serial-number bump + provider's secondary-NS polling rhythm) gates when the new record becomes observable at downstream resolvers — the shared-hosting spoke documents the canonical operator-side diagnostic- workflow when a published record appears to be ignored by downstream receivers for the first 15-60 minutes after the zone-edit UI confirmed the change (the provider's per-zone publication-cycle delay, NOT a malfunctioning operator- side edit), and the dig / kdig directly-against-provider-NS verification sequence that distinguishes provider-side-zone-publication-delay from operator-side-edit-failure. Read the shared-hosting spoke when an operator-authored DMARC / SPF / DKIM publication cycle traces back to the shared-hosting DNS-authority-delegation boundary this page's propagation model presupposes is operator-controlled — the spoke is the authoritative per- provider operational reference for the DNS-propagation-meets-shared-hosting- DNS-authority-delegation cross-cluster boundary.
• SPF explained — SPF DNS-record syntax. SPF records live at example.com and propagate per the same rules.
• SPF DNS TXT-record byte syntax — the SPF-TXT-RECORD-BYTE-LAYOUT-AS- PROPAGATION-PAYLOAD companion documenting the byte-level structure of the SPF TXT- record whose publication and resolution THIS DNS-propagation page's TTL-bounded publish-and-verify cycle gates. Where THIS page documents the publisher-side propagation cycle (publish → wait-TTL → verify at all recursive resolvers in the global resolver population), the SPF-DNS-syntax spoke documents the EXACT byte-payload that fills the propagation- cycle's payload-window: the v=spf1-leading mechanism- sequence (RFC 7208 §4 grammar with eight mechanism tokens plus four qualifiers), the RFC 7208 §3 single-TXT-record-per- domain constraint (publishing 2 SPF TXT records simultaneously produces permerror at every receiver on the post-propagation evaluation), the RFC 7208 §3.3 multi-string concatenation form (("v=spf1 …" " …")) for records exceeding the 255-byte single- string DNS TXT limit, and the ~all / -all / ?all / +all terminating qualifier whose byte-level publication on the propagation-cycle's first verifiable resolution is the load-bearing default-clause every receiver applies post-propagation. The four-axis DNS-PROPAGATION-CYCLE-VS-SPF- BYTE-SYNTAX comparison exposes the structurally-distinct PROPAGATION-PAYLOAD classes: (i) publisher-side SPF record first-publication propagation window — the publish-new operation's payload IS the SPF-DNS-syntax spoke's byte-layout, propagated through the recursive-resolver population over the TTL window this page documents; (ii) SPF include-chain propagation cascade per major-ESP TTL catalogue — adding include:_spf.google.com / include:spf.protection.outlook.com / include:_spf.salesforce.com means the publisher's record propagation cascades through the major ESP's per- TTL-bound nested-record propagation that this page documents; the SPF-DNS-syntax spoke is the byte-layout reference for the per-include record's structure; (iii) SPF record-edit propagation tail with operator-error-class detection — the SPF-DNS-syntax spoke documents the byte-level operator-error classes (the most-common: 256-byte single-string violation breaking the published record, spaces injected at the wrong position between mechanisms, two-TXT-records publication producing post-propagation permerror) whose detection only surfaces AFTER the propagation window has closed and receivers begin the post-publication evaluation pass; (iv) SPF record-deprecation propagation tail — removing an SPF record (rare but operationally valuable for send-only domain decommissioning) means the negative- resolution propagates over the TTL window; the SPF-DNS-syntax spoke is the byte-layout reference operators consult to verify the post-deprecation negative- resolution behaviour matches RFC 7208's none result-code semantics. Read the SPF-DNS-syntax spoke alongside this DNS-propagation reference when designing an SPF record-publication or record-edit operation — the byte-syntax spoke is the payload reference the publish-and-propagate cycle on THIS page transports through the global resolver population.
• SPF PermError vs TempError — the propagation-window failure-symptom most operators see during SPF record edits — the focused per-error-code deep dive on the two SPF-failure result codes (RFC 7208 §2.6.7 PermError + §2.6.8 TempError) operators encounter most acutely during the DNS-record-propagation window this page documents. Where THIS page documents the TTL-driven mid-propagation window during which downstream resolvers see a mix of old and new record values, the permerror-vs-temperror spoke documents the SPF-evaluator-side symptoms operators see during that window: TempError verdicts spiking in auth_results/spf/result=temperror rows when downstream resolvers experience SERVFAIL or timeout during the propagation-window-induced DNS-cache invalidation (RFC 7208 §2.6.8); PermError verdicts spiking when the operator publishes an SPF edit that introduces a record-grammar violation or hits the 10-DNS-lookup limit (RFC 7208 §4.6.4). Read the permerror-vs-temperror spoke when executing an SPF DNS-record change and the operator needs the diagnostic decision framework for triaging the post-deploy aggregate-report rows: TempError spikes are EXPECTED during the propagation window and should resolve themselves within 24-48 hours; PermError spikes are NEVER acceptable and indicate the new SPF record is broken at publication, requiring an immediate edit revert or hot-fix. The two error codes require fundamentally different operator responses (TempError → wait; PermError → rollback or fix immediately) and the spoke is the authoritative reference for the per-code diagnostic workflow.
• SPF for Google Workspace — the WORKSPACE-TENANT-SPF-RECORD- PUBLICATION-AS-DNS-TTL-BOUNDED- PROPAGATION-WINDOW companion reference. Where THIS page documents the resolver- cache aging model (RFC 1035 TTL countdown, RFC 2181 TTL-canonicalisation rules, RFC 8767 serve-stale behaviour) that determines when a newly-published DNS record is observable at recursive resolvers worldwide, the SPF-for-Google-Workspace spoke documents FIVE Workspace-tenant- specific propagation-window patterns that compound atop the universal propagation model: (i) the canonical apex SPF record propagation — when a Workspace operator first publishes v=spf1 include:_spf.google.com ~all as the apex TXT record, the TTL-countdown clock starts on the customer-domain DNS zone but Workspace outbound mail authorisation does not become uniformly observable at receivers worldwide until the maximum-TTL ceiling elapses (typically 1-4 hours at modern DNS providers, but historically 24-48 hours at legacy registrars publishing TTLs of 86400 seconds); (ii) the recursive include-chain cache-warming prerequisite — Workspace's include:_spf.google.com token resolves to a four-level recursive cascade (_spf.google.com → _netblocks.google.com + _netblocks2.google.com + _netblocks3.google.com) managed by Google in zones the customer does NOT control, so even an operator publishing the customer-domain SPF record with a 5-minute TTL must still wait for receivers' caches to warm the Google-managed include-chain (those zones publish their own TTLs, typically 300-3600 seconds) before SPF authorisation evaluates uniformly; (iii) the SPF-edit-during-propagation TempError window — when a Workspace operator adds a secondary include token (SendGrid, Mailchimp, etc.) during the propagation window, receivers mid-window see a mix of OLD apex TXT record values and NEW values, producing TempError verdicts in auth_results/spf/result=temperror rows until the propagation window closes; (iv) the apex TXT-record single-record-per-domain constraint survival during edit — Workspace operators editing the apex TXT-record must publish the new record as a complete-record-replacement (RFC 7208 §3 forbids multiple SPF records at one owner-name) within the propagation window — a partial edit producing two v=spf1 records at the apex returns PermError uniformly at receivers post- propagation, and (v) the Workspace SMTP-relay and outbound-gateway secondary-include propagation surface — operators using Workspace SMTP-relay or outbound-gateway egress paths must coordinate secondary-include propagation across multiple DNS-zone publishers (Workspace's primary include, the secondary include's vendor zone, the operator's own apex zone). Pair this DNS-propagation reference when designing a Workspace SPF record-publication or record-edit operation — the Workspace SPF spoke is the per-tenant deployment playbook the publish-and-propagate cycle on THIS page transports through the global resolver population.
• DKIM explained — the DKIM pillar covering DNS syntax, selectors, deployment. DKIM records live at selector._domainkey.example.com and have the most aggressive TTL recommendation (300 seconds) because of rotation requirements.
• DKIM for Microsoft 365 — the M365-EXCHANGE-ONLINE-SELECTOR1- SELECTOR2-CNAME-CHAIN-PROPAGATION-AS- DNS-TTL-BOUNDED-PUBLICATION-READINESS- GATE companion reference. Where THIS page documents the resolver-cache aging model (RFC 1035 TTL countdown, RFC 2181 TTL-canonicalisation rules, RFC 8767 serve-stale behaviour) that determines when a newly-published DNS record is observable at recursive resolvers worldwide, the DKIM-for-Microsoft-365 spoke documents the M365-tenant- specific dual-CNAME publication topology that is uniquely TTL-propagation-sensitive. The M365 DKIM publication model uses TWO CNAME chains (selector1. _domainkey.<your-domain> → selector1-<tenant-id>. _domainkey.<tenant>. onmicrosoft.com and the equivalent selector2 chain) — each chain requires a TWO-HOP CNAME-followed-by-TXT resolution at receiver-side DKIM verifiers. The receiver-side DNS resolver MUST successfully follow BOTH the domain-owner-published CNAME AND the Microsoft-published TXT at the onmicrosoft.com terminus BEFORE the DKIM signature can be verified — a propagation delay on EITHER hop produces a transient permerror verdict during the propagation window. Microsoft's documented "publish CNAMEs, wait for propagation, enable DKIM toggle in Defender portal" deployment sequence explicitly references this page's TTL-mechanics model: the Defender- portal enable toggle SHOULD only be switched ON after the receiver-side CNAME-chain propagation completes, and the propagation-window duration is bounded by the onmicrosoft.com zone's TTL + the domain-owner-zone CNAME TTL per the resolver-cache aging model on THIS page. Read the DKIM-for-Microsoft-365 spoke when planning an M365-DKIM rollout — the CNAME-chain propagation-readiness check, the Defender-portal enable toggle, and the dual-selector zero-downtime rotation pattern are all DNS-TTL-bounded operational primitives whose timing this page's resolver-cache aging model governs.
• DKIM key rotation — the operational procedure whose canonical dual-selector zero-downtime pattern depends on the short-TTL deployment recommended on this page.
• DKIM selectors explained — the DNS-PROPAGATION-TIMING-GATES-PER- SELECTOR-TXT-PUBLICATION-AND-PER-ROTATION- WINDOW-DUAL-SELECTOR-OVERLAP companion to this DNS-propagation reference. Where THIS page documents the propagation mechanics (TTL-bounded publish-and-verify cycles, per-resolver cache-fill timing, authoritative-vs-recursive resolution path, the dig +trace verification workflow, the 48-hour propagation-completion rule of thumb), the DKIM-selectors-explained spoke is the PER-PROVIDER SELECTOR-NAMESPACE CATALOGUE companion documenting the canonical per-platform selector-name conventions whose <selector>._domainkey.<domain> TXT-record publication this page's propagation cycle gates. Four DNS- PROPAGATION-VS-DKIM-SELECTOR cross- correlation axes: (i) per- rotation-window dual-selector overlap propagation — the canonical DKIM zero-downtime rotation pattern requires the new selector's TXT record (published with the next signing key's public bytes) to FULLY propagate to ALL receiver-side resolvers BEFORE the signing infrastructure rotates to the new selector; the selectors-explained spoke documents the per-platform dual-selector convention (selector1 ↔ selector2 at M365, named rotating selectors at Workspace, ESP- managed random-hex rotation cohorts) that exploits the propagation-window- bound rotation discipline THIS page documents; (ii) per-platform- managed-selector vs operator-published- selector propagation custody boundary — for platforms that manage the selector publication on behalf of the operator (M365's .onmicrosoft.com selector publication, Workspace's .gappssmtp.com CNAME- chained publication, AWS SES's managed TXT publication), the selectors-explained spoke documents which propagation cycle the operator is responsible for triggering vs which the platform manages — a critical operator-side custody distinction because the platform's selector publication propagates on the PLATFORM's TTL schedule, not the operator's; (iii) per-receiver propagation timing skew producing per-selector aggregate-report divergence — during the propagation window of a new selector, different receivers' independent resolver hierarchies cache the new selector at different rates; the publisher's aggregate-report stream shows per-receiver dkim=permerror / dkim=temperror divergence on the new selector that gradually resolves as propagation completes — the selectors-explained spoke documents the receiver-side selector-lookup evaluation rule whose per-selector cache-state determines the propagation- window divergence pattern; (iv) per-selector CNAME-delegation chain propagation for ESP-tenant onboarding — M365 / Google Workspace tenants onboarding new ESP signers (SendGrid, Mailgun, Mailchimp, AWS SES) typically delegate s1._domainkey.<tenant>.com CNAME s1.domainkey.<esp>.net; the selectors-explained spoke documents the canonical CNAME-delegation pattern whose propagation through the global DNS infrastructure gates the receiver's ability to verify the ESP-emitted DKIM-signed mail — the per-CNAME-link in the delegation chain has its own TTL contract THIS page's propagation model governs. Pair this DNS- propagation reference with the selectors-explained spoke when planning a DKIM key rotation or ESP-onboarding publication — the spoke is the canonical per-provider selector- namespace catalogue whose TXT-record propagation is the operational gating constraint this page's propagation mechanics govern.
• DKIM best practices — the DNS-PROPAGATION-TIMING-CONSTRAINS- DKIM-KEY-ROTATION-BEST-PRACTICES companion to this DNS-propagation deep dive. Where THIS page documents the DNS-PROPAGATION primitive (per-record TTL semantics per RFC 1035 §3.2.1 + RFC 2181 §8, resolver-cache minimum + maximum cap quirks, the propagation-observability window every DNS rotation event must respect), the DKIM best-practices spoke is the SYNTHESIS LAYER documenting the 15 operator-discipline rules whose KEY-ROTATION-CADENCE rule directly consumes the propagation-timing model THIS page documents. The DNS-PROPAGATION-TIMING- CONSTRAINS-DKIM-KEY-ROTATION-BEST-PRACTICES cross-reference establishes four specific propagation-timing-to-best-practices-rule dependencies: (i) "publish new selector record 30 days before activating it for signing" best-practices rule is calibrated against the maximum recursive-resolver cache-aging cap documented on THIS page (typical recursive-resolver caches enforce 86400s upper-bound TTL even when the authoritative zone declares a longer TTL); the 30-day publish-ahead window is roughly 30 cycles of the upper-bound cache-age and ensures every verifying receiver's resolver has the new selector available BEFORE the operator starts using it; (ii) "deploy DKIM selector records with TTL 300 seconds" best-practices rule directly instances the TTL-design rationale THIS page documents — short TTL is the propagation primitive that makes rapid-rollback feasible when a botched selector publication needs reversal; (iii) "maintain a 30-day publish-overlap window before retiring the old selector" best-practices rule is similarly calibrated against the same 86400s upper-bound cache-age — in- flight messages signed with the old selector during the cache-aging tail of the rotation event MUST still verify cryptographically on the receiver side; the 30-day window provides 30+ cycles of the upper-bound; (iv) "rotate DKIM selectors quarterly" best-practices rule respects the propagation- observability + cache-aging windows on THIS page by sequencing rotation events at a cadence (90 days) that comfortably exceeds the propagation + overlap windows (60 days combined). Read THIS page when modelling the DNS-propagation primitive; read the DKIM best-practices spoke when the operator-discipline ruleset that consumes the propagation primitive is the next decision-shaping reference.
• DKIM cryptography basics — the foundational cryptographic reference covering why DKIM keys need rotation in the first place (and therefore why short TTLs matter).
• BIMI explained — Brand Indicators for Message Identification. BIMI records live at default._bimi.example.com.
• BIMI SVG Tiny PS asset-format requirements — the BIMI-RECORD-DNS-PROPAGATION- AT-DEFAULT-DOT-_bimi-OWNER-NAME consumer companion to this DNS- propagation reference. Where THIS page documents the universal RFC 1035 §3.2.1 + RFC 2181 §8 + RFC 8767 serve-stale TTL-aging and recursive-resolver-cache-eviction model — the per-record TTL discipline that bounds the cached-record straddle window every DNS-record- update produces — the BIMI-SVG-Tiny- PS-requirements spoke is the BIMI- RECORD-DNS-PROPAGATION-CONSUMER companion documenting how the BIMI TXT record published at default._bimi.<d-domain> becomes a propagation-bounded receiver- side cache-fetch trigger for the operator's published SVG asset. Concretely, the spoke documents FOUR BIMI-record-DNS-propagation- consumption dimensions: (i) BIMI TXT record at default._bimi.<d-domain> is published with operator-controlled TTL whose receiver-side cache lifetime determines BIMI-display update timeline — the BIMI record body (v=BIMI1; l=https://<svg-url>; a=https://<vmc-url>) is fetched by receiver-side BIMI- eligibility evaluators on a TTL- bounded cadence, and the per-record TTL THIS page documents directly determines how long receivers observe an out-of-date l=-URL or a=-URL after the operator updates the record (typical operator practice: 3600s TTL for the BIMI record, with TTL-lowering 24h before BIMI-URL update per the Phase 0 TTL- discipline THIS page documents); (ii) BIMI l=-URL SVG-asset fetch happens via HTTPS to the operator-controlled SVG-hosting endpoint, NOT via DNS — but the BIMI record's DNS-propagation discipline gates URL CHANGES — once the BIMI record is propagated, receivers cache the l=-URL and fetch the SVG-Tiny-PS asset via HTTPS on a separate cadence (typically per first-message-per-author-domain cache-miss); operator-side SVG-asset changes that REUSE the same l=-URL propagate to receivers via HTTPS-cache eviction on the SVG asset (not DNS), but operator-side l=-URL CHANGES (e.g. moving from logo-v1.svg to logo-v2.svg) require DNS propagation of the updated BIMI record per the discipline THIS page documents; (iii) BIMI a=-VMC- URL chain validation is another DNS- propagation-gated dereferenceable — the a=<vmc-url> tag in the BIMI record points to a Verified Mark Certificate's PEM-bundle at an operator-controlled HTTPS endpoint, and the VMC chain validation runs separately from the SVG-asset fetch — operator- side VMC-URL changes are bounded by the same BIMI-record DNS-propagation discipline (the BIMI TXT record body is the canonical source of the VMC URL, and DNS propagation of an updated record is required to migrate receivers from an old-VMC PEM-bundle URL to a new one); and (iv) BIMI fallback / deletion behaviour is also DNS- propagation-bounded — operators retiring a BIMI deployment (BIMI record deletion / TTL-zeroed retraction) face the same recursive-resolver cache-aging window every other DNS-record retraction faces, and receivers continue observing the cached BIMI record for up-to-TTL seconds after retraction — operators retiring BIMI must lower the TTL one full TTL period BEFORE the deletion per the Phase 0 TTL-discipline THIS page documents to bound the post- deletion BIMI-display-residual window. Read the BIMI-SVG-Tiny-PS-requirements spoke alongside this DNS-propagation reference when planning a BIMI deployment, a BIMI l=-URL migration, a VMC certificate rotation, or a BIMI retirement — the TTL- discipline THIS page documents is the invisible-timing-layer prerequisite for every BIMI-record-update operation the spoke documents.
• MTA-STS explained — MTA-STS uses a TXT record at _mta-sts.example.com AND an HTTPS-served policy file. Both have propagation considerations.
• MTA-STS vs DANE — the transport-security head-to-head decision reference (the DNS-PROPAGATION-TIMING-DECISION-INPUT companion to this propagation reference) — the DNS-PROPAGATION-TIMING-DECISION-INPUT companion documenting the transport-security choice between MTA-STS and DANE whose respective propagation models are structurally distinct in ways that constrain the operator's choice. Where THIS page documents the GENERIC DNS-propagation model (SOA serial-number bump, per-zone refresh interval, secondary name-server polling rhythm, resolver-cache TTL countdown, propagation-completion-within-48-hours rule of thumb, the dig +trace / dig @8.8.8.8 / dig @1.1.1.1 propagation-verification workflow), the mta_sts_vs_dane spoke is the HEAD-TO-HEAD DECISION REFERENCE documenting how the transport-security choice maps to TWO structurally-distinct propagation models the cross-reference makes explicit: (i) MTA-STS propagation is HYBRID DNS + HTTPS — the _mta-sts.<domain> TXT-anchor record propagates per THIS page's standard DNS rules, but the https://mta-sts.<domain>/.well-known/mta-sts.txt policy file is fetched on-demand over HTTPS with CDN-caching/origin-cache layered underneath, so the EFFECTIVE propagation window is policy-id-driven rather than TTL-driven; (ii) DANE propagation REQUIRES DNSSEC-CHAIN-FULL-PROPAGATION — the _25._tcp.<mx-host> TLSA record is published per THIS page's standard DNS rules, BUT the entire DNSSEC chain (root → TLD → zone) MUST also be propagated and validated by the verifying receiver before the TLSA record can be trusted, which means DNSSEC-chain propagation timing dominates the DANE-effective propagation window; (iii) cert-rotation propagation timing diverges between MTA-STS and DANE — when the operator rotates the SMTP cert, MTA-STS-protected receivers re-fetch the policy file on next-policy-expiry rather than on-DNS-record-change, while DANE-protected receivers re-validate the TLSA record's cert-hash on next-TLSA-TTL-expiry with DNSSEC-chain re-validation; (iv) STS-mode "testing" vs DANE usage-21 — MTA-STS provides a non-enforcing "testing" mode receivers report-only while propagation completes across resolver caches, but DANE has no equivalent non-enforcing mode (a TLSA record publication is enforcing-immediately on the first DNSSEC-chain-validating receiver that observes it). Read the MTA-STS-vs-DANE head-to-head when the operator is choosing the transport-security technology and the propagation-window characteristics documented on THIS page contribute to the decision.
• DANE for SMTP (RFC 7672) explained - the DANE-PROTOCOL-OVERVIEW-AS-STANDALONE- TRANSPORT-SECURITY-MECHANISM companion to this DNS-propagation reference. Where the sibling MTA-STS-vs-DANE entry ABOVE documents the HEAD-TO-HEAD comparison between the two transport-security technologies, the dedicated DANE deep-dive documents the STANDALONE DANE protocol-overview-and- operational-deployment-model whose four propagation-cycle interactions with THIS page's TTL-bounded publish-and-verify model are STRUCTURALLY-DISTINCT from any other email-authentication record's propagation behaviour. The four-axis DNS-PROPAGATION- VS-DANE-DEPLOYMENT comparison exposes the structurally-distinct DANE-PROPAGATION- TIMING roles: (i) TLSA-RR publication at _25._tcp.<mx-host> is governed by the published TLSA record's TTL per the standard TTL-countdown this page models BUT the TLSA record's payload cryptographic-hash is INERT until the receiver-side DNSSEC-chain validates the zone holding the TLSA RR - the operational propagation window is therefore the SLOWER of (a) TLSA-RR TTL expiry across the receiver-resolver fleet and (b) DNSSEC- chain re-validation across the resolver fleet, structurally extending the typical per-record propagation window an unbounded amount when DNSSEC-key-roll-over operations intersect - the DANE deep-dive documents the DNSSEC-chain-validation- gates-TLSA-trust contract; (ii) DANE requires the publisher's zone to be DNSSEC- signed (the parent zone publishes a DS record at the publisher's zone-cut, the publisher's zone publishes DNSKEY records, and every record below the zone-cut is signed with RRSIG records) - the DANE- deployment-prerequisite DNSSEC-zone-signing operation introduces a propagation cycle STRUCTURALLY-ORTHOGONAL to the TXT-record propagation this page models because DS- record publication at the parent zone-cut is on the registrar's propagation schedule and the registrar's propagation cadence may differ from the operator's authoritative zone's refresh cadence; the DANE deep-dive documents the per-registrar DS- record-propagation cycle as a DANE- deployment-specific propagation-window component; (iii) DANE cert-rotation propagation requires the operator to PUBLISH BOTH the old-cert-hash and the new-cert-hash TLSA records in a 3-2-1-overlap pattern (RFC 7671 §8 dual-TLSA-publication discipline) for at least 2x the TLSA-RR-TTL window BEFORE the cert rotates, then remove the old-cert-hash TLSA record at least 1x the TLSA-RR-TTL after the rotation completes - this two-window cert-rotation propagation choreography is DANE-SPECIFIC and has no equivalent in DMARC/SPF/DKIM/MTA-STS propagation; the DANE deep-dive documents the RFC 7671 §8 dual-TLSA- publication overlap discipline as the canonical DANE cert-rotation propagation- coordination procedure; and (iv) DANE- validation failures at the receiver are permanent-rejection events (deferred SMTP 4xx temporary-failure mid-transit on DNSSEC- chain-validation transient errors but permanent 5xx on TLSA-mismatch) so the operator's propagation-window choreography is OPERATIONALLY HIGH-STAKES at receivers that validate DANE - publishing a TLSA record with a typo, an old-cert-hash that the operator has already rotated past, or an incomplete DNSSEC chain produces immediate mail-delivery rejection from every DANE-validating receiver, with no non-enforcing "testing" mode equivalent to the MTA-STS testing mode the sibling spoke documents; the DANE deep- dive documents the rejection-on-validation- failure receiver-side semantics as the single most operationally-load-bearing characteristic the propagation-window choreography on THIS page must accommodate for DANE-publishing operators. Read the dedicated DANE deep-dive alongside this propagation page when scoping the TLSA-record publication timing for a new DANE deployment - the spoke is the authoritative DANE-protocol-overview reference whose four DANE-specific DNS- propagation interactions this propagation page is the timing-model companion for.
• MTA-STS policy file syntax (byte-level reference) — the byte-level reference for the mta-sts.<domain>/.well-known/mta-sts.txt HTTPS-served policy file whose propagation rules differ structurally from every other record this page documents. Unlike the DNS-only TXT records (DMARC, SPF, DKIM, BIMI, MTA-STS-anchor-TXT, TLS-RPT) whose propagation is governed by the published TTL plus resolver caching, the MTA-STS policy file is fetched over HTTPS and has DUAL substrate-cache considerations: (i) the _mta-sts.<domain> TXT record's id= token MUST change with each policy revision to invalidate sender-side caches (independent of TTL — senders cache the policy keyed by id, not the TXT TTL), AND (ii) the HTTPS Cache-Control: max-age=N response header from the policy-host webserver governs the sender's policy-file re-fetch interval after id-change detection. The policy file's max_age: directive (in seconds, 86400 minimum recommended for production deployments) sets the sender's policy-cache lifetime if the HTTPS Cache-Control is absent. Read this when coordinating MTA-STS policy rotation with the rest of your DNS-substrate change windows — the TXT-id bump must propagate BEFORE senders re-fetch the policy or they will keep enforcing the stale policy until the previous max_age: window expires.
• TLS-RPT explained — SMTP TLS Reporting. TLS-RPT records live at _smtp._tls.example.com.
• TLS-RPT DNS record syntax (RFC 8460 §3) — the byte-by-byte syntax-layer reference for the _smtp._tls.<domain> TXT record whose propagation this page documents at the substrate level. The record-syntax page covers the 255-octet TXT-string chunking rule (the SAME chunking rule documented in this page's DKIM-and-SPF-record sections — TLS-RPT records that approach the 255-octet limit because of many or long rua= URIs trip the same Cloudflare-auto-split / GoDaddy-manual-chunk / BIND-multi-string publishing-side gotchas this page documents), the v=TLSRPTv1 case-sensitive version-tag floor (case mismatches produce the same silent rejection mode this page's case-sensitivity section warns about for DKIM v=DKIM1 and DMARC v=DMARC1), and the optional size_limit= extension. Read this when authoring or migrating the _smtp._tls.<domain> TXT record under the TTL-reduction + observe-propagation workflow this page recommends — TLS-RPT records have the 86400-second TTL ceiling this page recommends in section 9, so a botched publish followed by an immediate rollback will still leave receivers honouring the bad record for up to 24 hours.
• TLS-RPT JSON report format (RFC 8460 §4) — the DNS-PROPAGATION-WINDOW-FOR- TLS-RPT-PUBLICATION-CONSUMER companion to this DNS-propagation reference. Where the TLS-RPT record-syntax spoke above documents the byte-level _smtp._tls.<domain> TXT-record grammar (v=TLSRPTv1; rua=URI list) whose propagation through the recursive-resolver cache hierarchy this page models, the TLS-RPT report-format spoke documents the JSON-payload schema ("policy-domain", "policy-type", "successful-session-count", "failed-session-count", "failure-details": [{"result-type", "ip-address", "receiving-mx-hostname", "additional-information", "failure-reason-code"}]) the receiver emits via the rua=mailto: delivery channel AFTER the receiver's recursive resolver has fully observed the TXT-record publication — meaning the DNS-propagation window THIS page documents is the EXACT START-GATE for the per-receiver TLS-RPT report-collection timeline the report-format spoke documents. Read this spoke when the TLS-RPT TXT record has been authored and published per the TTL-reduction workflow this page recommends and the operator is now waiting for the FIRST 24-hour-window-worth of JSON reports to arrive from the receiver population — the report-format spoke documents the exact JSON schema the operator's ingest pipeline must accept, the gzip-compression contract on the application/tlsrpt+gzip MIME type, and the per-receiver publication-frequency contract (one report per 24-hour window per publisher-domain × receiving-MX tuple). The DNS-propagation reference and the TLS-RPT report-format reference share an OPERATIONAL HANDOFF: the propagation reference is the PUBLISHER-SIDE pre-publication discipline; the report-format reference is the OBSERVER-SIDE post-publication operational discipline. Both must be in scope when an operator commissions a new _smtp._tls TXT record.
• CAA records explained — Certificate Authority Authorization. Sibling DNS-published email-security record whose propagation timeline matters for certificate issuance.
• Reverse DNS / PTR records for mail servers — the operator deep dive on the in-addr.arpa / ip6.arpa reverse-zone record class whose propagation follows a fundamentally different delegation chain than the forward zones documented on this page. Forward zones are delegated to the domain owner by the registrar (and propagate via the operator's authoritative nameservers per the 5-minute to 48-hour timeline this page documents); reverse zones are delegated to the IP-block holder by the RIR (ARIN, RIPE, APNIC, LACNIC, or AFRINIC) and from there typically to the ISP or cloud provider — not to the end-customer renting the IP. PTR-change propagation therefore goes through the ISP / cloud-provider DNS infrastructure rather than the operator's own authoritative nameservers: AWS Elastic IP PTR requires the "Request to Remove Email Sending Limitations" form (24-48 h manual turnaround), Azure VM reverse DNS is set per-VM via the Azure portal, Google Cloud uses Cloud DNS reverse zones, and self-hosted operators must coordinate PTR changes with whoever holds the upstream /24 (typically the colo or the upstream transit provider). Reverse-zone TTLs and propagation timings are rarely under the operator's control. Read this page for the forward-zone propagation timeline and then the reverse-DNS page for the operationally-distinct reverse-zone path that often surprises operators rolling out new outbound-mail IPs.
• MX records explained — the dedicated DNS-record deep dive on the MX resource record class whose propagation timing matters in two operationally-distinct ways the forward-zone timeline on this page does not fully address. (1) MX-failover TTL budgeting: operators routinely publish short MX TTLs (300 – 1800 seconds) to bound the recovery window if a primary MX target's IP changes during an incident, and the multi-MX preference list (10 / 20 / 30) only protects against the connecting receiver already-cached BUT failing-to-reach case if the TTL is short enough for the cache to refresh before the receiver's retry budget exhausts. (2) MX-migration cutover sequencing: moving the MX RDATA from on-prem Postfix to Microsoft 365 example-com.mail.protection.outlook.com or Google Workspace aspmx.l.google.com requires lowering the MX TTL to 300 BEFORE the cutover (so receivers re-query during the migration window), running both old and new MX targets in parallel during the propagation tail (5 minutes to 48 hours per this page), and only retiring the old MX target after the TTL window has fully drained across the receiver population. Read this page for the propagation timeline and then the MX records page for the MX-specific TTL operational considerations.
• DMARC policy rollout — the operational deep dive whose per-phase exit-criteria framework depends on understanding DNS propagation when moving between p=none, p=quarantine, and p=reject.
• DMARC policy modes (p=none / p=quarantine / p=reject) — the PER-DMARC-POLICY-MODE-PUBLICATION- TRANSITION-IS-GATED-ON-PRE-LOWERED-TTL- DISCIPLINE companion to this DNS-propagation reference. Where THIS page documents the canonical TTL-bounded publish-and-verify cycle (the RFC 1035 §3.2.1 + RFC 2181 §8 recursive-resolver-cache-aging-out model, the pre-lowered-TTL preparation discipline that makes record changes feel instantaneous rather than spanning a 4-to-24-hour cached- record straddle window), the DMARC-policy- modes spoke documents the THREE per-policy- mode-transition operational windows (Phase 1 → Phase 2 / Phase 2 → Phase 3 / Phase 3 → terminal-state) whose per-transition publication-cadence operational execution is the LOAD-BEARING DOWNSTREAM CONSUMER of every TTL-bounded publish-and-verify cycle THIS propagation reference documents. The PER- DMARC-POLICY-MODE-TRANSITION-VS-DNS- PROPAGATION cross-reference establishes FOUR structurally-distinct per-policy-mode- transition-to-DNS-propagation-discipline coupling dimensions: (i) Phase 0 TTL discipline as canonical pre-policy-mode- transition operational prerequisite — every per-policy-mode publication-transition (p=none → p=quarantine, p=quarantine → p=reject, pct=10 → pct=25 → pct=50 → pct=75 → pct=100) REQUIRES the publisher to execute Phase 0 TTL discipline ONE FULL TTL PERIOD BEFORE the policy-mode-transition publication takes effect — failing to pre- lower the per-DMARC-record TTL produces a 4-to-24-hour per-recursive-resolver cached- record straddle window where some receivers evaluate the publisher's mail against the OLD policy-mode and others against the NEW policy-mode, producing per-receiver per-row DMARC-disposition divergence in the per- publisher RUA aggregate stream during the cutover window; the DMARC-policy-modes spoke documents the per-policy-mode-transition operational discipline whose load-bearing upstream prerequisite is the Phase 0 TTL discipline this propagation reference documents; (ii) per-policy-mode- transition rollback discipline as canonical operational-safety-fallback consumer of the TTL-bounded publish-and-verify cycle — every per-policy-mode escalation MUST retain the operational option to ROLLBACK to the prior policy-mode within one TTL period if per-receiver per-row aggregate- report evidence surfaces a per-source-IP per-disposition divergence the publisher cannot operationally resolve at the escalated policy-mode; the per-policy-mode- rollback operational discipline depends on the pre-lowered-TTL preparation window THIS propagation reference documents as the canonical Phase 0 prerequisite; the DMARC- policy-modes spoke documents the per-policy- mode-transition rollback discipline whose operational execution structurally depends on the TTL-bounded publish-and-verify cycle documented here; (iii) sp= subdomain-policy-mode-transition per- subdomain-DMARC-record propagation coordination — publishers using the per-subdomain DMARC override discipline (an explicit DMARC record at _dmarc.<subdomain> rather than inheriting from the apex sp= tag) MUST coordinate per- subdomain DMARC-record publication-transition propagation across multiple authoritative- nameserver zone files when subdomain DNS authority is delegated to a different nameserver set than the apex zone — a recurring DNS-propagation coordination defect class for publishers with multi-tenant subdomain DNS delegation arrangements; the DMARC-policy-modes spoke documents the sp= tag-value-semantics whose per-subdomain-DMARC-record publication- transition coordination depends on the multi- zone propagation discipline THIS propagation reference documents; (iv) per-policy- mode-transition per-percentage-ramp publication-cadence per-resolver-eviction window alignment — publishers executing the per-percentage pct=- ramp publication-cadence (pct=10 → pct=25 → pct=50 → pct=75 → pct=100) MUST align each per- percentage publication-transition with the canonical 300-second-recommended-DMARC-record TTL eviction window per receiver-resolver- cache-aging model documented in this propagation reference — failing this alignment produces per-receiver per-row per-percentage-ramp-stage disposition divergence in the publisher's RUA aggregate stream that contaminates per-percentage- ramp-stage exit-criteria evidence the DMARC-policy-rollout playbook gates per-percentage advancement on; the DMARC- policy-modes spoke documents the per- percentage pct=-ramp publication- cadence operational discipline whose load- bearing per-percentage-stage TTL-alignment prerequisite is documented in THIS propagation reference. Read THIS DNS- propagation reference WITH the DMARC-policy- modes spoke when the per-policy-mode- transition publication-cadence operational execution step arrives: the propagation page documents the TTL-BOUNDED PUBLISH-AND- VERIFY CYCLE, the DMARC-policy-modes spoke documents the THREE-STATE AUTHOR-DOMAIN ENFORCEMENT-POLICY-MODE LADDER whose per- transition publication-cadence operational execution is the load-bearing downstream consumer of every TTL-bounded publish-and- verify cycle this propagation reference documents.
• DMARC troubleshooting — the operational diagnostic guide. "DNS not propagated yet" is the wrong diagnosis in 95 percent of the cases this guide covers.
• Email authentication ecosystem — the cluster-intro pillar covering all three email-auth pillars (SPF, DKIM, DMARC) plus BIMI, ARC, MTA-STS, and TLS-RPT — all of which depend on DNS propagation.
• Email authentication glossary — definitions of the DNS vocabulary on this page: TTL, authoritative nameserver, recursive resolver, glue record, SOA record, NXDOMAIN.
• MTA-STS for Microsoft 365 — the DNS-PROPAGATION-M365-MTA-STS- POLICY-ID-VS-TXT-RECORD-CACHE- CONSISTENCY-DURING-POLICY-ROLLOUT- WINDOW companion reference. Where THIS page documents the generic DNS propagation mechanics (TTL, authoritative-vs-recursive resolver boundary, multi-resolver verification, glue records, SOA, NXDOMAIN), the MTA-STS-for-Microsoft-365 spoke documents the M365-tenant-specific TWO-RECORD coordinated publication where the _mta-sts.<domain> TXT-record's id= identifier must match the HTTPS- hosted policy file's version field byte- for-byte. The DNS-propagation dynamics this page catalogues directly determine WHEN any operator's MTA-STS policy update (whether tightening mode: testing → mode: enforce, adding a new MX host to the mx: allow-list, or bumping max_age) takes effect at sending MTAs — a sending MTA's MTA-STS implementation caches the policy file keyed on the TXT-record id= identifier, so a policy-file rollout that propagates faster than the corresponding TXT-record update leaves sending MTAs ENFORCING THE OLD POLICY for the difference window. Read the M365 MTA-STS spoke alongside this page when authoring the M365 MTA-STS rollout playbook — the DNS propagation timeline this page documents is the rate-limiting constraint on the MTA-STS policy- update workflow the M365 spoke describes.
• MTA-STS for Google Workspace — the DNS-PROPAGATION-WORKSPACE-MTA-STS- POLICY-ID-VS-TXT-RECORD-CACHE- CONSISTENCY-AT-aspmx.l.google.com-MX- ENFORCEMENT-WINDOW Workspace-tenant sibling of the M365 MTA-STS-propagation companion above. Where the M365-MTA-STS entry documents the M365-tenant two-record coordinated publication discipline at the _mta-sts.<m365-tenant> + mta-sts.<m365-tenant> publication-pair boundary, the Workspace- tenant MTA-STS-for-Google-Workspace spoke surfaces a structurally-analogous publication- discipline coordination at FOUR Workspace- tenant-specific DNS-and-HTTPS-cache- coordination dimensions: (i) Workspace-tenant _mta-sts.<workspace-tenant> TXT-record vs mta-sts.<workspace-tenant> HTTPS-host A/AAAA / CNAME record propagation synchronisation — the Workspace operator publishes the policy-version- identifier TXT at the authoritative-NS for the customer-controlled zone AND the HTTPS-host name resolution at the SAME authoritative-NS (or a delegated sub-NS), each subject to independent TTL-budget propagation across the recursive-resolver fleet this page documents at the generic DNS-propagation mechanics layer; (ii) Workspace-tenant mx: *.l.google.com allow-list evolution at the policy-file id= identifier-bump boundary — Workspace's authoritative MX hosts evolve at Google-managed boundaries (aspmx.l.google.com + alt1.aspmx.l.google.com + alt2.aspmx.l.google.com + alt3.aspmx.l.google.com + alt4.aspmx.l.google.com — the five canonical hostname-patterns the Workspace tenant publishes in the mx: allow-list); the Workspace tenant publishes a fresh id= identifier whenever the allow-list updates, AND the corresponding DNS TXT-record propagation timeline THIS page documents determines WHEN sending MTAs see the new identifier-pointer in their TTL-bounded local resolver cache and re-fetch the updated policy from the HTTPS host; (iii) per-sending-MTA HTTPS-fetch-cache vs DNS-TXT-record-cache cross-resolver-fleet coherence — the Workspace MTA-STS publication discipline is structurally DUAL — DNS TXT-record propagation governed by the authoritative-NS-published TTL AND HTTPS-fetch caching governed by the per-sending-MTA implementation's MTA-STS cache layer (typically refreshed at max_age-second intervals); the joint window where TXT-record cache coherence is achieved AND HTTPS-fetch cache has refreshed the new policy is the structural rollout boundary the Workspace operator must reason about when bumping mode: testing → mode: enforce at the policy-rollout boundary; (iv) Workspace-tenant cross-record propagation-failure detection via TLS-RPT feedback loop — a Workspace tenant whose _mta-sts. TXT-record propagates faster than the HTTPS host's A/AAAA record OR vice versa produces a transient per-sending-MTA TLS-handshake-attempt window where some sending MTAs cache an unreachable HTTPS endpoint (DNS-PROPAGATION-PARTIAL condition); the Workspace MTA-STS spoke documents the canonical TLS-RPT observability pipeline at _smtp._tls.<workspace-tenant> for surfacing transient MTA-STS-fetch- failure events the DNS propagation timeline this page documents can produce during the policy-rollout window. Read the Workspace MTA-STS spoke alongside this page when authoring the Workspace MTA-STS rollout playbook — the DNS-propagation timeline this page documents is the rate-limiting constraint on the MTA-STS policy-update workflow the Workspace MTA-STS spoke describes.
• DKIM for Google Workspace — the DNS-PROPAGATION-WORKSPACE-DKIM- 255-BYTE-TXT-CHUNK-CONCATENATION-AND- MANUAL-SINGLE-SELECTOR-ROTATION-OVERLAP- WINDOW companion reference. Where THIS page documents the generic DNS propagation mechanics (TTL, authoritative- vs-recursive resolver boundary, multi- resolver verification, glue records, SOA, NXDOMAIN), the DKIM-for-Google-Workspace spoke documents the WORKSPACE-TENANT- SPECIFIC operator-published DKIM TXT- record mechanics where the 255-byte TXT- chunk concatenation rule and the operator-controlled MANUAL single- selector rotation procedure both depend on DNS propagation timing behaviours this page catalogues. The Workspace DKIM TXT-record carries a 2048-bit RSA public key encoded in base64 (typically ~390+ characters of base64 plus the v=DKIM1; k=rsa; p= prefix tags) — a value that exceeds the per-string 255-byte TXT-record limit defined in RFC 1035 §3.3.14, so the operator must split the base64 payload into 255-byte segments wrapped in adjacent quoted strings within the same TXT record that resolvers concatenate at lookup time. Different authoritative DNS provider UIs handle this differently — Cloudflare and Google Cloud DNS auto-split, Route 53 requires explicit chunking with the quoted-string syntax, some DNS UIs corrupt the chunks. AND because Workspace uses MANUAL single- selector rotation (NOT M365's automatic dual-selector overlap rotation), the operator must coordinate the rotation across the DNS propagation timeline this page documents — publish the NEW selector's TXT record under a NEW selector name, wait for the new TXT record to propagate uniformly through recursive-resolver caches (typically 24-48h for global propagation depending on the old record's TTL), switch the Workspace Admin Console DKIM signing configuration to the new selector, then wait an additional in-flight-message retention window (typically 7-14 days per receiver retry policies) before removing the OLD selector's TXT record — removing the old TXT record too early during the propagation overlap window strands in-flight messages signed against the old selector with unverifiable DKIM signatures (because the verifier's lookup against the old selector returns NXDOMAIN). Read the Workspace-DKIM spoke alongside this page when authoring the Workspace DKIM rotation playbook — the DNS propagation timeline this page documents is the rate-limiting constraint on both the initial TXT-publication step AND every subsequent key-rotation step the Workspace-DKIM spoke describes.
• DMARC deployment checklist — the PROPAGATION-LATENCY-GATES-EVERY- PUBLISH-STEP-IN-THE-CHECKLIST companion. Where THIS page documents the DNS-cache / TTL-decay / authoritative-vs-recursive- resolver propagation-latency surface (the multi-resolver verification window, the per-TLD propagation-delay budget ranging from sub-minute for Cloudflare / AWS Route 53 to multi-hour for legacy registrars, the TTL-stagger pattern for zero-downtime record changes), the deployment-checklist spoke documents the canonical staged-rollout runbook EVERY PUBLISH-STEP OF WHICH IS GATED BY THE PROPAGATION-LATENCY THIS PAGE DOCUMENTS. The deployment-checklist spoke's publish-and-verify step pairs each require a propagation-wait window between the publish-step and the verify-step: (i) the initial DMARC TXT publication at _dmarc.<domain> requires waiting at least the current DNS TTL (typically 1 hour for fresh records, up to 24 hours for cached legacy records) before the verify-step confirms multi-resolver visibility; (ii) each pct= ramp adjustment in the staged-rollout (pct=10 → pct=25 → pct=50 → pct=100) requires the same propagation-wait window before the next ramp-step begins (the operator must be confident every recursive resolver sees the new pct= value before the new sample-population is statistically representative); (iii) the terminal p=quarantine → p=reject flip is the most propagation-sensitive step (any recursive resolver still serving the stale p=quarantine for the cached TTL window will quarantine rather than reject mail the publisher expects to be rejected, surfacing the false-positive volume in the quarantine bucket rather than the reject bucket). The propagation- latency this page documents IS the rate-limiting constraint on the deployment-checklist spoke's overall timeline; a publisher whose registrar forces 24-hour propagation cannot execute the deployment checklist faster than ~24-hour-per-step cadence regardless of operator availability. Read THIS DNS-propagation page WITH the deployment-checklist spoke when planning a DMARC deployment timeline and matching the checklist's per-step wait-window to the actual registrar / DNS-host propagation budget.
• BIMI Verified Mark Certificates (VMC) — the PER-PUBLISHER-BIMI-VMC- PUBLICATION-AS-CROSS-LAYER-DNS-AND- PKI-PROPAGATION-DOWNSTREAM-CONSUMER- OF-DNS-PROPAGATION-DISCIPLINE companion to this DNS-propagation reference. Where THIS page documents the per-publisher DNS-propagation budget (per-RR TTL, per-registrar per-zone refresh cadence, per- resolver per-receiver cache TTL, multi-resolver verification discipline), the BIMI VMC spoke is the CROSS-LAYER DNS + PKI PROPAGATION-DOWNSTREAM-CONSUMER companion documenting the per- publisher BIMI VMC publication discipline whose per-tenant DNS propagation budget for the BIMI TXT-RR is compounded with the per- publisher PKI propagation budget for the VMC AIA/CRL/OCSP chain. The four-axis DNS-PROPAGATION-VS- BIMI-VMC-PKI-PROPAGATION comparison exposes the structurally-distinct cross-layer per-publisher per- receiver propagation couplings: (i) per-publisher BIMI TXT-RR publication has the same per- registrar per-resolver DNS- propagation budget as any other per-publisher TXT-RR (SPF / DKIM / DMARC / MTA-STS / TLS-RPT / CAA) this DNS-propagation page documents — operators publishing the per-publisher default._bimi.<d> TXT-RR with v=BIMI1; l=...; a=... observe the same per-registrar per-resolver propagation budget; (ii) per-publisher BIMI VMC publication has an ADDITIONAL PKI-propagation layer beyond DNS- propagation — per-receiver BIMI-display-eligibility evaluator fetches the VMC at a=https://<cert-uri> AND validates the per-cert AIA chain (Authority Information Access URI for intermediate CA certs) + per-cert CRL (Certificate Revocation List) + per-cert OCSP (Online Certificate Status Protocol) endpoints — each of which has its own per-receiver cache TTL + propagation budget independent of the DNS-propagation budget; (iii) per-publisher BIMI VMC emergency-revocation propagation is bounded by the slower of (DNS TXT-RR removal propagation, CA- issued AIA/CRL/OCSP revocation propagation, per-receiver MUA cached-cert-revalidation interval) — operators responding to per-publisher VMC private-key compromise must coordinate DNS-edit removal of the BIMI TXT-RR AND CA-side revocation publication; both propagation budgets stack against the per-receiver display- eligibility re-evaluation window; (iv) per-publisher BIMI VMC issuance-workflow propagation is the slowest variant of any per-publisher cryptographic- material propagation discipline (1-7 day CA-issuance window + per-publisher DNS-propagation budget on first publication + per-receiver cached-NXDOMAIN eviction at receivers that cached the pre-publication NXDOMAIN response) — operators provisioning per- publisher BIMI VMC first-time must architect a propagation budget that compounds DNS- propagation with PKI-issuance + per-receiver NXDOMAIN-cache eviction at receivers that previously queried the publisher's default._bimi RR before publication. Read the BIMI VMC spoke alongside this DNS-propagation reference when scoping the per-publisher cross-layer BIMI publication propagation budget — the spoke documents the per-publisher BIMI VMC PKI-propagation discipline that compounds with the per-publisher DNS-propagation budget this page documents at every per-publisher first-time BIMI publication + per-cert renewal + emergency-revocation workflow.
• SPF mechanism comparison: include vs ip4 vs a vs mx — the RFC-7208-§5-PER-MECHANISM- DNS-LOOKUP-OVERHEAD-AS-LOAD- BEARING-PER-PUBLISHER-PER- MECHANISM-CHOICE-COUPLING-TO- PER-PUBLISHER-DNS-PROPAGATION- BUDGET-DISCIPLINE companion to this DNS-propagation pillar reference. Where THIS page documents the per-publisher TTL- bounded resolver-cache-aging model (RFC 1035 + RFC 2181 + RFC 2308 negative-caching + RFC 8767 serve-stale) whose per-zone TTL- discipline determines per-record propagation-window coordination, the include_vs_ip4_vs_a_vs_mx spoke documents the per-RFC-7208- §5-mechanism-choice catalogue at FOUR per-mechanism-DNS-propagation- coupling dimensions: (i) per-publisher include:<zone> mechanism per-message receiver- side EVALUATION-TIME RECURSIVE ZONE-LOOKUP AS LOAD-BEARING DOWNSTREAM CONSUMER of the per- included-zone TTL-discipline THIS page documents — every per-publisher include:<zone> token's per-message receiver-side evaluation resolves the included- zone's per-zone SPF-record, which the recursive resolver caches TTL-bounded; the include_vs_ip4_ vs_a_vs_mx spoke documents this per-include-token DNS-lookup- overhead consumer-discipline whose receiver-side per-message evaluation depends on the per- included-zone publisher's TTL- discipline THIS page documents; (ii) per-publisher a: / mx: mechanism per- message receiver-side EVALUATION- TIME FORWARD-DNS-RESOLUTION AS LOAD-BEARING DOWNSTREAM CONSUMER of the per-publisher per-A-RR / per-MX-RR TTL-discipline THIS page documents — every per-publisher a:<host> / mx: mechanism's per-message receiver-side evaluation resolves the per-host A-RR / per-MX-host A-RR, both TTL-bounded by the recursive resolver-cache-aging model; the include_vs_ip4_vs_a_vs_mx spoke documents this per-mechanism- forward-DNS-lookup-overhead consumer-discipline whose receiver-side evaluation depends on the per-publisher per-A-RR / per-MX-RR TTL-discipline THIS page documents; (iii) per- publisher ip4:<CIDR> / ip6:<CIDR> mechanism LITERAL-CIDR PUBLICATION AS ZERO-DNS-LOOKUP- OVERHEAD primitive WHOSE per- publisher LITERAL-IP cutover- cadence STILL COORDINATES WITH the per-publisher SPF-record TTL-discipline THIS page documents — the per- publisher ip4: / ip6: literal-CIDR mechanisms consume zero per- message receiver-side DNS-lookup overhead but the per-publisher SPF-record TTL itself bounds the per-publisher CIDR-cutover propagation-window; the include_ vs_ip4_vs_a_vs_mx spoke documents the per-literal-CIDR mechanism choice whose zero-DNS-overhead- per-message-evaluation primitive STILL participates in the per- publisher SPF-record TTL- propagation-window THIS page documents at the per-publisher SPF-record-publication boundary; (iv) per-publisher per- mechanism-choice RFC-7208-§4.6.4- TEN-DNS-LOOKUP-CEILING-BUDGET AS LOAD-BEARING per-publisher SPF-publication-budget- discipline COUPLING TO per- publisher TTL-discipline THIS page documents at the per- publisher SPF-record-cutover boundary — every per- publisher per-mechanism choice consumes per-mechanism DNS- lookups from the RFC 7208 §4.6.4 ten-DNS-lookup-ceiling; per- publisher per-mechanism CHOICE- CUTOVER (e.g., flattening include: tokens to ip4: literals to avoid ten-lookup overflow) REQUIRES coordinating the per- publisher SPF-record TTL THIS page documents at the per- publisher mechanism-cutover boundary; the include_vs_ip4_ vs_a_vs_mx spoke documents this per-publisher mechanism-choice- budget-discipline whose every per-mechanism cutover coordinates with the per- publisher SPF-record- propagation-window TTL- discipline THIS page documents. Read the include_vs_ip4_vs_a_ vs_mx spoke alongside this DNS- propagation pillar reference whenever the per-publisher operator scopes a per-publisher SPF-mechanism-choice-cutover plan — the per-RFC-7208-§5- mechanism-catalogue per- mechanism DNS-lookup-overhead discipline the spoke documents IS the canonical per-publisher SPF-mechanism-cutover-budget- discipline whose per-mechanism cutover coordinates with the per-publisher SPF-record TTL propagation-window discipline THIS page documents at the per- publisher per-zone DNS- publication-coordination boundary.
• Domain Security Checker — live DNS lookups for SPF, DKIM, DMARC, BIMI, MTA-STS, TLS-RPT. Performs the multi-resolver verification documented in section 6 automatically and reports both the authoritative state and the public-resolver cache state.
• Email Header Analyzer — paste a received message and inspect the Authentication-Results header to see what SPF / DKIM / DMARC verdicts the receiver applied. Useful when DNS appears correct but the email is still failing.
• DKIM troubleshooting (symptom-driven diagnostic ladder) — the DKIM-SELECTOR-PROPAGATION-WINDOW-AS- DIRECT-UPSTREAM-PRODUCER-OF-PER-RECEIVER- DKIM-VERDICT-LADDER-BRANCHES companion to this DNS-propagation reference. Where THIS page documents the TTL-bounded recursive- resolver cache-ageing model (RFC 1035 §4.1.3 TTL semantics + RFC 2181 §8 RRset-level TTL consistency + RFC 2308 negative-cache NXDOMAIN ageing + RFC 8767 serve-stale fallback), the DKIM-troubleshooting spoke is the OPERATOR- SIDE per-symptom diagnostic ladder whose dkim=temperror and dkim=permerror verdict branches are produced AS-A-DIRECT-DOWNSTREAM- CONSEQUENCE of FOUR DNS-propagation-phase-to- DKIM-verdict-ladder dimensions: (i) per-selector TXT-record publication propagation window at publisher first-key- publication — until the new <selector>._domainkey.< d-domain> TXT propagates to the receiver's resolver-side authoritative cache, receivers querying the not-yet-propagated selector receive NXDOMAIN and emit dkim=permerror per RFC 6376 §6.1.2; the troubleshooting spoke documents the per-symptom branch operators traverse when a freshly-published selector produces per-receiver dkim=permerror surges that decay as propagation completes; (ii) per-selector CNAME-delegation chain propagation at publisher third-party-signer onboarding — when the publisher delegates s1._domainkey.example.com CNAME s1.domainkey.<platform>.com, the CNAME-delegation chain's propagation window across receiver-side recursive resolvers produces a per-receiver dkim=temperror / dkim=permerror surge during the propagation gap; the troubleshooting spoke documents the per-symptom branch operators traverse to attribute these verdicts to the CNAME-delegation propagation rather than to the third-party signer's publication infrastructure; (iii) per-selector dual-key-rotation overlap-window propagation at publisher key- rotation cutover — during a dual-selector rotation where the publisher introduces the new selector before retiring the old, receiver-side resolvers serving stale per-RFC-8767 may continue resolving the old selector AFTER the publisher's signing platform has cut over to the new selector; the troubleshooting spoke documents the per-receiver dkim=fail body-hash-mismatch verdict branch operators traverse during the rotation cutover window to attribute the dkim=fail surge to the stale-resolver propagation gap rather than to a publication-discipline misconfiguration; (iv) per- publisher selector-TXT-record retirement propagation at publisher decommissioning cutover — when the publisher retires the selector-TXT without dual-key overlap-window discipline, in-flight messages signed with the now-retired selector produce dkim=permerror NXDOMAIN verdicts at receivers; the troubleshooting spoke documents the per- symptom recovery branch operators traverse when post-retirement DMARC RUA aggregate evidence surfaces this propagation-driven per-receiver verdict pattern. Read the troubleshooting spoke ALONGSIDE this DNS- propagation reference when a per-receiver per-message DKIM verdict surge correlates with a recent selector-TXT or CNAME- delegation publication, rotation, or retirement event — the spoke is the canonical application-layer diagnostic ladder each DNS-propagation-phase-to-DKIM- verdict mapping resolves to at the per- receiver per-message verification boundary.
• SPF for Microsoft 365 — the per-M365-tenant per-domain v=spf1 include:spf.protection.outlook.com -all publication discipline this spoke documents is a canonical per-zone apex-RR-class publication primitive whose per-tenant publish-and-verify- cycle obeys the per-zone TTL-driven cache-expiry + recursive-resolver warm-up + receiver-side first-hop SPF evaluation timing model THIS page catalogues. Read the M365 SPF spoke as the per-publisher per-domain canonical apex-zone authentication- record-class consumer of the DNS- propagation primitives — every Microsoft-side ESP-cohort addition, cross-tenant SPF flattening, or sender-cohort rotation event the spoke documents resolves through this page's propagation timing primitives at the per-receiver per- message verification boundary.
• DKIM canonicalization — the canonicalization-mode spoke documents the per-publisher per-domain RFC 6376 §3.4 c=-tag choice between c=simple/simple and c=relaxed/relaxed whose per-message DKIM body-hash stability is the LOAD-BEARING upstream determinant of per-message DKIM-verify-pass at every receiver. Four DNS-propagation-vs- canonicalization-mode-stability axes the canonicalization spoke documents that couple to the TTL-bounded publish-and- verify cycle THIS page models: (i) per-selector DKIM public-key TXT- record rotation overlap-window MUST preserve a stable per-publisher canonicalization-mode value across BOTH the deprecating and incoming selector because per-receiver verifier-side cached TXT-record state lags publication by the TTL-bounded propagation tail THIS page documents — a per-publisher per-domain canonicalization-mode flip (e.g. c=simple/simple → c=relaxed/relaxed) co- committed with a selector rotation produces per-receiver per-day dkim=fail verdicts on cryptographically-legitimate mail while the new TXT-record propagates through the global recursive-resolver cache hierarchy; (ii) per-publisher per-domain canonicalization-mode publication consistency across heterogeneous outbound-egress signing MTAs is gated by the per-zone TTL-bounded publish-and- verify cycle THIS page documents — multi-tenant signing-MTA fleets whose canonicalization-mode default is re-aligned (e.g. on-prem Exchange flipping from c=simple body to c=relaxed body) cannot verify the rollout's per-receiver DKIM-pass-rate- floor consequence until the corresponding selector's TXT-record republication propagates through the receiver-side resolver caches per the propagation timing primitives THIS page catalogues; (iii) per-publisher per-domain CNAME- delegated DKIM key publication (M365 selector1/selector2 → onmicrosoft.com, ESP CNAME chains) is STRUCTURALLY ORTHOGONAL to the per-message c=-tag value but the receiver- side resolver MUST walk the CNAME chain to fetch the canonical TXT record whose key-material is used to validate the per-message body-hash computed under the published canonicalization mode — a CNAME-delegation propagation regression (cache-staleness, NXDOMAIN tail, dangling CNAME at the delegation target) produces per-receiver dkim=permerror verdicts indistinguishable from canonicalization- mode publication divergence at the per-receiver per-publisher per-day aggregate-report row level; (iv) per-publisher per-domain canonicalization-mode publication- discipline regression detection during the TTL-bounded propagation tail is STRUCTURALLY BLOCKED until the global resolver-cache warm-up cycle THIS page documents completes — an operator who flips per-publisher canonicalization mode WITHOUT a TTL-floor reduction (lowering the <selector>._domainkey TTL to 300s 24 hours BEFORE the flip) cannot reliably detect per-receiver DKIM-pass-rate regression until the propagation tail completes — the per-receiver per-source-IP DKIM-aligned- pass-rate floor empirically converges only AFTER the resolver-cache warm-up the TTL-bounded publish-and-verify cycle models. Read THIS page when reasoning about per-publisher per-zone DKIM-record publication propagation cadence; read the canonicalization-mode spoke when AUDITING the per-publisher per-domain c=-tag canonicalization-mode choice whose per-message DKIM body-hash stability under legitimate intermediary whitespace normalisation is the LOAD- BEARING upstream determinant of the per-message DKIM-verify-pass verdict that the receiver-side resolver-cache state THIS page models gates at the per-message verification boundary.
• DMARC for Microsoft 365 hybrid Exchange — the hybrid-Exchange dual-egress deployment companion to this DNS- propagation publisher-side TTL-bounded publish-and-verify cycle reference. Where THIS page documents the per-publisher per-RR-type TTL-bounded publish-and- propagate-and-cache-and-invalidate cycle with per-receiver-side resolver-cache state mediating per-message authentication verdicts, the hybrid-Exchange spoke documents the canonical DOWNSTREAM deployment topology where the DNS- propagation cycle materialises across MULTIPLE per-tenant per-custom-domain zones with dual-boundary publication coordination. The DNS-PROPAGATION-VS- HYBRID-EXCHANGE cross-reference establishes FOUR coupling dimensions: (i) per-tenant per-custom-domain multi-RR-type publication coordination — the hybrid-Exchange deployment requires coordinated publication of MX, SPF TXT, DKIM CNAME (for EXO selector1/selector2), DMARC TXT, and per-boundary autodiscover RRs across the SAME zone; the hybrid spoke documents the per-tenant per-domain multi-RR publish-cycle whose per-RR TTL-bounded propagation this page's resolver-cache-state model anchors; (ii) per-publisher per-portfolio dual-boundary publication timing — cloud EXO and on-prem Edge Transport publish into the SAME authoritative-DNS zones but at DIFFERENT operational cadences (cloud EXO rotations are Microsoft-managed, on-prem rotations are operator- managed); the hybrid spoke documents the per-boundary publication- cadence asymmetry whose receiver-side cache-warmup timing this page's per- receiver TTL-bounded propagation cycle gates; (iii) per-tenant DMARC ramp progression coordination with per-receiver DNS-cache state — the hybrid DMARC pct=N ramp must coordinate with per-receiver authoritative-resolver DMARC TXT cache TTL expiry to avoid mid-ramp receiver-side stale-policy application; the hybrid spoke documents the per-tenant per- custom-domain DMARC ramp discipline whose per-receiver TTL-bounded cache invalidation timing this page models; (iv) per-publisher per-domain per-RR-type rollback-window coordination — when a hybrid-Exchange regression requires DMARC posture rollback (e.g., from p=quarantine to p=none), the per-receiver authoritative-resolver TTL-bounded rollback-propagation window must be respected to avoid receiver-side stale-policy persistence beyond the operational expectation; the hybrid spoke documents the per-tenant per-custom-domain rollback discipline whose per-receiver TTL-bounded cache eviction timing this page's resolver-cache-state model anchors. Read the hybrid-Exchange spoke when planning per-publisher per- portfolio per-tenant DNS publication cycles for hybrid Exchange dual- egress boundary deployment.
• SPF qualifiers (+ Four per-publisher per-domain qualifier-ramp-vs-DNS-propagation coupling dimensions: (i) per-publisher per-domain SPF TXT-record TTL discipline as load-bearing per-qualifier-ramp-phase rollback-window-floor — the per-publisher per-domain SPF-record TTL determines the receiver-side resolver-cache eviction window that bounds the per-qualifier-ramp-phase rollback-window-floor — a per-publisher per-domain operator publishing ~all→-all with TTL=3600 has a 1-hour rollback-window-floor for the per-message envelope-authorization-strictness regression detection-and-rollback procedure; (ii) per-publisher per-domain SPF qualifier-ramp during DMARC ramp Phase 5 terminal upgrade as DNS-propagation-coordinated dual-publication event — the per-publisher per-domain operator upgrading from ~all-soft to -all-strict concurrent with DMARC p=quarantine→p=reject must coordinate the per-publisher per-domain DNS-propagation timing window across BOTH the SPF-record and DMARC-record publication events (typically published as a single authoritative-zone commit producing a single per-publisher per-domain DNS-propagation event); (iii) per-publisher per-domain SPF qualifier-ramp rollback via RFC 8767 serve-stale + RFC 2308 negative-cache awareness — when the per-publisher per-domain operator detects a per-customer-domain deliverability regression following a ~all→-all upgrade and publishes a rollback to ~all, the per-receiver-side resolver-cache eviction is governed by the RFC 8767 serve-stale discipline (some resolvers continue serving the cached -all-strict record past TTL until upstream re-verification succeeds) and the per-publisher per-domain operator must coordinate the rollback observability window with the per-receiver per-resolver serve-stale window; (iv) per-publisher per-domain SPF qualifier-ramp during sub-domain delegation as per-zone DNS-propagation-cascade coordination — when the per-publisher per-domain operator splits per-customer-domain SPF authoring across a primary apex + per-ESP subdomain delegation pattern (e.g., v=spf1 include:_spf.mx.<domain> -all + per-ESP subdomain _spf.mx.<domain> RR), the per-publisher per-domain qualifier-ramp on the apex SPF coordinates with the per-publisher per-subdomain DNS-propagation event window the cascade publication produces. Read the SPF-qualifiers spoke alongside this DNS-propagation reference when planning per-publisher per-domain SPF qualifier-strictness ramp progression with explicit DNS-propagation-window coordination, when authoring per-publisher per-domain SPF-record TTL discipline runbooks for per-qualifier-ramp-phase rollback-window-floor planning, or when investigating per-publisher per-domain SPF qualifier-strictness rollback regressions correlating with per-receiver resolver-cache RFC 8767 serve-stale eviction windows.
• DKIM failures explained — the PER-PUBLISHER-PER-SELECTOR-DKIM- TXT-RECORD-DNS-PROPAGATION-WINDOW-AS-LOAD- BEARING-ROOT-CAUSE-OF-TRANSIENT-DKIM-FAILURE companion to this DNS-propagation reference. Where THIS page documents the per-publisher per-zone TTL-bounded publish-and-verify propagation cycle, the per-resolver authoritative-vs-recursive resolution path, the RFC 8767 serve-stale eviction discipline, and the RFC 2308 negative-cache SOA-minimum- TTL bounding, the DKIM-failures-explained spoke is the RECEIVER-SIDE-DOWNSTREAM-CONSUMER whose per-message DKIM-verification verdict class (dkim=permerror / dkim=fail / dkim=neutral / dkim=temperror) is the load- bearing per-message authentication outcome the per-selector TXT-record propagation cycle gates. FOUR per-publisher per-selector DNS-propagation-vs-DKIM-verification-failure coupling dimensions: (i) per-publisher per-selector DKIM TXT-record post-publish propagation tail as load-bearing root cause of transient dkim=permerror (no-record-found) verdicts during the per-resolver cache-fill window — per-publisher operators who newly publish <selector>._domainkey.<domain> TXT records observe per-receiver evaluators return dkim=permerror for the TTL-bounded propagation window until every receiver-side recursive-resolver authoritative- cache layer has fetched the new RR, producing the canonical "we published the DKIM record but receivers still see dkim=permerror" defect class the DKIM-failures spoke catalogues; (ii) per-publisher per-selector rotation overlap-window publish-and-verify cycle as load-bearing precondition preventing dkim=fail (signature-mismatch) verdicts during per-selector cutover — per-publisher operators rotating from an old per-selector key to a new per-selector key MUST publish the new selector AND keep the old selector live across the per-receiver per-resolver-cache-eviction window the TTL discipline this page documents bounds; cutover before the propagation tail completes produces per-message dkim=fail verdicts for in-flight mail signed by the still-cached old selector the receiver can no longer fetch, a per- selector rotation defect class the DKIM-failures spoke catalogues; (iii) per-publisher per-selector revocation-via-empty-p= publish cadence with RFC 2308 negative-caching SOA- minimum-TTL window as load-bearing per-key- compromise revocation latency floor — per-publisher operators revoking a compromised per-selector key via v=DKIM1; p=; empty-public-key publication face a per-receiver per-resolver revocation-effective-latency bounded by BOTH the per-selector TXT-record TTL AND the per- zone SOA-minimum-TTL negative-cache window this page's RFC 2308 reference covers; the DKIM-failures spoke documents how the dkim=fail "revoked key" verdict propagates across the receiver fleet on the timeline this DNS-propagation reference's TTL discipline determines; (iv) per-publisher per-selector CNAME-delegated DKIM key publication via ESP/transactional-vendor delegation chains as DOUBLE-TTL-bounded per-receiver per- resolver propagation-window consumer — per-publisher operators delegating per-selector DKIM publication via CNAME chains (<selector>._domainkey.<customer-domain> IN CNAME <selector>.<esp-domain>.) accumulate TWO TTL-bounded cache-fill windows the per-receiver evaluator must traverse before per-message DKIM verification succeeds — the per-customer-domain CNAME-target-RR cache window plus the per- ESP-domain TXT-public-key cache window — producing a DOUBLE-PROPAGATION-WINDOW receiver-side dkim=permerror floor whose root-cause attribution the DKIM-failures spoke documents at the per- selector CNAME-chain operator-boundary the per-publisher per-customer-domain DKIM- publication discipline anchors. Read the DKIM-failures-explained spoke alongside this DNS-propagation reference when DIAGNOSING per-receiver per-day dkim=permerror / dkim=fail RUA-attributed evidence rows that correlate with a recent per-publisher per-selector TXT-record publication or revocation commit, when PLANNING per-publisher per-selector rotation cadence with explicit per-receiver propagation-window-floor coordination, or when AUTHORING per-publisher per-customer- domain CNAME-delegated DKIM publication runbooks whose double-TTL-bounded propagation- window discipline the DKIM-failures spoke catalogues.
• Email deliverability
• RFC 1035 — Domain Names (Implementation and Specification) — the foundational DNS specification. Section 4.1.3 defines the TTL field; section 7 covers caching.
• RFC 2181 — Clarifications to the DNS Specification — section 8 clarifies that the TTL is a property of the resource record SET, not of individual records. Required reading for understanding TTL behaviour.
• RFC 2308 — Negative Caching of DNS Queries (DNS NCACHE) — defines the SOA MINIMUM field that governs how long NXDOMAIN responses are cached. Relevant when adding new records at names that previously did not exist.
• RFC 8767 — Serving Stale Data to Improve DNS Resiliency — defines the serve-stale behaviour implemented by Cloudflare and some other recursive resolvers that can extend cache lifetime when the authoritative server is unreachable.
• SPF forwarding issues — the canonical operator-side SPF-forwarding-issue remediation reference whose per-forwarder envelope-rewrite + SRS + ARC-rescue remediation playbook depends on the per-publisher TTL discipline and authoritative-nameserver propagation window THIS DNS-propagation reference documents at four DNS-propagation- discipline-to-SPF-forwarding-remediation resolution dimensions: (i) the per- publisher Phase-0 TTL-lowering discipline (drop apex _spf-record TTL from the conventional 24h floor to 5min / 300s 24-48h before the forwarder- remediation cutover) is the load- bearing publication prerequisite for adding an include:srs.forwarder.example or include:bounces.forwarder.example token to the apex SPF record without a stale-cached pre-include record emitting per-receiver-per-source-IP spf=fail during the cutover window; (ii) the per- authoritative-nameserver NOTIFY- plus-AXFR propagation cadence discipline is the load-bearing upstream coordination prerequisite for the per-forwarder SRS rewrite infrastructure to authoritatively attribute the forwarder-rewritten envelope MAIL FROM domain to the forwarder's own SPF-publishing organisational domain rather than to the upstream publisher; (iii) the per-recursive-resolver negative-cache TTL discipline (RFC 2308 SOA-minimum-controlled NXDOMAIN cache for missing v=spf1 tokens) is the load-bearing per-receiver upstream-prerequisite for the per-forwarder include-token- addition cutover to propagate to Gmail / Outlook / Yahoo downstream consumers within the per-receiver-evaluation-window bound; and (iv) the per-publisher glue-record + delegation-record propagation discipline at the parent TLD's authoritative servers is the load-bearing per-zone upstream prerequisite for adding a dedicated _spf delegation subdomain (e.g. spf1.example.com → spf2.example.com bounce-tree-decomposition pattern) to mitigate the RFC 7208 §4.6.4 ten-DNS-lookup-ceiling overflow that a forwarder-include-token addition routinely triggers. Read the SPF-forwarding-issues spoke ALONGSIDE this DNS-propagation reference whenever the publisher scopes a per-publisher per-zone forwarder-include-remediation cutover plan — the per-publisher TTL + per-resolver negative-cache + per-authoritative-nameserver propagation cadence THIS page documents IS the load-bearing publication-discipline framework every SPF-forwarding-remediation cutover depends on.
• DMARC monitoring discipline — where THIS page documents the per-recursive-resolver TTL-bounded cache-aging behaviour governing WHEN a newly-published or rotated DNS RR becomes observable across the per-receiver resolver population, the DMARC-monitoring spoke documents the per-publisher per-domain standing observability discipline whose aggregate-XML evidence stream IS the LOAD- BEARING per-publisher per-receiver per-day evidence primitive that CONFIRMS the propagation window THIS page describes has completed at the per-receiver scope. FOUR structurally-distinct DNS- PROPAGATION-WINDOW-TO-MONITORING- KPI coupling dimensions the DMARC-monitoring spoke operationally documents: (i) per-publisher per-domain DMARC-pass-rate KPI rise after a newly-published SPF / DKIM / DMARC TXT-record as load-bearing per-receiver propagation- completion confirmation primitive — the rua aggregate-XML dmarc/result=pass rate at the per-publisher per- domain per-receiver per-day scope rising after the cache-aging window THIS page documents is the LOAD-BEARING observable per- receiver propagation-completion signal the DMARC-monitoring spoke's KPI framework surfaces; (ii) per-source-IP alignment-failure rate alert threshold as load-bearing post- rotation regression-detection primitive bounded by the per-RR- TTL propagation window — when a per-publisher per-domain DKIM-selector rotation or SPF- include-zone change is published, the DMARC-monitoring spoke's per-source-IP alignment-failure alert threshold detects any regression bounded by the per-RR- TTL propagation window THIS page documents the duration of; (iii) per-publisher per- receiver coverage drift KPI as load-bearing per-recursive- resolver propagation-coverage primitive across the receiver population — the DMARC- monitoring spoke's per-receiver coverage KPI (the set of receivers actively sending rua reports about the per-publisher per-domain) surfaces per-recursive- resolver propagation-coverage variance at the per-publisher per-domain per-receiver scope — when a previously-covered receiver disappears from the rua report stream, the per-recursive- resolver cache-aging behaviour THIS page documents at the per-receiver scope is the load- bearing diagnostic primitive bounding the receiver-side cache- coherence investigation; (iv) per-publisher post- publication review cadence synchronized to the per-RR-TTL propagation window as load- bearing publisher-operator operational discipline — the DMARC-monitoring spoke's per-week / per-month / per- quarter operational review cadence provides the standing per-publisher per-domain review framework that materially synchronizes the post-publication regression-detection review agenda to the per-RR-TTL propagation window THIS page documents the duration of. Read the DMARC-monitoring spoke ALONGSIDE this DNS-propagation reference whenever the publisher scopes a per-publisher per-domain DNS-publication-discipline framework — the per-publisher per-domain DNS-propagation window THIS page documents IS the load- bearing publication-prerequisite primitive, and the DMARC- monitoring observability discipline IS the load-bearing downstream confirmation primitive that surfaces per-receiver propagation-completion at the per- publisher per-domain per-receiver per-day rua aggregate-XML evidence-stream scope.
• DMARC for transactional email — the PER-ESP-PER-CUSTOMER-DOMAIN- CNAME-CHAIN-DNS-PROPAGATION-WINDOW companion to this DNS-propagation operator reference. Where THIS page documents the canonical per-RR per- TTL per-resolver-cache propagation- completion infrastructure (per-RR- TTL-bounded propagation window, per- receiver-resolver-cache eventual- consistency timing, the per-publication- event propagation-completion confirmation observability discipline), the transactional-email spoke is the per- ESP per-customer-domain deployment- execution companion documenting FOUR transactional-DNS-propagation coordination dimensions whose per- customer satisfaction gates per- message DKIM-verification at the per-customer-domain transactional outbound flow's first message: (i) per- customer-onboarding CNAME-chain DNS-propagation is the load-bearing upstream precondition for first- message DKIM-verification — when a per-customer-domain operator onboards to SendGrid / Mailgun / Amazon SES / Postmark / SparkPost, the operator publishes per-selector CNAME records (s1._domainkey.<customer-domain> → s1.domainkey.u123.wl456.sendgrid.net) whose per-RR-TTL propagation window THIS page documents must complete before the first per-customer- domain transactional message can produce dkim=pass at the receiver-side; the transactional- email spoke documents the per-ESP per-customer-domain onboarding-to- first-send propagation discipline; (ii) per-ESP per-customer- domain selector-rotation DNS- propagation gates the dual-selector overlap window at the per-customer- domain transactional outbound flow — when SendGrid / Mailgun / Amazon SES / Postmark / SparkPost rotate per-customer- domain DKIM selectors, the per-RR- TTL DNS-propagation window THIS page documents BOUNDS how long the publisher must maintain the old selector's per-receiver-resolver- cache validity before transitioning the signing path to the new selector; the transactional-email spoke documents the per-ESP per- customer-domain rotation cadence and the per-RR-TTL-bounded dual-selector overlap discipline; (iii) per- customer-domain SPF include-target DNS-propagation is the load-bearing upstream precondition for per-ESP include-chain evaluation — when a per-customer-domain operator publishes an SPF record including include:sendgrid.net, the per-RR-TTL DNS-propagation window THIS page documents must complete before the receiver-side SPF evaluator's per-mechanism sweep can resolve the include-target against the per-receiver-resolver- cache; the transactional-email spoke documents the per-customer- domain SPF-publication propagation discipline; (iv) per-customer- domain RUA-mailbox publication DNS-propagation is the load-bearing upstream precondition for per-ESP per-customer-domain RUA aggregate- XML delivery — when a per- customer-domain operator publishes _dmarc.<customer-domain> with a rua= mailbox external to the customer's organisational domain (the per-ESP per-customer-domain RUA delegation pattern), the per-RR-TTL DNS- propagation window THIS page documents must complete before the receiver-side reporter can resolve the per-customer-domain external- destination-verification TXT record; the transactional-email spoke documents the per-ESP per-customer- domain RUA-mailbox publication propagation discipline. Read the transactional-email spoke ALONGSIDE this DNS-propagation reference whenever the operator scopes a per- customer-domain transactional-email deployment on SendGrid / Mailgun / Amazon SES / Postmark / SparkPost — the per-RR-TTL DNS-propagation window THIS page documents IS the load-bearing per-publication-event propagation-completion primitive the transactional-email deployment guide encodes the per-ESP per- customer-domain execution discipline for.
• DMARC multi-domain strategy — the PER-ORGANISATION-DOMAIN-FAMILY- DNS-PROPAGATION-COORDINATION companion to this per-RR-TTL DNS-propagation reference. Where THIS page documents the per-RR-TTL DNS-propagation window (per-authoritative-nameserver publication-event timing, per- recursive-resolver cache TTL consumption, per-NXDOMAIN negative- cache TTL behaviour, per-zone propagation-monitoring discipline), the multi-domain-strategy spoke is the PER-ORGANISATION-DOMAIN-FAMILY- DNS-PROPAGATION-COORDINATION companion documenting how the per-RR-TTL DNS- propagation discipline scales across the organisation's complete domain family at FOUR per-organisation- domain-family-DNS-propagation- coordination dimensions: (i) per-active-domain per-RR-TTL coordination is the per-active-domain publication-event propagation instantiation — the multi- domain-strategy spoke documents how every actively-published RR across the organisation's domain family (per-domain SPF TXT, per-domain DKIM TXT, per-domain DMARC TXT, per-domain MTA-STS TXT, per-domain MX RRSET) follows the per-RR-TTL propagation discipline THIS page documents at each per-domain authoritative nameserver; (ii) per-parked- or-defensive-registered domain DNS- publication-discipline is the per- non-active-domain minimal-publication propagation instantiation — the multi-domain-strategy spoke documents how parked domains and defensive registrations follow a minimal-publication discipline (null- MX, restrictive SPF, locked DMARC p=reject) whose per-RR- TTL propagation discipline THIS page documents must complete before the per-organisation-domain-family defensive posture is operationally effective; (iii) per- organisation-wide multi-zone- publication-event coordination is the per-domain-family-wide simultaneous- rollout instantiation — the multi-domain-strategy spoke documents how organisation-wide DNS-publication events (DMARC enforcement ramp, DKIM key rotation, MTA-STS policy ramp) scale when the organisation's domain family includes dozens of actively- publishing zones each requiring independent per-zone propagation- completion tracking before the per- organisation-wide enforcement event is operationally complete; and (iv) per-organisation-domain- family DNS-propagation-coordination is the upstream operational- prerequisite of per-organisation- domain-family DMARC-publication- coordination — the multi- domain-strategy spoke documents how the per-RR-TTL DNS-propagation discipline THIS page documents is the upstream operational-prerequisite for every per-organisation-wide DMARC- publication-event the multi-domain- strategy spoke catalogues across the organisation's domain family — every per-zone DMARC publication-event must propagate fully before the per-domain DMARC policy is operationally active.
• SPF 10-DNS-lookup limit (RFC 7208 §4.6.4) — the PER-NESTED-INCLUDE-PROPAGATION- RACE-WINDOW companion to this DNS- propagation reference. Where THIS page documents the canonical Phase 0 TTL- discipline + gradual-aging-out-of-cached- records model (RFC 1035 §3.2.1 + RFC 2181 §8) that governs how authoritative DNS edits reach every recursive resolver across the public Internet, the SPF- lookup-limit spoke is the per-publisher per-domain cumulative-mechanism lookup- budget ARITHMETIC REFERENCE documenting the RFC 7208 §4.6.4 10-lookup hard ceiling whose nested-include: cost accounting is PROPAGATION-DEPENDENT — every per-publisher per-domain SPF- leg include:spf.<provider>. tld mechanism the publisher appends causes the receiver-side SPF engine to recurse into the provider's published SPF record, and the receiver- observed per-mechanism cost depends on whether that provider-side record has propagated to the receiver's recursive resolver yet. The DNS-PROPAGATION-VS-SPF- LOOKUP-LIMIT cross-reference establishes the per-publisher propagation-race discipline that every SPF-leg edit must observe: (i) per-publisher per- domain SPF-record-edit propagation window — when a publisher edits the apex SPF record, the per- receiver per-recursive-resolver observation of the new record's lookup cost is staggered across the 4-to-24- hour propagation window; (ii) per-provider nested-include: record-edit propagation window — when a provider (M365's spf.protection.outlook.com, Google's _spf.google.com, SendGrid's sendgrid.net) edits THEIR published SPF record to add or remove nested mechanisms, every publisher who references the provider's include: mechanism observes a transient propagation-window per- recursive-resolver discrepancy in the cumulative lookup count — some receiver- side resolvers see the old cost (e.g. 3 lookups), some see the new cost (e.g. 5 lookups), and the publisher's per- domain SPF-baseline interpretation must account for the possibility that the cumulative ceiling is crossed for SOME recursive resolvers but not others during the provider's propagation window; (iii) per-publisher Phase-0 TTL-lowering discipline at SPF- edit — the canonical Phase 0 prerequisite THIS page documents (lower the TTL one full TTL period BEFORE you change the record) applies identically to the SPF-leg apex TXT-record edit because the per-receiver per-recursive-resolver SPF-baseline interpretation depends on the SPF record having propagated end-to-end before the publisher can claim spf=pass stability. Read THIS page when PLANNING the per-zone TTL-lowering discipline that precedes every DNS-leg edit; read the SPF- lookup-limit spoke when SEQUENCING a per-publisher per-domain SPF-leg include: append around the propagation window of the provider's published SPF record, or when AUDITING the per-publisher per-domain SPF- baseline cumulative lookup-count stability across the multi-hour propagation window each SPF-leg edit incurs.
• Phishing protection — the DEFENDER-SIDE-PHISHING-ATTACK- CLASS-ENUMERATION-AT-PER-PROTOCOL-LAYER- MITIGATION-PILLAR companion to this DNS- propagation reference. Where THIS page documents the canonical Phase 0 TTL- discipline + gradual-aging-out-of-cached- records model (RFC 1035 §3.2.1 + RFC 2181 §8) plus the emergency-rollback case for short TTLs when an inadvertent policy advance breaks legitimate mail, the phishing-protection cluster-level enumeration spoke is the cluster-level DEFENDER-SIDE-PHISHING-ATTACK-CLASS- CATALOGUE REFERENCE documenting the six canonical per-protocol-layer phishing attack classes plus the per-protocol- layer mitigation pillar that closes each class. The DNS-PROPAGATION-VS-PHISHING- PROTECTION cross-reference establishes that the per-zone TTL-discipline operational baseline THIS page documents IS the per-phishing-incident-response- window mitigation pillar for the live- active-phishing-incident response workflow: (i) per-publisher per- domain rapid policy-rollback at compromised-signing-key incident — when a per-publisher per- selector DKIM private key is exfiltrated, the rotation-revocation publication via empty p= must propagate to every recursive resolver before the compromised key stops being honoured at per-receiver verification time; the per- zone TTL discipline determines the per- receiver per-resolver propagation window for the revocation; (ii) per- publisher per-domain DMARC enforcement- tightening at active-phishing-incident — when an active phishing campaign is impersonating the publisher's sending domain, the per-publisher per- domain emergency p=none → p=reject advance must propagate to every recursive resolver before per-receiver per-message dmarc=fail rejection takes effect on the phishing flow; (iii) per-receiver per-policy-cache invalidation at MTA-STS / TLS-RPT rotation — when a per-publisher MTA-STS policy-file edit is published to close an active downgrade-to-plaintext phishing-interception attack, the per- receiver per-policy-file max_age: cache TTL plus the DNS-leg _mta-sts.<domain> TXT-RR propagation must complete before every receiver honours the new policy. Read THIS page when AUTHORING per-zone TTL discipline that precedes every per- protocol-layer security edit; read the phishing-protection cluster-level enumeration spoke when MAPPING per-zone propagation timing to the per-attack- class defender-side incident-response workflow, or when CO-AUDITING the per- publisher per-protocol-layer mitigation- pillar completeness across SPF / DKIM / DMARC / BIMI / MTA-STS / TLS-RPT / CAA / ARC at per-attack-class closure boundaries.
• Email spoofing explained — the per-publisher per-domain DNS- publication-discipline as upstream anti-spoofing mitigation primitive companion to this DNS propagation operator-reference. Where THIS page documents the per-publisher per-domain authoritative-DNS publication-discipline- vs-recursive-resolver TTL-propagation rhythm (the per-zone NS-record-published TTL, the per-RR-publication negative- cache TTL, the per-recursive-resolver cache-expiry-vs-authoritative-edit propagation window), the email-spoofing spoke is the PER-ATTACK-CLASS DOWNSTREAM-CONSUMER REFERENCE documenting the per-publisher per- domain attack-surface catalogue whose per-attack-class defender-side mitigation discipline structurally consumes the upstream per-publisher per- domain authoritative-DNS publication- discipline correctness (a per-publisher per-domain SPF / DKIM-selector / DMARC / BIMI / MTA-STS / TLS-RPT / CAA TXT-or- CNAME-RR publication-discipline regression emits per-attack-class anti- spoofing mitigation-pillar gaps until the per-zone authoritative-DNS-vs- recursive-resolver TTL-propagation window has fully cleared). Pair this page (the per-publisher per-domain DNS- propagation rhythm reference) with the email-spoofing spoke (the per-attack- class catalogue reference) when designing the per-publisher per-domain anti- spoofing-mitigation publication-discipline cadence — the spoke documents the per- attack-class mitigation-pillar publication-discipline-correctness constraint the per-publisher per-domain operator MUST track AGAINST the per- zone authoritative-DNS-vs-recursive- resolver propagation rhythm THIS page documents.
• DMARC myths and misconceptions — the DNS-PROPAGATION-INDUCED- MYTH-DEBUNK-COMPANION to this propagation-rhythm reference. Where THIS page documents the per-publisher per-zone DNS-publish-and-verify-cycle mechanics (the per-RR TTL-bounded cache-fill rhythm, the per-resolver authoritative-vs-recursive resolution path, the per-zone SOA-serial increment discipline, the per-RR negative-caching SOA-minimum-TTL bounding, the per-zone NS-delegation publication-window) that gates every per-receiver per-day per- publisher per-day per-RR-class publication-observability cycle, the myths-and-misconceptions spoke is the MISCONCEPTION-CATALOGUE companion documenting FOUR propagation-induced myth classes whose per-publisher per- domain DMARC-deployment mental-model REBUTTAL is the PREREQUISITE the per- publisher per-domain operator MUST INTERNALISE before reading the per- receiver per-day per-publisher per-day DMARC-aligned-pass-rate-floor reading whose propagation-induced per-zone cache-coherence gap this page diagnoses: (i) myth 7 — "Going straight to p=reject is fine if my records look right" — the per-publisher per- domain operator-side misconception that per-publisher per-domain DMARC-record SYNTACTIC-CORRECTNESS ALONE is sufficient to declare per-publisher per-domain enforcement readiness — when the per-zone DNS-publish-and-verify- cycle propagation-window THIS page documents (per-publisher per-receiver per-RR TTL-bounded cache-fill latency vs per-publisher per-zone TTL-edit cadence) is the LOAD-BEARING per- receiver-side per-message DNS-cache- coherence prerequisite the per-receiver per-message DMARC verdict per RFC 7489 §6.6 structurally depends on — the per-publisher per-domain operator MUST observe the per-publisher per-zone per-RR propagation-window has fully cleared BEFORE ramping policy to p=quarantine / p=reject enforcement; (ii) myth 8 — "pct=10 means 10% of attackers get blocked" — the per-publisher per-domain operator- side misconception that the per- publisher per-domain DMARC pct= tag per RFC 7489 §6.3 is a per-attacker- targeting filter rather than a per- sampling-RNG percentage applied to per-receiver per-message DMARC-aligned- fail verdict population — compounded by the per-publisher per-zone DNS-propagation window THIS page documents whose per- receiver per-resolver per-RR cache-fill latency makes per-publisher per-zone pct=-tag edits propagate asynchronously across the per-receiver per-resolver footprint, producing per- receiver per-day per-publisher per-day DMARC-aligned-pass-rate-floor sampling artifacts the per-publisher per-domain operator misattributes to per-publisher per-domain attacker behaviour rather than per-publisher per-zone pct= sampling-RNG percentage propagation race-condition; (iii) myth 18 — "Once DMARC is at p=reject I can stop monitoring" — the per-publisher per-domain operator-side misconception that per-publisher per-domain DMARC- enforcement steady-state cancels the per-publisher per-zone per-RR publication-discipline-observability cadence — when the per-publisher per- zone per-RR TTL-bounded propagation rhythm THIS page documents is a CONTINUOUS per-RR-cutover-coordination per-receiver per-day per-publisher per- day per-RR-class cache-coherence publication-discipline cadence the per-publisher per-domain operator MUST sustain at every per-publisher per-zone per-RR v=DMARC1 / per- selector v=DKIM1 / per- SPF-v=spf1 publication-edit BEYOND the initial per-publisher per- domain DMARC-record publication; and (iv) myth 4 — "DMARC alone is enough — no need for MTA-STS" — the per-publisher per-domain operator- side misconception that per-publisher per-domain DMARC publication-discipline ALONE is sufficient to declare per- publisher per-domain anti-spoofing- mitigation-pillar publication-discipline- completeness — when the per-publisher per-zone per-RR-class propagation- coordination cadence THIS page documents explicitly catalogues per-publisher per- domain MTA-STS / TLS-RPT / DANE / CAA publication-discipline cadences each with their own per-publisher per-zone per-RR TTL-bounded publish-and-verify propagation-window the per-publisher per- domain operator MUST sustain in parallel with the per-publisher per-domain DMARC publication-discipline cadence per the per-publisher per-domain anti-spoofing- mitigation-pillar publication-discipline- completeness invariant. Pair this DNS- propagation reference with the myths- and-misconceptions spoke when explaining the per-publisher per-domain per-zone propagation-induced per-receiver per- day per-publisher per-day DMARC-aligned- pass-rate-floor reading interpretation discipline to a stakeholder who has internalised one or more of the four myth classes above — the myths-page documents the PER-MISCONCEPTION-CLASS REBUTTAL-DISCIPLINE the per-publisher per-domain operator MUST DEPLOY at the stakeholder-conversation boundary, and THIS page documents the PER-ZONE PER- RR PROPAGATION-WINDOW PROTOCOL-LEVEL ROOT-CAUSE the per-misconception-class rebuttal-discipline materially attributes against.
• How attackers bypass weak DMARC — the WEAK-DMARC-ATTACK-SURFACE-CATALOGUE companion to this DNS-propagation timing reference. Where THIS page documents the per-RR TTL-bounded cache-fill cycle (RFC 1035 §4.1.3 + RFC 2181 §8), the authoritative-vs-recursive resolver path, the RFC 8767 serve-stale behaviour, the per-RR-type TTL selection cadence, and the publish-and-verify cycle discipline, the DMARC-attacker-bypass spoke catalogues the per-attacker per-message DMARC-side bypass attack-variants the per-publisher per-domain DNS-propagation-window hygiene defends against — the per-publisher per- domain DMARC policy-mode ramp transition window (p=none → p=quarantine pct=N → p=reject) exposes a per- recursive-resolver per-RR TTL-bounded cache-coherence window during which attackers can exploit stale p=none-cached posture to deliver attacker-Friendly-From- spoofed messages while the per-publisher per-domain DMARC posture has actually ramped to p=quarantine or p=reject at the authoritative nameserver. Similar overlap- window exposures during SPF mechanism- rewrites (the per-publisher per-domain pre-publication ip4: / ip6: / include: cascade remains cached at the receiver- side recursive resolver while the new mechanism set is authoritative), DKIM selector-rotation publication, and authoritative-NS migrations widen the per- attacker per-message attack-window the DNS-propagation discipline THIS page documents structurally closes at four DNS-propagation-window-discipline-vs- DMARC-attacker-bypass-surface coupling dimensions: (i) per-publisher per-domain DMARC TTL selection as policy-ramp window coverage discipline — short per-record TTL (300-3600s) selection compresses the per- recursive-resolver per-RR cache-coherence window during DMARC policy-mode ramps, narrowing the attacker-bypass attack- window; (ii) per-publisher per-domain pre- publication TTL-reduction discipline before policy-mode ramps — the per- publisher per-domain TTL-reduction cycle (drop TTL to 300s several days BEFORE the policy-mode ramp, wait for cache-fill, ramp policy, re-extend TTL after cache- fill complete) is the canonical bypass- window closure cadence the DNS-propagation reference THIS page documents enables; (iii) per-publisher per-domain authoritative-vs-recursive coordination during NS migrations — the per-publisher per-domain authoritative-NS migration window exposes a per-recursive-resolver cache-coherence window where the per- publisher per-domain DMARC posture diverges between the legacy authoritative- NS state and the new authoritative-NS state, widening the attacker-bypass attack-window; and (iv) per-publisher per- domain RFC 8767 serve-stale behaviour as DMARC-posture-cache-extension consideration — recursive resolvers implementing serve- stale can extend the per-publisher per- domain pre-ramp DMARC posture cache- lifetime past the intended TTL during authoritative-NS unreachability, widening the per-attacker per-message bypass window the per-publisher per-domain DMARC policy- mode ramp intended to close. Read THIS page when AUTHORING the per-publisher per- domain DNS-propagation timing discipline for DMARC policy-mode ramps or SPF / DKIM record-rewrites; read the DMARC-attacker- bypass catalogue spoke when AUDITING the per-publisher per-domain DMARC policy-mode ramp window against the per-attacker per- message bypass attack-class catalogue the per-publisher per-domain DNS-propagation discipline THIS page documents structurally compresses at the per-recursive-resolver per-RR cache-coherence boundary.
• SPF mechanisms explained — the PER-PUBLISHER-PER-DOMAIN-SPF- MECHANISM-AUTHORING-DISCIPLINE-AS-LOAD- BEARING-DNS-PUBLICATION-WORKLOAD-DRIVING- PER-RECURSIVE-RESOLVER-PER-RR-CACHE- PROPAGATION-WINDOW companion to THIS DNS- propagation discipline reference. Where THIS page documents the per-publisher per- domain DNS-publication propagation discipline (per-recursive-resolver per-RR cache-coherence behavior, per-RR TTL-driven cache-expiry cadence, per-recursive- resolver negative-caching per RFC 2308, per-recursive-resolver serve-stale per RFC 8767, per-recursive-resolver per-RR cache- propagation-window staging discipline, per-authoritative-nameserver per-RR publication-cutover-against-cache-coherence staging discipline), the SPF-mechanisms- explained spoke is the PER-PUBLISHER-PER- DOMAIN-SPF-PUBLICATION-WORKLOAD-AS-CANONICAL- DNS-PROPAGATION-WORKLOAD companion at FOUR per-SPF-mechanism-authoring-vs-DNS- propagation coupling dimensions: (i) per-publisher per-domain SPF include: cascade-delegation publication-workload AS per-publisher per-domain multi-RR multi- zone DNS-publication-workload driving per- recursive-resolver per-RR per-zone cache- propagation-window cascade — the per-publisher per-domain SPF include: cascade-delegation mechanism the SPF- mechanisms-explained spoke documents (per- publisher per-domain include: cascade-list spanning per-publisher per-domain authoritative-nameserver-published TXT-RR PLUS per-third-party-SaaS-sender authoritative-nameserver-published TXT-RR cascade) IS the per-publisher per-domain multi-RR multi-zone DNS-publication- workload driving per-recursive-resolver per-RR per-zone cache-propagation-window cascade behavior THIS page documents the per-recursive-resolver per-RR cache- coherence-staging discipline of; per- publisher per-domain operators stage per- publisher per-domain include: cascade- modifications against per-zone TTL-driven cache-expiry cadence cascade at the per- publisher per-domain multi-zone publication-staging boundary; (ii) per-publisher per-domain SPF ip4: / ip6: range publication-staging operational discipline AS per-publisher per-domain authoritative-nameserver- published TXT-RR publication-staging operational discipline against per- recursive-resolver per-RR cache- propagation-window — the per-publisher per-domain SPF ip4: / ip6: range publication-staging operational discipline the SPF-mechanisms-explained spoke documents (per-publisher per-domain new-ip4: range publication BEFORE per- source-IP first-message emission, per- publisher per-domain retired-ip4: range removal AFTER per-source-IP last-message emission + per-DNS-propagation-window grace period) IS the per-publisher per- domain authoritative-nameserver-published TXT-RR publication-staging operational discipline against per-recursive-resolver per-RR cache-propagation-window THIS page documents the per-recursive-resolver per- RR cache-coherence-staging discipline of; per-publisher per-domain operators stage per-publisher per-domain SPF TXT-RR ip4: / ip6: range modifications against per-RR TTL-driven cache-expiry cadence at the per-publisher per-domain SPF-TXT-RR publication-staging boundary; (iii) per-publisher per-domain SPF a: / mx: FQDN-resolution mechanism-publication AS per-publisher per-domain per-message runtime-DNS-resolution workload feeding per-recursive-resolver per-FQDN per-RR cache-population — the per- publisher per-domain SPF a: / mx: FQDN- resolution mechanism the SPF-mechanisms- explained spoke documents (per-publisher per-domain per-message per-receiver-side SPF-evaluator a: per-FQDN A/AAAA-RR resolution, per-publisher per-domain per- message per-receiver-side SPF-evaluator mx: per-FQDN MX-RR resolution + per-MX- host A/AAAA-RR resolution) IS the per- publisher per-domain per-message runtime- DNS-resolution workload feeding per- recursive-resolver per-FQDN per-RR cache- population behavior THIS page documents the per-recursive-resolver per-FQDN per- RR cache-coherence discipline of; per- publisher per-domain operators reason about per-message per-receiver-side SPF- evaluator per-FQDN cache-population latency against per-recursive-resolver per-FQDN per-RR TTL-driven cache-expiry cadence at the per-publisher per-domain per-message runtime-DNS-resolution- latency boundary; (iv) per- publisher per-domain composite SPF + DKIM + DMARC + MTA-STS + TLS-RPT publication- floor coordination AS load-bearing per- publisher per-domain operator-side unified-DNS-publication-discipline-floor — the per-publisher per-domain SPF mechanism-authoring publication discipline the SPF-mechanisms-explained spoke documents IS the load-bearing per-publisher per-domain envelope-MAIL-FROM-layer DNS- publication discipline leg of the per- publisher per-domain composite SPF + DKIM + DMARC + MTA-STS + TLS-RPT publication- floor coordination posture the per- publisher per-domain DNS-propagation discipline THIS page documents the per- recursive-resolver per-RR cache- coherence-staging discipline of; per- publisher per-domain operators stage ALL FIVE per-publisher per-domain protocol- layer publications coordinated at the per-publisher per-domain unified-DNS- publication-staging-discipline boundary against per-recursive-resolver per-RR cache-coherence-staging cadence. Read THIS page when STAGING per-publisher per- domain DNS-RR publications against per- recursive-resolver per-RR cache-coherence cadence; read the SPF-mechanisms- explained spoke when AUTHORING the per- publisher per-domain SPF mechanism-choice publication discipline whose per- publisher per-domain include cascade- delegation + per-publisher per-domain a: / mx: FQDN-resolution + per-publisher per-domain ip4: / ip6: literal-range publication-workload IS the per-publisher per-domain canonical DNS-publication workload driving per-recursive-resolver per-RR cache-propagation-window behavior THIS page documents the per-publisher per-domain DNS-publication propagation- discipline of.
• DKIM replay attacks
• DMARC for SaaS senders — the PER-SAAS-TENANT-PER-CUSTOMER- DOMAIN-CNAME-DELEGATED-RR-FANOUT-AS-LOAD- BEARING-PER-RECURSIVE-RESOLVER-CACHE- PROPAGATION-WINDOW-CONSUMER companion to this DNS propagation reference. Where THIS page documents the per-publisher per-domain DNS-publication TTL-bounded per-recursive- resolver cache-propagation-window discipline (RFC 1035 §4.1.3 TTL semantics, RFC 2181 §8 cache-propagation cadence, RFC 2308 NCACHE negative-caching, RFC 8767 serve-stale resiliency), the SaaS-senders spoke is the PER-SAAS-TENANT-PER-CUSTOMER- DOMAIN MULTI-TENANT DNS-PUBLICATION-FANOUT consumer the per-SaaS-tenant operator consults when authoring per-customer-domain CNAME-delegated RR publication at scale. Four per-SaaS-tenant DNS-propagation coordination dimensions: (i) PER-SAAS- TENANT-PER-CUSTOMER-DOMAIN-CNAME-DELEGATED- SELECTOR-PUBLICATION-TTL-FLOOR (per-customer- domain selector._domainkey CNAME publication TTL floor across N customer- domains determines per-SaaS-tenant DKIM-key- rotation propagation cadence — per-customer-domain TTL fragmentation produces per-receiver per-recursive-resolver per-customer-domain cache-staleness drift); (ii) PER-SAAS-TENANT-PER-CUSTOMER-DOMAIN- SPF-INCLUDE-CASCADE-DNS-LOOKUP-EXHAUSTION (per-customer-domain SPF include:_spf.<saas-tenant> consumes per-customer-domain RFC 7208 §4.6.4 10-DNS-lookup budget across per-recursive-resolver cache-warmup propagation windows); (iii) PER-SAAS-TENANT- PER-CUSTOMER-DOMAIN-DMARC-RUA-MAILTO- EXTERNAL-DESTINATION-VERIFICATION- PROPAGATION (per-customer-domain DMARC rua=mailto:agg@<saas-tenant> external-destination authorisation via per-customer-domain <customer-domain>._report._dmarc.<saas-tenant> TXT-RR publication requires per-recursive- resolver cache-propagation across N customer-domains); (iv) PER-SAAS-TENANT- PER-CUSTOMER-DOMAIN-NCACHE-NEGATIVE-CACHE- WINDOW-DURING-CUSTOMER-DOMAIN-ONBOARDING (per-recursive-resolver NCACHE negative- caching of NXDOMAIN responses for newly- added per-customer-domain CNAME publications delays per-receiver-side per-message signature verification readiness during per-customer-domain onboarding). Read the SaaS-senders spoke alongside this DNS- propagation guide when AUTHORING per-SaaS- tenant per-customer-domain DNS-publication TTL-discipline, when ONBOARDING new per- customer-domains across per-recursive- resolver NCACHE windows, or when PLANNING per-SaaS-tenant per-customer-domain DKIM key-rotation propagation cadences across N customer-domains.
• DMARC reporting pipeline — the PER-PUBLISHER-PER-DOMAIN-DMARC-TXT- RR-AT-_dmarc.<d>-DNS- PUBLICATION-DISCIPLINE-PROPAGATION-CADENCE- AS-LOAD-BEARING-PER-PUBLISHER-PER-DOMAIN- DMARC-RUA-AGGREGATE-REPORT-EMISSION- READINESS-PRECONDITION companion at four DNS-propagation-vs-DMARC-RUA-reporting- pipeline coupling dimensions: (1) per- publisher per-domain DMARC TXT-RR publication at _dmarc.<domain> per RFC 7489 §6.1 carries the per-publisher per-domain rua=mailto: aggregate- report-URI per RFC 7489 §6.2 whose per- receiver per-recursive-resolver DNS propagation cadence (per-zone authoritative publication latency + per-recursive-resolver TTL-honored caching window + per-stub- resolver NCACHE per RFC 2308 §5) IS the load-bearing per-publisher per-domain DMARC RUA aggregate-report receiver-side discovery precondition the per-publisher per-domain DMARC RUA aggregate-report-pipeline THIS DNS-propagation guide is the upstream- propagation primer of structurally depends on; (2) per-publisher per-domain DMARC _dmarc.<d> TXT-RR publication-discipline TTL-tuning IS the per-publisher per-domain operator-side rollout-cadence control whose per-recursive- resolver propagation tail must converge before per-receiver per-day DMARC RUA aggregate-report emission begins — the per- receiver per-day per-source-IP per-row aggregate-report stream the reporting- pipeline spoke documents only becomes operator-observable AFTER the per-receiver per-recursive-resolver TXT-RR propagation convergence the DNS-propagation guide documents; (3) per-publisher per-domain DMARC TXT-RR mid-rollout cutover (e.g. p=none → p=quarantine or adding a second rua=mailto: endpoint) requires per-publisher per-domain DNS-propagation-cadence-aware publication sequencing — without TTL-discipline coordination, per-receiver per-day DMARC RUA aggregate-reports during the propagation tail surface inconsistent per-receiver-cached <policy_published> attribution per RFC 7489 §7.2.1.2 distorting the per-publisher per-domain per-day per-receiver aggregate-evidence stream; (4) per-publisher per-domain DMARC TXT-RR propagation-discipline at _dmarc.<d> IS structurally parallel to per-publisher per-selector DKIM TXT-RR propagation- discipline at <selector>._domainkey.<d> and per-publisher per-domain SPF TXT-RR propagation-discipline at apex — all three per-publisher per-domain DNS-TXT-RR publication-discipline-propagation-cadence primitives jointly underpin the per- publisher per-domain composite cross- protocol DNS-publication-discipline- readiness baseline the per-publisher per- domain DMARC RUA aggregate-report-pipeline attribution-stream the reporting-pipeline spoke documents structurally consumes.
• DMARC for Microsoft 365 — the PER-M365-TENANT-PER-ACCEPTED-DOMAIN-DMARC-TXT-RR-DNS-PUBLICATION-DISCIPLINE-AS-DOWNSTREAM-CONSUMER-OF-DNS-PROPAGATION-TTL-DISCIPLINE companion at four per-M365-tenant per-accepted-domain DMARC-TXT-RR-propagation coupling dimensions: (i) per-M365-tenant per-accepted-domain DMARC TXT-RR publication at _dmarc.<m365-accepted-domain> per RFC 7489 §6.1 IS the load-bearing per-tenant per-accepted-domain composite-verdict-policy DNS-publication primitive whose per-receiver per-zone TTL-bounded propagation-cadence per RFC 1035 §4.1.3 + RFC 2308 §3 governs the per-receiver per-message DMARC-policy-discovery window THIS DNS-propagation guide documents the cache-and-refresh discipline of; (ii) per-M365-tenant per-accepted-domain DMARC publication-discipline events (initial ramp from p=none to p=quarantine to p=reject, alignment-mode tightening from relaxed to strict, RUA destination-address rotation) require coordinated per-tenant per-accepted-domain _dmarc.<accepted-domain> TXT-RR DNS-zone-publication propagation discipline so per-receiver per-message DMARC-policy resolution stays unambiguous across the rotation-window THIS DNS-propagation guide documents the TTL-aware change-window planning discipline of; (iii) per-M365-tenant per-accepted-domain DMARC TXT-RR rua=mailto: destination publication-discipline drives per-receiver per-day per-source-IP per-row aggregate-report-pipeline transmission whose per-receiver per-zone TTL-bounded propagation-cadence determines the per-tenant per-accepted-domain RUA-pipeline-discovery latency THIS DNS-propagation guide documents the per-zone-publisher per-RR-type propagation-floor of; (iv) per-M365-tenant per-accepted-domain DMARC TXT-RR DNS-publication-propagation-discipline drift (zone-publish race-window opens between _dmarc.<accepted-domain> upsert and per-receiver per-zone TTL-bounded cache-refresh boundary) directly opens per-tenant per-accepted-domain DMARC composite-verdict-policy stale-cache window THIS DNS-propagation guide documents the TTL-bounded-propagation-cache-coherence-floor of as the load-bearing per-zone-publisher per-RR-type publication-discipline baseline.
• DKIM-Signature header explained
• Business email compromise (BEC) playbook — the PER-PUBLISHER-PER-ZONE-DNS- PROPAGATION-CADENCE-AS-LOAD-BEARING-GATE- OF-BEC-DEFENSE-PUBLICATION-DISCIPLINE- CLOSURE companion to this DNS-propagation timing reference. Where THIS page documents the per-publisher per-zone DNS-propagation mechanics (per-RR TTL-bounded cache-fill cycle, per-resolver authoritative-vs- recursive resolution path, per-zone NS- delegation publication discipline, per-zone SOA-serial increment-discipline, per-RR negative-caching SOA-minimum-TTL bounding, per-publisher publish-and-verify propagation-window), the BEC playbook is the FINANCE-TREASURY-FRAUD-TEAM operational-workflow reference whose per- publisher per-domain DMARC + SPF + DKIM publication-discipline closure cadence DIRECTLY DEPENDS on the per-publisher per- zone DNS-propagation-cadence at FOUR per- publisher per-zone DNS-propagation-vs-BEC- defense coupling dimensions: (i) per-publisher per-domain DMARC _dmarc.<domain> TXT-RR p=none → p=quarantine → p=reject ramp-progression as DNS-propagation-gated BEC-defense closure cadence — the per-publisher per-domain DMARC policy-tag ramp is the single LOAD-BEARING publication-discipline decision closing the per-attacker per- target-domain BEC envelope-MAIL-FROM spoofing attack-class at the receiver-side disposition boundary per RFC 7489 §6.6.3; per-publisher per-domain _dmarc.<domain> TXT-RR propagation tail per RFC 1035 §4.1.3 + RFC 2308 §3 directly bounds the per- receiver per-day per-message DMARC-policy- discovery latency — per-attacker per- target-domain BEC spoofing during the propagation tail produces per-receiver per-message disposition-softening evidence the BEC IR investigation parses for per- message authentication-leg attribution; (ii) per-publisher per-domain SPF apex-zone TXT-RR ~all → -all hardening cutover as DNS-propagation- gated BEC-defense floor — per-publisher per-domain SPF -all hard-fail enforcement per RFC 7208 §4.6.4 is the per-publisher per-domain envelope-MAIL-FROM-layer BEC- defense publication-decision; per-publisher per-zone apex-TXT-RR propagation-window directly determines the per-receiver per- message SPF-policy-discovery-latency bounding the per-attacker per-target- domain BEC envelope-MAIL-FROM spoofing attack-window during the publication- cutover propagation tail; (iii) per-publisher per-selector DKIM <selector>._domainkey.<domain> TXT-RR publication-discipline as DNS- propagation-gated BEC-forensic-evidence- anchor — per-publisher per- selector DKIM-key publication-discipline TTL-bounded propagation cadence governs the per-receiver per-message DKIM-public- key-availability window the BEC investigator depends on for per-message DKIM-Signature d= + s= + b= forensic-evidence verification — per- publisher per-selector DKIM-key rotation events during a BEC IR investigation require per-zone DKIM TXT-RR DNS- publication-discipline coordination with the IR-evidence-collection window so per- message s= tag-value resolution stays unambiguous across the rotation tail; (iv) per-publisher per-domain CAA RR DNS-publication- discipline propagation cadence as DNS- propagation-gated BEC PKI-layer defense floor — per-publisher per- domain CAA RR publication per RFC 8659 §3 is the per-publisher per-domain PKI-layer per-CA-allowlist publication-discipline closing the per-attacker per-lookalike- domain BEC HTTPS-cert-mis-issuance attack- class — the CAA RR propagation tail directly bounds the per-CA enforcement boundary at per-attacker per-domain certificate-acquisition time. Read the BEC playbook WITH this DNS-propagation reference when AUTHORING per-publisher per-domain DMARC-p-equals-reject ramp + SPF-dash-all hardening rollout discipline whose propagation-cadence closure cadence directly determines the per-publisher per- domain BEC envelope-MAIL-FROM-spoofing attack-window closure timeline at the per-publisher per-zone DNS-publication- cadence-and-BEC-defense-rollout coordination boundary.
• ARC (Authenticated Received Chain) explained — the PER-PUBLISHER-PER-ZONE-DNS- PUBLICATION-AND-PROPAGATION-CADENCE-AS- LOAD-BEARING-PUBLISHING-INFRASTRUCTURE- DEPENDENCY-OF-PER-FORWARDER-PER-HOP-ARC- MESSAGE-SIGNATURE-PUBLIC-KEY-DNS-PUBLICATION- DISCIPLINE companion at four per-publisher per-zone DNS-propagation-vs-ARC-chain-of- custody coupling dimensions: (i) per- forwarder per-hop ARC-Message-Signature + ARC-Seal cryptographic-attestation publication per RFC 8617 §5 requires per- forwarder-domain <selector>._domainkey.<forwarder-domain> TXT-RR DNS publication discipline structurally parallel to per-publisher per-selector DKIM TXT-RR publication-discipline — the per- forwarder per-hop ARC-signing key publication consumes the SAME per-publisher per-zone DNS- publication-and-propagation-cadence discipline THIS page documents the per-publisher per- zone DNS-publication-cadence operational- discipline of; (ii) per-publisher per-zone DNS TTL-bounded publication-cadence operational- discipline THIS page documents IS the load- bearing per-publisher per-zone DNS-propagation infrastructure dependency the per-forwarder per-hop ARC-Message-Signature public-key DNS-publication discipline structurally depends on for per-receiver-side per-hop per-message ARC-chain cryptographic-attestation verification at the per-receiver per-mailbox- provider ARC-chain honour decision boundary (Gmail / Microsoft EOP per-forwarder ARC chain trust evaluation); (iii) per-publisher per-zone DNS-propagation-cadence drift (zone-publication-cadence drift past TTL cache-eviction window / recursive-resolver cache-coherence drift / authoritative-zone- commit-and-resolver-cache-eviction asymmetry) IS structurally parallel per-publisher per- zone DNS-publication-discipline drift class to per-forwarder per-hop ARC-Message- Signature public-key DNS-publication-discipline drift (per-forwarder per-hop ARC-signing-key rotation drift past per-forwarder TTL cache eviction window) that the ARC explained spoke documents the per-forwarder per-hop diagnostic ladder of; (iv) per-publisher per-zone DNS- publication-cadence operational-discipline + per-forwarder per-hop ARC-Message-Signature public-key DNS-publication-discipline JOINTLY underpin per-publisher per-domain composite per-receiver per-message ARC-chain-of-custody preservation floor across forwarder-survival boundaries. Read the ARC explained spoke when AUTHORING per-publisher per-zone DNS- publication-and-propagation-cadence coordinated with per-forwarder per-hop ARC chain-of-custody preservation discipline at the per-publisher per-zone composite DNS- publication-cadence-and-forwarder-survival publication-discipline coordination boundary.
• DMARC for Google Workspace — the Google-Workspace-tenant deployment guide. The SPF, DKIM (google._domainkey), and _dmarc TXT records a Workspace tenant publishes propagate per the TTL-bounded cache-fill rules on this page — verify each with dig after the propagation window before ramping the DMARC policy.
• DMARC forensic reports — the per-message failure samples that tell you whether a record you just published has actually propagated and is authenticating mail. During the TTL-bounded cache-fill window this page documents, stale resolvers can still serve the old SPF or DKIM record, so a ruf= failure report arriving for a legitimate message is an early warning that propagation is incomplete. Read the forensic-reports spoke to use per-failure samples as a propagation-health signal.
• Microsoft SNDS + JMRP monitoring — Microsoft grades the sending IP itself, not just the domain: SNDS per-IP GREEN/YELLOW/RED verdicts and JMRP complaints are the reputation companion to getting the DNS foundation right.

14. Verify your DNS propagation now

DMARC Analyzer's Domain Security Checker performs the multi-resolver lookup workflow documented in section 6 automatically (via includes/DnsChecker.php), reporting the live state of SPF, DKIM, DMARC, BIMI, MTA-STS, and TLS-RPT records from both the authoritative-perspective lookup and the public-resolver cache. Use it to confirm a newly-published record is visible across the internet, to compare the TTL declared by your DNS provider against the TTL actually observed in resolver caches, and to identify the wrong- label / wrong-zone / wrong-syntax errors that masquerade as propagation delays. The Email Header Analyzer parses Authentication-Results headers from received messages (via includes/EmailHeaderParser.php) so you can confirm what receivers are actually observing — useful when DNS appears correct but email is still failing for non-DNS reasons.

Verify my DNS records Sign up — Free plan