I Wrote DMARC Guides for Years. Then My Own Monitoring Caught Me With My Pants Down.

I write DMARC guides for a living. Today my own DMARC monitoring caught me with my pants down.

I found out the hard way that my domain had been sending email through an unauthorized server for two months. Nobody told me. My own monitoring did not catch it either -- not until I happened to review an aggregate report that I almost skipped.

This is not a hypothetical warning. This is what actually happened to someone who spends their working life thinking about email authentication.

The gap was a legacy test server that had been decommissioned in my mind but was still running in the wild, still sending email with my domain in the From header, still passing SPF because the IP was technically authorized somewhere, and still failing DMARC alignment because nobody had updated the sending infrastructure in years.

The DMARC failure was there in the reports the whole time. I had not been looking carefully enough.

Why Expert Monitoring Still Has Gaps

If you are reading this and thinking "that would not happen to me," consider what your monitoring actually covers. Most teams monitor their primary sending domain and call it done. Here are the gaps that slip through.

Subdomains you forgot existed. Every subdomain that can send email is a potential gap. Test environments, legacy applications, old marketing platforms -- these often live outside IT visibility. They send email with your domain attached. Your apex domain policy says nothing about what these subdomains are doing.

Third-party senders using your domain. Your marketing platform, your CRM, your transaction email provider -- they send on your behalf. Do you know exactly which ones? Do you know if they are using your domain correctly? Most teams have a list that is six months out of date.

Legacy server IPs that were supposed to be decommissioned. The server you migrated away from in 2021 is still running somewhere. It is still sending. Your SPF record still includes its IP because nobody removed it. Your DMARC policy is p=reject but that server is quietly failing alignment every time it sends, and nobody notices because nobody reads those reports.

Internal mail systems with different authentication rules. Your internal Exchange or Zimbra server authenticates differently than your external mail flow. Internal-to-internal email never hits DMARC because it never leaves your domain. But internal-to-external email does, and if that server is misconfigured, it shows up as a DMARC failure from your own domain.

Shared hosting accounts still sending on behalf of the main domain. If your domain has ever been hosted on a shared platform, there may be sending activity attached to your domain that your IT team does not control and may not even know about.

How to Check Your Own DMARC Monitoring for These Gaps

1. Review aggregate reports for every subdomain -- not just the apex. Look at which subdomains appear in the failure data.
2. Look for DKIM selectors you did not provision. If you see DKIM signatures with selectors you do not recognize, something is sending using keys you did not create.
3. Cross-reference your SPF includes against your actual sending infrastructure. Every include in your SPF record is a service or server sending on your behalf. If you do not recognize one, find out why.
4. Check for forwarding chains that generate alignment failures. When email is forwarded, the original SPF check fails because the forwarder's IP is not in your SPF record, and header modifications during forwarding often break DKIM signature validation. This is normal forwarding behavior, but a sudden spike in forwarding failures can indicate a configuration problem.
5. Verify that your monitoring covers all sending domains -- not just the primary one. If you own 10 domains and only monitor 2, the other 8 are invisible.
6. Set up alerts for new subdomains appearing in your DMARC reports. A new subdomain in your failure data is a signal worth investigating immediately.
7. Review your own DMARC record for p=none periods that hide problems. If your policy is set to none while you were "testing," those test periods may have covered up real configuration problems.

What DMARC Aggregate Reports Reveal That SPF and DKIM Alone Cannot

SPF tells you whether a sending IP is authorized. DKIM tells you whether a message was signed with a valid key. DMARC tells you whether the domain in the From header aligns with the domains used for SPF and DKIM.

This distinction matters.

A message can pass SPF and pass DKIM and still fail DMARC. That happens when the From header domain does not match the SPF or DKIM domain. Forwarded mail is the most common real-world cause: the forwarder's IP is not in your SPF record, so SPF fails for the forwarded message, and if headers were modified during the forward, DKIM validation also fails.

DMARC aggregate reports give you the domain-level view. They show you which sources are sending on your behalf, which are failing, and which are succeeding. That view is not available from individual message headers or from SPF or DKIM checks alone.

Without that view, you are managing email authentication blind.

The Bottom Line

Three things to do today.

First, pull your aggregate reports for all your domains -- not just the one you care most about. Set aside 20 minutes and actually read them. Look for anything that surprises you.

Second, audit your SPF includes. If you cannot account for every include, find out what is using it and whether it should still be there.

Third, set up automated monitoring so that you do not have to remember to check. DMARC reports that nobody reads are not monitoring -- they are just data sitting in a folder.

If you want a tool that monitors all your domains, alerts you when something new appears in your traffic, and gives you a daily digest so you do not have to remember to look -- DMARCFlow is built for exactly this. The problem this article describes -- domains slipping through monitoring, new senders appearing without anyone noticing -- is what DMARCFlow is designed to catch before it becomes a problem.

The self-catch is humbling. But it is also useful. The gap my monitoring caught was a legacy server that should have been removed years ago. Knowing it existed meant I could fix it. Without the aggregate report, I would never have known.