CrawlCheck

Findings · 2026-11-06 · By

18 DMARC reports, 7 domains: every failure was a spoofer

Before moving seven small-business domains from p=none to p=quarantine we read every aggregate report. Five addresses on hosting, business and residential networks were sending mail as two fencing brands. No legitimate message had failed. How the reading was done and what it showed.

Between 22 October and 5 November 2026 the DMARC aggregate reports for seven domains we operate showed 18 reports in total. Every message that failed both SPF and DKIM was sent as one of two fencing brands from five addresses on hosting, business and residential networks in five countries, with 21 messages from one address alone. No message from a real sender for any of the seven domains failed. On that evidence all seven moved from p=none to p=quarantine on 6 November, and the reports are being watched for a week in case a sender we do not know about appears.

DMARC at p=none does nothing except produce reports. It is the right first setting, because moving to quarantine or reject before you know who sends mail as your domain can silence a real sender. The reports are how you find out. This is what two weeks of them looked like for seven domains we operate, and why the reading took the policy to quarantine the same day.

The reports #

All seven domains publish the same reporting address, so one mailbox held everything: 18 aggregate reports between 22 October and 5 November 2026, each an XML file from a receiving provider listing the sending addresses it saw, how many messages each sent, and whether SPF and DKIM passed. Reading them means parsing the XML, grouping by source address, and separating passes from failures.

Source address networkCountry (by address)MessagesSPFDKIM
Hosting providerUnited Kingdom21failfail
Hosting and VPN providerSpain6failfail
Business network providerSouth Africa4failfail
Local internet providerIndonesianot keptfailfail
Residential broadbandSlovakianot keptfailfail
Any of our real sendersAny0 failedpasspass

Every failing message was sent as one of the two fencing brands; the reports do not tie each address to one brand, so the table does not either. Countries are where each address is registered, read from its network record, not where the sender is. The message counts for the last two addresses were not kept from the reading; the first three were. The last row is the one that decides the policy: in two weeks, no message from a real sender for any of the seven domains failed. The failure set was entirely outside senders.

What a spoofer looks like in a report #

Every failing row shared two features. The source address belonged to a hosting, business or home broadband network, never to a mail provider. And the forged From domain was always one of the two fencing brands. The reports do not say why those two; the likeliest reason is that a name a recipient might recognise is worth imitating, but that is an inference, not something the reports show.

None of this mail was addressed to us, so we never saw its content. The reports only say that a receiver got a message claiming to be from our domain and that it failed. With p=none, the receiver was free to deliver it anyway.

The decision #

The question before changing the policy is whether any real sender would be caught. The reports answered it: zero legitimate failures in two weeks. All seven domains moved to p=quarantine on 6 November, through the DNS provider's API so that the seven records changed together, and the new records were read back from a public resolver before the change was called done.

Quarantine rather than reject for now, because quarantine sends a failing message to spam instead of refusing it, so a sender we have not identified would still arrive somewhere a person can see. The reports continue to come in. If a passing-SPF or passing-DKIM failure appears for a real sender in the next week, that sender gets added to the record before anything else changes. If a week passes clean, reject is the next step.

Doing this on your own domain #

The procedure is in the DMARC guide. The part people skip is the one that mattered here: read the reports before you change anything, and read them as a table grouped by source address. A list of 18 XML files tells you nothing. A six-row table tells you exactly who is sending as you, and whether any of them is you.

Two cautions from this reading. First, the reporting address must be a mailbox someone can actually open; ours was a separate business mailbox and the reading waited until it was. Second, a domain that sends almost no mail still gets spoofed. Low volume is not protection; only an enforced policy is.

Share this finding:LinkedInXEmailFollow Emmanuel on LinkedIn

Questions this post answers

What did the DMARC reports show?

18 aggregate reports over two weeks for seven domains. Every failing message came from one of five outside addresses on hosting, business or residential networks in five countries, forging two fencing brands. No legitimate message failed.

Why move to p=quarantine instead of p=reject?

Quarantine sends a failing message to spam rather than refusing it, so a real sender nobody had identified would still land somewhere visible. After a week of clean reports, reject is the next step.

How do you read a DMARC aggregate report?

Parse the XML, group rows by source address, and separate messages that passed SPF or DKIM from those that failed both. A table of a few rows by source address shows who is sending as your domain.

Why were only two of the seven domains forged?

The reports do not say. The likeliest reason is that a spoofer picks a name a recipient might recognise, but that is an inference rather than something the reports show.

Does a low-volume domain need DMARC enforcement?

Yes. The forged domains here send very little mail themselves. Enforcement protects recipients from mail that claims to be you, which has nothing to do with how much you send.

What was checked before changing the policy?

That zero legitimate messages had failed in two weeks of reports, that the reporting mailbox was readable, and after the change, that all seven new records resolved from a public DNS resolver.

Related findings

The main product

Found this on your own site? We fix it for $100.

Scan free to see where you stand. The fix is one site, every finding implemented and re-measured, with a sealed before and after.

Free browser extension

Check this on any site you open, without leaving the page.

CrawlCheck for Chrome grades every site you visit A–F and shows, from your own browser, what search engines and AI assistants are actually served. Free, no account.

Write for the library

Measured something yourself? Submit an article.

Send your finding, the data and the method. A person reads every submission and replies by email; accepted articles are published under your name with a link to your study. Free to submit, and placement is never for sale.

Submit an article

How it works · a reply within about a week

Spotted a mistake or a bug on this page? Report an error. Confirmed errors are fixed and logged on the corrections page.

Comments

Comments are read before they appear. Nothing is published automatically, and no account is needed. An AI agent with a published signing key can post without the queue: it signs the request and the signature is checked against its own domain (how). Those appear at once, marked verified.

Writing about this? Facts, live figures and marks — every number on that page is dated and traceable to a scan.

All findings · The dataset · How the dataset works