I Read 6 Months of My Own DMARC Reports. Here’s What They Were Actually Telling Me.

Every day, my inbox fills up with attachments named like google.com!iamgeek.com!1778025600!1778111999.zip. These are DMARC aggregate reports — the email-authentication world’s version of a daily attendance roster. Mailbox providers like Google, Microsoft, Yahoo, Comcast, and Fastmail send them to tell you who’s been sending email “as your domain” and whether those messages passed the cryptographic checks that prove they really came from you.

Most people delete them. I did too, for a long time. They’re XML, they’re cryptic, and they pile up. But last week I finally cracked one open, then a second, then a hundred, and what I found was a small detective story sitting on my own domain.

If you own a domain — for your business, your law firm, your medical practice, your nonprofit — there’s a high probability that the same report is sitting in your inbox right now. And it might be telling you something useful.

What DMARC actually is, in 90 seconds

DMARC stands for Domain-based Message Authentication, Reporting & Conformance. It’s the policy layer that sits on top of two older mechanisms — SPF and DKIM — and tells receiving mail servers what to do when something looks fishy.

A useful analogy: think of your domain (the part after the @ in your email) as a building, and email as a stack of letters being mailed out of the lobby.

• SPF (Sender Policy Framework) is the list at the front desk that says which mail rooms are authorized to drop mail in the lobby. If a letter shows up from somewhere not on the list, the front desk frowns.
• DKIM (DomainKeys Identified Mail) is a tamper-proof wax seal pressed into every legitimate letter. The receiving post office can verify the seal was made by the right private key. If the seal is broken or fake, that’s a bad sign.
• DMARC is the standing instruction you give to every recipient post office: “If a letter from my building has neither a valid front-desk authorization nor a valid wax seal, here’s what to do with it — pass it through, drop it in the spam pile, or refuse delivery entirely.”

The “reporting” part of DMARC is the daily attendance roster: every receiving mail server can send you a summary of every message it saw claiming to be from your domain — whether it passed, where it came from, and how it was handled. That’s what’s been piling up in my inbox.

Why I finally cracked them open

I started getting curious because I was about to recommend tighter email security to a client and realized I should make sure my own house was in order first. So I pulled six months of DMARC aggregate reports from my own inbox — Google, Microsoft, Yahoo, Comcast, Fastmail, Mimecast, Rackspace, and a few others. I parsed the XML, rolled it up by sending IP, and asked the four questions any domain owner should be able to answer:

1. Who is sending mail “as me”?
2. How much of it passes authentication?
3. Where are the failures coming from?
4. Is anyone trying to spoof me?

The picture for iamgeek.com

Across six months and 215 messages in my sample:

• 99.07% passed authentication. Two messages out of 215 failed.
• Three categories of legitimate senders: my normal Google Workspace email, a high-volume sender on AWS infrastructure (more on this in a minute), and a handful of recipient-side forwarders.
• No sustained spoofing attempts. Nobody is pretending to be me — at least, not at the scale that would show up in DMARC reports.

That’s a healthy domain. But the analysis turned up two things I didn’t know.

Discovery #1: My website was sending more email than I realized

The biggest sender wasn’t my work email. It was a cluster of IP addresses in two narrow AWS ranges (35.89.44.32–39 and 44.202.169.32–39). All of them were signing messages with my domain’s DKIM key, and all of them had iamgeek.com in the header — meaning the recipient saw them as coming from me.

A little detective work tied those IPs back to HostGator, the host my WordPress blog runs on. HostGator is owned by EIG, and EIG’s outbound mail relays live on AWS. Every time my site sent a contact-form notification, a comment alert, or any system-generated email, it went out through one of those AWS IPs.

This was fine — the DKIM signatures were valid, so DMARC passed. But the volume had been steadily climbing since February of this year, which lined up with some site updates I’d made. I just hadn’t noticed.

Discovery #2: My SPF record was incomplete

Here’s where it got interesting. SPF is supposed to authorize sending IPs. My SPF record looked like this:

v=spf1 include:_spf.google.com ~all

That authorizes Google Workspace and nothing else. The HostGator IPs weren’t authorized, which meant every site-generated email was getting an SPF “softfail.”

DMARC was passing anyway — because DKIM was aligned — but only by the skin of its teeth. If my DKIM key ever rotated incorrectly, or if a forwarder stripped the signature, those messages would silently start failing.

The fix was a one-line DNS change:

v=spf1 include:_spf.google.com include:eigbox.net ~all

EIG publishes their authorized senders as eigbox.net, which chains to eig.spf.a.cloudfilter.net, which explicitly lists ip4:35.89.44.32/29 and ip4:44.202.169.32/29 — the exact ranges I was seeing. Adding the include brought my site’s senders fully under the SPF umbrella. Belt and suspenders, no surprises.

The two “failures” — and why they weren’t what they looked like

The two messages that failed DMARC across the entire 6-month sample came from Microsoft IPv6 addresses and tripped both SPF and DKIM. On paper that looks like spoofing. In practice, it was something more mundane.

Both failed records had an SPF “MAIL FROM” pointing to a different domain — one belonging to a fitness club I’d corresponded with. What had happened: I sent legitimate email to that recipient, their Microsoft 365 account auto-forwarded the message to a different mailbox, and the act of forwarding modified the message just enough to invalidate the DKIM signature.

This is the forwarding problem in DMARC, and it’s well-known. Forwarders that don’t preserve the original signature break authentication for everybody downstream. The mail itself was legitimate — it just got mangled in transit by an over-eager forwarding rule.

Real spoofing attempts look different. They show up in volume, from networks that have no relationship to your business, with envelope-from headers that don’t make sense. None of that was in my reports.

A confession about how I actually pulled this off

I didn’t sit at a terminal for three days reading XML. I did this entire analysis in a single afternoon using Cowork, Anthropic’s desktop AI tool — a research preview that pairs Claude (their AI assistant) with the ability to drive my actual computer: read my files, search my email, run shell scripts, and operate my browser.

In one chat session, Claude:

• Searched my Gmail for six months of DMARC reports and built an inventory by provider and month
• Drove Chrome through Gmail to download a representative sample of XML attachments into a folder I’d shared with it
• Decompressed and parsed every report, then aggregated them by source IP and pass/fail rate
• Pulled my live DNS records, traced my SPF chain through HostGator’s eigbox.net and out to the underlying AWS ranges, and verified the fix
• Wrote a Python script that rolled up the results and explained what each cluster of IPs was actually doing

Two months ago I would have done this analysis manually — dig, gunzip, a spreadsheet, scribbled notes, half a day minimum. Now it’s a conversation, and a much more thorough one because I’m not the bottleneck on the tedious parts.

The expertise is still mine. The judgment about what matters, what to recommend, what’s a real threat versus a forwarding artifact — that all has to come from someone who knows networks and email. But the grunt work — the part that used to make this kind of audit expensive — is gone.

If you’ve been watching the AI hype cycle and wondering whether any of it actually helps a small business yet, this is what useful looks like. It’s not magic, it doesn’t replace the engineer, but it eats the boring parts of the job for breakfast. I’ve started using it on client work too, which means audits and analyses that used to take half a day land in a fraction of that time without losing rigor — and without raising my rates.

What this means for your business

If you own a domain and use email professionally — and that’s pretty much every small or medium business at this point — you should be able to answer four questions:

1. Do you have DMARC, SPF, and DKIM records published? If you don’t know, you probably don’t.
2. What’s your DMARC policy? none, quarantine, or reject? Most domains start at none and never move. That means spoofers can pretend to be you and recipients have no instruction to stop them.
3. Who’s actually sending mail as your domain? This isn’t theoretical. Your website probably sends mail. Your CRM probably sends mail. Your ticketing system probably sends mail. If they’re not in your SPF and DKIM, your legitimate mail is silently softfailing.
4. Where are your DMARC reports going? Mine come to me directly. Most people’s go nowhere — they have a rua tag pointing to an unmonitored address, or no rua at all.

For my own domain, I’m now sitting at p=quarantine with a clean baseline, and I’ll be moving to p=reject once I’ve watched a few weeks of reports under the new SPF. That last step — moving from quarantine to reject — is the one most domains never take, and it’s the one that actually stops spoofers cold.

How I’d help you with this

This is the kind of work I do for clients alongside the network installations and the day-to-day computer support. If you’re running a law firm, a medical practice, a real-estate office, or a small business and you’ve never audited your domain authentication, the odds are good there’s something worth fixing.

A typical engagement looks like:

• Audit your current DMARC, SPF, and DKIM records
• Pull a month of your DMARC aggregate reports and roll them up the same way I did mine
• Identify legitimate senders that aren’t authorized (very common — your CRM, your billing system, your website)
• Tighten your records and walk you up the policy ladder from none → quarantine → reject
• Set up a parser like dmarcian or Postmark so you don’t have to read XML for the rest of your life

If that sounds useful, I’m at brian@iamgeek.com or 615-335-5737. The DMARC reports are already flowing into your inbox; somebody might as well read them.

---

Brian Coulam is the network engineer behind I am Geek, serving small and medium businesses and high-end residential clients across Middle Tennessee. He specializes in Ubiquiti UniFi network installations, computer security, and turning XML attachments nobody reads into actionable security posture.