For years I had no idea who was sending email as justplainsimple.com. Not a vague sense. No idea at all.

I knew the theory. SPF says which servers may send for you. DKIM signs your mail so it survives a forward. DMARC ties those to the domain in the From: header a human actually reads, and tells receivers what to do when neither lines up. I have explained this to other people. I had implemented none of it on my own domain.

So I fixed the records, pointed the reports at a mailbox, and waited a week.

Then I read them. The answer was 147 strangers.

DMARC reports are unreadable on purpose

Turn on DMARC with a rua address and mailbox providers start sending you aggregate reports. Google, Microsoft, Yahoo, AOL, Verizon. One per day per provider, as gzipped or zipped XML, attached to an email.

The format is machine-readable in the sense that a machine can read it. A human cannot. A week of reports for a domain that sends almost nothing was sixteen files and 196 records.

There are plenty of SaaS products that will ingest these for you. I did not want to forward a mailbox full of my own mail metadata to a third party to find out who was spoofing me. So I wrote a tool.

franking reads a directory of report files and tells you what is in them. Go, standard library only, no dependencies, no network calls unless you ask for a reverse DNS lookup. It reads the files you downloaded and prints what it found. A franking mark on a letter shows the postage is paid and the sender is who they claim to be, which is exactly what DMARC is for.

The number that lied to me

Here is what the first week looked like.

messages           410
DMARC pass         108 (26.3%)
source addresses   150

Twenty-six percent. My first reaction was that I had botched the setup.

I had not. Here is the same week, split by who was actually sending:

Every one of my own messages passed. Every single one. The 26% was not a measure of my configuration. It was a measure of how much mail someone else was sending while pretending to be me.

That distinction is the whole post. A low DMARC pass rate has two completely different causes that call for opposite actions:

• A sender of yours is misconfigured. Do not tighten the policy. You will start throwing away your own mail.
• Someone is forging you. Tighten the policy immediately. That is the entire point of DMARC.

A percentage cannot tell you which. I nearly read mine backwards.

How to tell the two apart

The signal is not in any single sender. It is in the shape of the failures, plus whether each failing sender owns up to who it is.

A real sender of yours that is broken looks like this:

• It usually attempted a DKIM signature. A stale key or a wrong selector, but it tried. Only something holding a key for your domain tries.
• It uses its own bounce domain. bounce.sendgrid.net, not yours. Real services identify themselves in the envelope.
• There are one or two of them, and they send a lot.

A forgery looks like this:

• No DKIM signature at all. They do not have your key and cannot get one.
• The envelope is forged as your domain, because that is the point.
• There are a great many of them, and each one sends almost nothing.

Mine was the second one, unambiguously. All 147 carried no signature and claimed my domain in the envelope. 115 of them sent two messages or fewer. The addresses were scattered across DigitalOcean, Vultr, Hetzner, EC2, GCP and Azure — rented boxes, a handful of messages each, spread thin to stay under volume-based reputation checks.

So franking does that classification for you and leads with it:

Diagnosis
  Your own mail is healthy. Someone is forging your domain.

  your sender  3 sources    108 messages  100.0% pass
  forged       147 sources  302 messages  0.0% pass

  the headline pass rate of 26.3% is set by that forged mail; over your own
  senders it is 100.0%

The second rate is the one to act on. An attacker controls the first one. He cannot touch the second.

The blind spot I would have missed

Here is the part I did not expect, and it is the most useful thing I learned.

My domain sends through two paths: Google Workspace, and Amazon SES for automated summaries. Across all sixteen reports there were exactly two authentication identities — one SPF domain and one DKIM selector, both Google’s.

SES did not appear at all. Not once.

That matters, because the gate I had written for myself was “move to enforcement once the reports are clean.” The reports were clean. 100% over my own senders. But they were clean partly because two of my three sending paths produced no data whatsoever.

A 100% pass rate over one sender is not evidence that the other two survive enforcement. If I had tightened on that week of data, my SES mail would have been the experiment.

So the gate was wrong. It is not “are the reports clean.” It is:

Has every sending path actually appeared in a report, and passed?

Absence of evidence is not evidence of alignment. Seven days is not long enough for a sender that fires monthly. This is the single easiest way to break your own mail while following the instructions correctly.

Fix the records in this order

The order is not stylistic. Publishing an enforcing policy before the other two are right will bounce your own mail.

1. SPF. One TXT record listing who may send. Start with ~all, not -all.
2. DKIM. Turn on signing at every provider. Two aligned identifiers beats one, because SPF breaks on forwarding and DKIM survives it.
3. DMARC at p=none. Monitoring only. Nothing changes for anyone. Collect reports.
4. Read the reports until every sender has appeared and passed. This is the slow part.
5. p=quarantine, then p=reject. Tighten SPF to -all at the same time.

I am at step four. That is not a failure of execution — it is what step four is.

What enforcement will and will not do

I assumed that moving to p=reject would make my 26% climb. It will not, and understanding why took me a minute.

DMARC reports describe mail that was attempted, not mail that was delivered. Receivers report every message they evaluated, including the ones they threw in the bin. The forger keeps sending. Google keeps reporting it. It keeps failing.

What changes is one field. Every record I have right now says:

<disposition>none</disposition>

That means: I detected this forgery and delivered it anyway. Because that is what p=none asks for.

After enforcement it says quarantine, then reject. The dkim and spf results do not move — they were already failing. The pass rate is computed from those. So it stays at 26% until the forger gives up.

Campaigns that stop landing lose their return and often move to a softer target. Often. Some run on autopilot for years against domains that have been at p=reject the entire time. Do not plan around it.

There is a further wrinkle for a small domain. My legitimate volume is about 108 messages a week. The headline rate is a ratio of my volume to an attacker’s, and both move independently. A quiet week for me and a busy week for him pushes that number down with nothing wrong on my end. It is a noisy metric and a bad thing to manage by.

This takes longer than you want

Publishing the records took an afternoon. Everything after that is waiting.

You need enough weeks of reports for every sender to show up at least once — including the quarterly one you forgot about. Then you need to authenticate or retire each one. In my case that means a handful of legacy sending identities in a second AWS region that still use a default envelope domain. Harmless under p=none. Rejected the moment I tighten.

Then p=quarantine for a while. Then p=reject. Then you watch to see whether the forgeries taper off, which is months at best and may be never.

Weeks to get honest data. Months to enforce safely. Possibly years before the forged traffic stops, if it ever does.

That is the real shape of this work, and nobody says it out loud because “turn on DMARC” fits in a tweet.

What I would tell you to do today

Publish p=none with a rua address. That is one DNS record, it changes nothing for anyone, and you will know within a week who is sending as you.

When the reports start arriving, download them and point franking at the directory. It will tell you whether your own mail is healthy and who else is using your name.

You will probably not like the answer. I did not. But not knowing was worse, and the reports had been available to me for free the entire time. I had just never asked for them.