SPF, DKIM, DMARC — aligned
and reject-ready.

The DMARC aggregate report is the most important diagnostic tool that exists for understanding email authentication. Mailbox providers send these reports daily to whatever address you specify in the rua= tag of your DMARC record — they contain, for the previous 24 hours, every IP address that sent mail claiming to be from your domain, the SPF and DKIM result for each, the DMARC alignment outcome, and the count of messages. Two weeks of these reports gives a complete picture of your domain's mail behaviour.

Without DMARC aggregate reporting, an audit is guesswork. You can check what authentication records exist; you cannot check what is actually using them. The marketing tool that switched providers eight months ago and forgot to update its DKIM selector is invisible. The shadow IT team running a side project from a cloud function with no SPF authorisation is invisible. The phishing campaign currently impersonating your domain from a Russian botnet is invisible. All three become visible immediately once you start collecting rua= data — and all three need to be addressed before p=reject can be safely deployed.

; _dmarc.yourcompany.com TXT record
; p=none means we do nothing yet — we just collect data.
; rua= sends aggregate reports to our endpoint for analysis.

v=DMARC1; p=none;
  rua=mailto:[email protected];
  ruf=mailto:[email protected];
  fo=1;
  adkim=r;
  aspf=r;
  pct=100

; Translation:
;   p=none      — observe only, do not affect mail flow
;   rua=        — daily aggregate reports to us
;   ruf=        — failure-event reports (forensic, sampled)
;   fo=1        — generate forensic for any auth failure
;   adkim=r     — relaxed DKIM alignment (subdomain match OK)
;   aspf=r      — relaxed SPF alignment (subdomain match OK)
;   pct=100     — apply to 100% of mail

After two weeks of collection, the data tells us everything we need. The audit report identifies every IP address, every sending source, every authentication outcome. Legitimate sources get fixed (DKIM signing added where missing, SPF includes adjusted, alignment pattern corrected). Illegitimate sources get documented and you get to decide what to do about them — sometimes it is a forgotten internal application that gets deprecated, sometimes it is a partner who shouldn't have been sending in the first place, sometimes it is an active phishing campaign that gets reported to the relevant authorities.

Only after every legitimate source is producing aligned authentication do we begin advancing the DMARC policy. The progression is conservative on purpose — moving too fast breaks legitimate mail, which is worse than moving too slowly.

Week 1-2:   p=none; pct=100      # observe, identify all sources
Week 3-4:   p=none; pct=100      # fix discovered issues, re-observe

# Begin enforcement — staged percentage
Week 5:     p=quarantine; pct=10   # 10% of failing mail to spam
Week 6:     p=quarantine; pct=25
Week 7:     p=quarantine; pct=50
Week 8:     p=quarantine; pct=100
Week 9:     p=reject; pct=10       # begin reject
Week 10:    p=reject; pct=50
Week 11:    p=reject; pct=100      # full enforcement

# If anything wobbles at any stage we hold the percentage
# until the underlying issue is fixed.

The five categories below cover the bulk of what we find. They do not cover everything. Across 217 audits we tracked between January 2023 and December 2025, the frequency distribution of findings settled into a stable shape — roughly the same percentages from one quarter to the next, regardless of client sector or domain size. The chart below is what 200+ domains tell you about the state of email authentication in production. The interpretation is uncomfortable: most domains have at least four findings, and the average domain has 6.3.

The 10-lookup SPF cliff. SPF has a hard limit of 10 DNS lookups, recursive includes counted. An SPF record that lists Google Workspace plus Microsoft 365 plus SendGrid plus Mailchimp plus a CRM platform almost always exceeds this — each include: directive can chain into multiple sub-lookups. Once over the limit, SPF returns permerror, which the receiving mailbox treats as a hard SPF failure regardless of whether the actual sender is authorised. Most senders never notice because the failure is silent — until DMARC starts enforcing, and then half their mail starts failing alignment overnight. The fix is SPF flattening (replacing include: with the actual IP ranges it expands to) combined with removing legacy authorisations for vendors no longer in use.

The forgotten subdomain. Mail gets sent from marketing.yourcompany.com, app.yourcompany.com, noreply.yourcompany.com, and the parent domain yourcompany.com — all four with separate authentication setups, three of which were configured by different teams at different times. The DMARC policy is published at the parent domain only. Three of the four subdomains have no DKIM signing, no SPF authorisation, and no aligned From address. The audit catches it; the fix is publishing per-subdomain authentication records or, more often, consolidating sending onto fewer subdomains so the surface to authenticate is smaller.

The CDN that mangles TXT records. Some CDN-fronted DNS providers split long TXT records at byte boundaries that break SPF and DMARC parsing — the record looks correct in the dashboard but resolves as malformed at the wire level. Cloudflare and Fastly along with a couple of others have specific quirks here that have caught us multiple times. The diagnostic is reading the raw DNS response with dig or equivalent rather than trusting the provider's UI. The fix is either escaping the splits correctly or moving authentication-critical TXT records to a DNS provider that does not transform them.

The marketing tool that signs DKIM with the wrong selector. A platform was configured years ago with selector k1 that DKIM-signs against a key the sender no longer controls. The platform later added a new selector k2026 with a key the sender does control, but the platform's outbound traffic still uses k1 for messages submitted via legacy API endpoints. SPF is fine, DKIM signature is technically valid, but the From-domain alignment fails because the k1 selector is hosted on the platform's domain rather than the customer's. Caught only by reading the DKIM d= field in the DMARC report. Fixed either by migrating the platform's traffic to the new selector or by accepting that this source needs SPF alignment as the path to DMARC pass.

The phishing campaign that has been running for six months. Roughly 1 audit in 8 reveals an active impersonation campaign — somebody sending mail from your domain to your customers, usually for credential phishing or invoice fraud. The DMARC report shows it immediately: a chunk of failing-alignment volume from IP ranges that have nothing to do with your legitimate sending sources, often with email patterns that mimic your invoice or password-reset templates. The fix is twofold — get to p=reject as fast as is safe, which kills the campaign at the receiving end, and report the campaign to the hosting provider of the originating IPs (and to your local cybercrime authority if there is monetary loss involved). Several of these have led to legal action.

The audit produces a document. The document is not the deliverable. The deliverable is what happens to the placement numbers in the 90 days after the changes ship. Below: actual placement-rate trajectories for three audits we ran in 2025, plotted from week zero (audit complete, changes deployed) through week twelve. Names anonymised, sectors preserved. The shape of the curve is the answer to "does fixing this stuff actually do anything." It does, but the timing is not what most clients expect.

Three trajectories. Client D is a B2B SaaS company that started at 71 percent inbox placement at Gmail and crossed 95 percent at week eight. The curve is gradual because reputation rebuilds slowly — there is no overnight fix once the placement degraded. Client E is an e-commerce retailer who started at 88 percent and reached 98 percent by week six. They were closer to clean to begin with, so the recovery was faster. Client F is the interesting one. Started at 64 percent, hit 92 percent at week four, then dropped to 81 percent at week six because a separate marketing campaign violated the new DMARC policy and produced a temporary reputation hit. Recovered fully by week eleven. None of these trajectories is straight. All of them are upward.

Two things buyers should take from these curves. First, the audit pays for itself in roughly six to ten weeks measured against incremental delivered volume — that is the recovery period for placement to stabilise above 90 percent at the major receivers. Faster than most senders expect, slower than vendor marketing implies. Second, recovery is not always monotonic. Client F's mid-recovery dip is normal, not a signal that the audit was wrong. Reputation systems at the major providers are noisy by design, and a clean audit produces a clean trajectory only if downstream operations stay clean too. The audit fixes the configuration. It does not fix the team that produced the configuration. That part is on you.

Twelve checks, in fixed order, applied to every audit. The order matters because findings cascade — fixing the SPF lookup count before reading the DMARC reports avoids chasing alignment failures that disappear once the lookup count drops below ten. We have not changed the checklist meaningfully since 2023. The patterns are stable, the diagnostic questions are stable, and the fixes are stable. What changes is the percentage of clients triggering each check, which we track quarterly.

The playbook is open because the audit is not the trade secret. The trade secret is the experience to know which finding deserves attention first when three of them surface at once, what the second-order effects look like when you fix one without addressing the related three, and how to talk to a procurement team about results that cannot be guaranteed in writing because reputation systems do not work that way. Anyone can run the 12 checks. The value of the engagement is what happens after the findings are listed — sequencing the fixes, reading the post-deployment aggregate reports, knowing when the placement curve is healthy and when it is not. Tools tell you what is wrong. Operators tell you what to do about it.