The problem
Every mailbox provider will happily send you a daily report saying who has been sending mail using your domain, and whether it authenticated. They arrive as compressed XML attachments. Nobody, anywhere, reads them.
Which means a domain can be spoofed, or a legitimate mail stream can start failing authentication, and the first signal is a client saying “I never got your email”, weeks later, about an apartment that has since sold to someone else.
What I built
A mailbox receives the reports. A pipeline unzips them, parses the XML, resolves every sending IP to its owner, classifies each result, and writes it all to a database. It alerts only when a human should act.
- Every failing IP is enriched with its owner, network and country: free, no API key.
- Failures from a known forwarder are relabelled as forwarding, not spoofing.
- Unparseable reports go to a dead-letter table rather than killing the run.
- A weekly AI-written digest: pass rate per source, alignment, week-on-week trend, new IPs.
- A separate healthcheck every four hours: if no report has arrived in 24 hours, something is broken upstream.
Select a provider report below to see how raw DMARC XML is parsed, enriched with ASN data, and filtered to prevent false forwarding alarms while catching genuine spoofing.
How it works
An alert that fires on forwarding is an alert people learn to ignore.
Under the hood
A forward is not an attack
When someone auto-forwards your mail, the forwarding server relays it from its own IP. Authentication fails. The report calls it a failure. It looks exactly like spoofing.
So the pipeline learns which IP ranges belong to the legitimate sending infrastructure, and relabels failures from anywhere else as forwarding. If every failure in a batch is a forward, no alert fires at all.
TRADE-OFF Deliberately conservative: only one known sender is reclassified. A false “all clear” is far worse than a false alarm.
The alert that only looked at the first ten
The alerting logic evaluated a sample of failing IPs: the first ten, sliced for a readable email. A real spoofing source sitting at position eleven would never have triggered anything.
It was found by an adversarial audit, not by a test, and not by me.
batch.slice(0, 10). Rogue spoofing IPs at pos 11+ went completely undetected.
FIX Evaluate every failing IP for the alert decision; keep the slice for the email body only. Those are two different jobs and they had been conflated.
A dead-letter queue, not a dead workflow
One malformed report from one provider used to abort the entire run, losing every valid report in the same batch.
TRADE-OFF Bad reports now land in their own table and the run continues. Someone has to look at that table. Nobody does, until the count grows, which is roughly the correct amount of attention for the problem.
Naming the blind spot out loud
Monitoring covers the transactional domain. The marketing newsletters, the ones that actually sell apartments, leave from a second domain whose DNS sits outside my access, so extending the same coverage there was never mine to do.
HONEST The most sophisticated part of this system watches the wrong domain. Saying so in the handover was worth more than any feature I could have added.
Results
Reports flowing in from around a dozen mailbox providers, with authentication failures at effectively zero. An adversarial audit of the pipeline found one high-severity bug, the sampling blind spot above, which is now fixed.
Still open. The path to enforcement is mapped: confirm every legitimate sender aligns, then ramp the policy in stages. Extending coverage to the second domain comes first, and that needs DNS access I don't have.
Honest verdict: for a five-person agency, this is over-built. The remaining value is not more features. It is closing the blind spot and handing it over cleanly.
Stack
- n8n, self-hosted: 36 nodes, plus a separate healthcheck workflow
- IMAP: the reports arrive as compressed XML attachments
- NocoDB: records, and a dead-letter table for the unreadable ones
- Free IP-reputation API: owner, network, country, datacenter flag
- Gemini: the weekly digest and its TL;DR
What I took away
The bug that matters is the one that fails silently. This whole system exists because of a class of failure that produces no error, no bounce, no complaint. Just an email that never arrives.
And the most valuable thing I wrote about it was not code. It was the sentence admitting which domain it doesn't watch.