The DMARC Mistake Even Experts Make: What the LearnDMARC Incident Teaches Every Organization

The person who teaches DMARC for a living recently found out their own setup was broken.

They posted about it on Reddit. 64 upvotes and 13 comments later, the thread had become a quiet confessional for everyone who assumed their email authentication was solid. People thanked the author for normalizing the struggle. Others shared their own near-misses.

The incident is worth studying carefully. Not because schadenfreude is instructive, but because the specific failure pattern is one of the most common in all of email authentication.

Here is what the LearnDMARC incident teaches about why even experts get DMARC wrong, and what your organization should check today.

What the incident revealed

The author runs LearnDMARC, a DMARC training and monitoring resource. By any reasonable standard, this is someone who understands email authentication better than most. Yet their own monitoring caught them with a configuration mistake.

The exact details of the mistake are less important than the pattern: an expert, using monitoring tools, still got caught.

This means two things at once.

First, DMARC expertise does not prevent configuration mistakes. Knowing how alignment works and actually keeping alignment working across every sending subdomain, third-party relay, and forwarding path are very different things.

Second, monitoring is not optional. The only reason this mistake was found is that someone was watching the aggregate reports. Without monitoring, the mistake would have persisted indefinitely, invisible until it caused a real email failure.

How DMARC alignment works

To understand why these mistakes happen, you need to understand alignment.

DMARC has two authentication mechanisms: SPF and DKIM. For DMARC to pass, at least one of those mechanisms must authenticate the sending domain, and the aligned domain must match the header-from domain.

Alignment has two modes.

Relaxed alignment accepts a match when the organizational domain is the same, even if the exact subdomain differs. This is the default.

Strict alignment requires the domains to match exactly. Very few organizations use strict alignment because it breaks easily when third parties are involved.

Most organizations use relaxed alignment. This is sensible, but it creates a gap: a message can pass SPF or DKIM for a related domain and still pass DMARC even if it is not legitimately from the sender you think it is.

The LearnDMARC incident almost certainly involved an alignment failure. The author's setup had SPF passing, or DKIM signing, for a domain that did not correctly align with the header-from address. The result was a DMARC failure that their monitoring caught but that would have been invisible without it.

The most common DMARC mistakes organizations make

Drawing from the LearnDMARC thread and years of aggregate report patterns, here is what shows up most often.

1. Subdomain policy gaps

An organization publishes a DMARC record for company.com with p=reject. But subdomain.company.com has no DMARC record. This means attackers can spoof that subdomain freely, and it will not show up in the top-level DMARC aggregate reports.

The fix is a wildcard record or explicit subdomain record: *._domainkey.company.com IN TXT "v=DMARC1; p=reject" covers all subdomains at once, or you can list specific subdomains individually.

2. Third-party relay misalignment

Many organizations send email through third parties: marketing automation platforms, CRM systems, support tools. Each of these uses its own infrastructure to send on behalf of your domain.

For DMARC to pass, the third party's SPF or DKIM must align with your domain. If the third party uses its own DKIM selector and does not sign with your domain's key, DMARC will fail regardless of your policy.

This is not theoretical. It is the leading cause of email deliverability failures when organizations first deploy DMARC.

3. Forwarding-induced alignment failures

When a message is forwarded, the envelope-from address often changes. If the forwarding service does not preserve DKIM signatures, the forwarded message will fail DMARC even though it originated from a legitimate sender.

This affects organizations that use mailing lists, email archiving services, and personal forwarding.

4. SPF 10-lookup limit

SPF has a hard limit of 10 DNS lookups per check. Organizations that include many third-party services in their SPF record can exceed this limit. Once SPF exceeds 10 lookups, it returns a permanent error (permerror) and is treated as a failure.

The result: legitimate mail starts failing DMARC with no obvious explanation.

5. Aggregate report neglect

Most organizations that deploy DMARC set a policy and never read the aggregate reports again. The reports are XML or JSON and require tooling to interpret.

This is the single biggest reason DMARC setups go stale. Alignment drifts. Third parties change their infrastructure. Subdomains proliferate. None of this shows up unless someone reads the reports.

Why expertise does not protect you

The LearnDMARC author understood all of these failure modes. The mistake still happened.

This is not a paradox. It is an operational reality.

Email infrastructure changes constantly. New sending services are added. Subdomains are created for new purposes. Third parties update their sending infrastructure. DMARC alignment that was correct last month can drift this month without anyone noticing.

Expert knowledge helps you understand what to look for. It does not automatically catch what has already gone wrong.

The only protection is continuous monitoring: reading aggregate reports on a schedule, setting up alerts for sudden changes in pass/fail rates, and treating DMARC as a live system rather than a one-time configuration.

This is where most organizations fall short. They know what DMARC is. They have a policy set. But nobody is watching the reports, and so nobody knows something has broken until a customer calls to say their password reset emails are not arriving.

What good DMARC monitoring looks like

Effective DMARC monitoring has a few non-negotiable elements.

First, you need aggregate report parsing. Raw DMARC aggregate reports are XML files. You need tooling that translates them into readable dashboards showing pass rates, alignment failures, and sources of DKIM and SPF failures. Without this, the reports are essentially unreadable for regular operational use.

Second, you need subdomain-level visibility. A top-level p=reject policy without subdomain monitoring is an incomplete deployment. You need to know when subdomains are being used for spoofing, and that requires subdomain-level reporting which DMARCFlow provides automatically.

Third, you need alerting on anomalies. A sudden drop in DMARC pass rate, a new ASN appearing in your reports, or a spike in alignment failures are all signals that something has changed and may need investigation.

DMARCFlow handles all three of these: automatic aggregate report parsing, subdomain-level visibility, and anomaly alerting. The LearnDMARC author found their mistake because they were watching their own reports. DMARCFlow is designed to give every organization that same capability without requiring you to build and maintain your own parsing infrastructure.

The bottom line

The LearnDMARC incident is a useful reminder that email authentication is not a set-and-forget task. Even the people who teach it for a living get it wrong occasionally.

The mistakes are predictable. Subdomain gaps, third-party misalignment, SPF lookup limits, and aggregate report neglect are the main culprits.

The solution is not more expertise. It is more monitoring. Read your aggregate reports. Set up alerts for sudden changes. Treat DMARC as a live system that needs ongoing attention.