Detecting spoofing in DMARC reports: the method

<record>
  <row>
    <source_ip>203.0.113.47</source_ip>
    <count>612</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.com</header_from>
  </identifiers>
</record>

The signatures of a spoofing campaign

Beyond the isolated line, real campaigns draw recurring patterns in the reports.

The short burst. A phishing campaign is prepared, fired, then extinguished: volume goes from nothing to hundreds or thousands of messages within 24 to 72 hours, then drops back to zero. Legitimate flows persist. A source that appeared on Monday and vanished by Thursday will not come back to explain itself.

Residential IPs and botnets. Rather than one big sending address, dozens or hundreds of IPs each sending a handful of messages, often on consumer ISP ranges, geographically dispersed. That fragmentation is a signature in itself: no legitimate sending infrastructure looks like a swarm.

Recipients concentrated at a single provider. RUA reports come from the recipients' mailbox providers. When a campaign shows up in the reports of a single reporter — only Google, for instance — it reflects a purchased or stolen address list concentrated at that provider. Legitimate traffic, by contrast, spreads across all the usual reporters.

Improbable targets. Messages sent in the name of subdomains that do not exist — a billing.example.com that was never created — betray an attacker probing the perimeter. DMARCbis introduced the np= tag precisely to harden the fate of non-existent subdomains without touching the rest of the policy.

The false positives that look like an attack

Three perfectly legitimate mechanisms produce DMARC failures, and mistaking them for spoofing wastes time — or triggers a false alarm.

Forwarding. A recipient who forwards mail to another mailbox re-emits the message from a new IP: SPF fails mechanically. But if the message was not modified in transit, DKIM survives the hop. An aligned spf=fail, dkim=pass line is therefore not spoofing: it is the classic signature of a forward.

Mailing lists. They modify the message — a tag in the subject, a footer appended — and break DKIM on top of SPF. The result is a double failure that looks deceptively like an attack. The saving clues: low and stable volume, a constant IP belonging to an identifiable list operator, recurrence week after week — the exact opposite of a burst. Some receivers compensate through ARC and deliver anyway; the report's reason field then keeps a record of that override.

Security gateways and scanners. At some receiving organizations, analysis appliances detonate attachments and re-inject the message internally: it re-emerges from a gateway IP, SPF fails, and sometimes DKIM too if the content was reprocessed. These sources reveal themselves through their regularity and a volume proportional to the mail genuinely sent toward that organization.

Settling the ambiguous cases. For the residue, the next level of detail would be the forensic report, sent message by message — but the major providers barely emit them anymore; the difference between aggregate and forensic reports explains why detection rests, in practice, on RUA alone.

The weekly triage method

Detection does not require a war room; it requires a routine. Thirty minutes a week is enough for an established domain, in five passes that never change.

1. Alignment rate first. The share of aligned volume over total volume, compared with the previous week. Stable or rising: nothing urgent. Falling: something changed, and the rest of the triage will say what.
2. New sources next. Every IP that appeared since the last reading gets classified into one of the three populations. A known vendor, a corporate range, a total unknown: three different fates.
3. Double failures in detail. For each fail/fail line: volume, temporal profile, network origin, list of reporters. Burst plus scattered IPs plus a single reporter: the evidence of a campaign is assembled.
4. Labeling. Every source receives a status — legitimate, to fix, hostile, undetermined — carried over from week to week. That memory is what makes the routine fast: only what is new demands analysis; the rest has already been judged.
5. The decision. A source marked "to fix" enters the configuration backlog; a hostile campaign observed under p=none becomes a dated, quantified argument for accelerating enforcement.

Done by hand on compressed XML files, this routine turns painful by the second week. Report-reading tools automate most of it — IP enrichment, persistent labeling, new-source alerts — and reduce the weekly appointment to reviewing the anomalies alone.

What the policy changes about the reading

The same report line does not tell the same story under every published policy.

Under p=none, the disposition stays none: every spoofed message counted in the report was delivered, barring the receiver's ordinary spam filtering. The reading is observation in the strict sense: hostile lines describe phishing that reached inboxes. This is the most uncomfortable period — the one where the reports document the exposure without reducing it — and every detected campaign is a dated reason to move out of it.

Under p=quarantine and then p=reject, the same lines change nature: disposition=quarantine or reject means the messages were set aside or refused. Failures become blocks; the report becomes a scoreboard. The rejected hostile volume reads as a protection metric: each burst is an aborted campaign, with no victims on the receiving side. One nuance: a disposition=none line can persist under p=reject when the receiver overrode the policy locally — a mailing list rehabilitated through ARC, an internal rule — and the reason field documents that choice.

A version note: progressive rollout no longer goes through the old pct tag, which is gone from DMARCbis; test mode is now expressed with the t= tag, and organizational-domain determination relies on the DNS Tree Walk. Existing v=DMARC1 records remain valid as they are.

When to escalate into incident response

The weekly routine is enough as long as spoofing remains background noise — a few opportunistic attempts per month are part of the normal life of any visible domain. Three thresholds justify leaving the routine.

Volume. A campaign that exceeds the domain's legitimate traffic, or that holds for several days instead of fading, is no longer noise: it is an investment by the attacker, and therefore targeting.

Targeting. Reports concentrated at the provider that happens to host the organization's own customers or partners, or a correlation with inbound signals — replies from victims, support calls, internal alerts — indicate that the campaign is hitting the real ecosystem, not random addresses.

Context. A burst synchronized with an organizational event — a billing run, a recruitment drive, a public announcement — betrays preparation, and preparation announces a sequel.

In those three cases, reading is no longer enough: the hardening timeline has to accelerate, the reports have to be preserved as evidence, and the exposed stakeholders have to be informed. The complete playbook — qualification, communication, emergency enforcement — is the subject of incident response after a spoofing campaign. And the best time to ask the question remains before the campaign: testing whether a domain can be spoofed says in minutes what the reports would end up proving over several weeks.

In summary

A RUA report makes spoofing visible, provided the sorting is done. Legitimate aligned sources get monitored; legitimate misconfigured ones get fixed; spoofers — unknown IPs in double SPF and DKIM failure, with no signature from the domain at all — are neutralized only by policy. A real campaign gives itself away by its short burst, its scattered or residential IPs and its reports concentrated at a single provider; forwards, mailing lists and security gateways produce comparable failures without being attacks. The weekly routine — alignment, new sources, double failures, labeling, decision — turns that reading into a reflex, and the published policy decides what the lines mean: observation under p=none, blocking under p=reject. Past a certain volume, a confirmed targeting or a suspicious synchronization, detection gives way to incident response.

The first triage can start today: running the domain through the free DMARC analysis shows immediately who sends under its name and on what authentication grounds. To install the routine for the long run — report collection, source enrichment, burst alerts — creating an account puts the method described here on continuous autopilot, until the day every hostile line reads as a block rather than a threat.