Diagnosing a Stalled Rollout

Most stalled DMARC rollouts trace back to one of a small number of repeat patterns. Recognizing them by shape saves real diagnostic time.

Pattern 1: an unaudited legitimate sender

A vendor nobody remembered to include in the SPF/DKIM setup keeps failing, indefinitely, because nothing about the failure looks urgent until enforcement tightens around it. This is exactly why Module 2's "audit every sender first" isn't optional process – it's the single most common root cause of a rollout that stalls.

Pattern 2: subdomain policy inheritance confusion

DMARC's sp= tag sets the policy specifically for subdomains – if it's absent, subdomains inherit the same policy as p=. A team that assumes subdomains are unaffected by the main domain's DMARC record (a common, wrong assumption) can be blindsided when a subdomain-hosted service suddenly starts failing under a policy nobody explicitly set for it.

Pattern 3: DNS propagation mistaken for a fix that didn't work

A DNS record change doesn't take effect instantly everywhere – resolvers and receiving mail providers cache records for their TTL. A record change that looks "not working yet" an hour later is frequently just propagation delay, not a real configuration error. Checking again after the TTL has actually elapsed, instead of re-editing a record that was already correct, avoids a surprisingly common wasted diagnostic loop.

Pattern 4: forwarding breaks SPF, but DKIM should still align

Covered in Module 2: a forwarded message loses SPF alignment at the relay hop. The fix isn't to abandon enforcement for anything that gets forwarded – it's to confirm the DKIM signature (not SPF) survives the forward and still aligns, since DMARC only needs one of the two.

The debugging order that actually works

Read the aggregate reports first. Every pattern above shows up there as a real, specific failing source – guessing at what's broken before reading what the reports already say is the slow way to diagnose a stall.