DMARC: What Happens When Email Auth Fails?

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is often described as "the thing that stops spoofing." That description is incomplete.

DMARC doesn’t stop email from being sent, nor does it perform cryptographic checks of its own. Instead, it functions as a policy and enforcement layer. It tells receiving mail servers what to do when existing checks (SPF or DKIM) fail, and verifies whether those results match the domain a recipient actually sees in their inbox.

Why SPF and DKIM Aren't Enough on Their Own

Before DMARC was introduced in the early 2010s, email providers relied on two distinct authentication checks:

• SPF verified whether a delivering server was authorized by a domain.
• DKIM verified whether a message had been altered in transit.

Neither mechanism resolved a fundamental problem: what should a server do when authentication fails, and does the check actually match the visible sender?

Without DMARC, SPF could pass for an underlying relay domain while the visible "From" address displayed a completely different brand. Similarly, DKIM could pass for an obscure signing domain the recipient had never heard of. Failures carried no predictable consequences, leaving enforcement entirely optional.

What DMARC Actually Checks

DMARC does not replace SPF or DKIM. Instead, it evaluates their output through two essential concepts: Alignment and Policy.

1. Alignment: Tying Checks to What Users See

Alignment answers a simple question: Does the domain verified by SPF or DKIM match the domain in the visible "From" header?

• If SPF passes, but the authorised domain doesn't match the visible "From" address, DMARC treats the check as a failure.
• If DKIM passes, but the signing domain doesn't match the visible "From" address, DMARC treats the check as a failure.

This requirement closes the spoofing loophole that SPF and DKIM leave open on their own.

2. Policy: Instructing Receivers How to Handle Failures

Once DMARC evaluates alignment, it enforces the policy published in the domain’s DNS record. Domain owners choose one of three explicit instructions for failed messages:

A DMARC Record Explained

A typical DMARC TXT record published in DNS looks like this:

Plaintext

_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"

• _dmarc: The required DNS namespace prefix where receiving servers look up policy rules.
• p=quarantine: The policy declaring how receiving servers should handle failed authentication.
• rua=mailto:...: Specifies where aggregate daily reports should be sent.

Reporting: The Part Most People Ignore

DMARC provides feedback loops directly to domain owners. When a DMARC record is published, receiving systems send daily aggregate reports showing:

• Which third-party servers and IP addresses are sending mail on behalf of the domain.
• Which sending streams pass or fail SPF, DKIM, and alignment checks.
• Real-world failures caused by misconfigurations, forgotten legacy systems, or broken DKIM keys.

Because these XML reports are voluminous and technical, many organizations use specialized aggregation services—such as Cloudflare or dedicated DMARC platforms—to interpret sending trends and spot abuse at scale.

Why DMARC Is Deployed in Stages

Enabling strict DMARC enforcement immediately can cause delivery outages if legitimate sending services are poorly configured. As a result, best practices dictate a staged rollout:

1. Monitor (p=none) ──► 2. Constrain (p=quarantine) ──► 3. Enforce (p=reject)

1. Monitor (p=none): Publish a policy to collect aggregate reports without affecting deliverability.
2. Constrain (p=quarantine): Fix misconfigured streams, then route failing mail to spam folders.
3. Enforce (p=reject): Fully protect the domain by instructing receivers to drop unauthenticated messages outright.

How the Protocols Work Together

DMARC is the decision layer that transforms isolated technical checks into enforceable domain protection. It doesn't evaluate message content, judge ethics, or replace spam filters, but it makes sender identity verifiable and accountable across the web.