What is DMARC? How it works, the phases, and the path to p=reject.

Introduction

Anyone sending email under their own domain in 2026 can no longer avoid DMARC. Google and Yahoo have required authentication for higher-volume senders since 2024, Microsoft has followed suit, and PCI DSS 4.0 explicitly requires it as well.

The rollout is often underestimated. A DMARC record is published in ten minutes – the real problem begins afterwards. Because DMARC is not a configuration but a measuring instrument: it shows who is really sending emails in your name. And almost always it's more systems than anyone in the organization had on their radar.

This article explains DMARC the way we do in projects with IT leadership: technically correct, but without marketing gloss. Including the points where the topic gets more complicated in practice than the documentation suggests.

What is DMARC?

DMARC stands for Domain-based Message Authentication, Reporting & Conformance. It is a standard specified in RFC 7489 that does two things:

1. It defines how receiving mail servers should handle emailsthat claim to come from your domain but cannot be authenticated.
2. It ensures that you, as the domain owner, receive reports about the email traffic under your domain – including legitimate and illegitimate senders.

Technically, DMARC is a DNS TXT record published on the subdomain _dmarc.your-domain.com . A minimal record looks like this:

v=DMARC1; p=none; rua=mailto:reports@your-domain.com;

The three mandatory tags are quickly explained:

v=DMARC1

Version. Currently only one valid value.

p=none

Policy. Determines what happens to non-authenticated mail: none, quarantine or reject.

rua=mailto:…

Reporting address. Recipients send aggregated reports to this address daily.

How DMARC works

DMARC doesn't check whether an email is legitimate itself. Instead, it builds on two older standards – SPF and DKIM – and adds one decisive extra check: the alignmentcheck.

The process in five steps

1. A mail server receives an email that claims to come from your-domain.com .
2. The server retrieves the SPF record of your-domain.com and checks whether the sending IP address range is listed there.
3. The server checks the email's DKIM signature against the public key in the DNS.
4. At least one of the two checks must pass and the authenticated domain must match the visible sender domain (the Fromheader). That's the alignment.
5. If the check fails, the DMARC policy is applied: let through, move to spam, or reject. In parallel, an entry is created in the report.

The alignment step is the real added value of DMARC. Without it, an attacker could send an email from a foreign but validly signed domain claiming to come from your-bank.com – and SPF and DKIM would be satisfied. Only DMARC ensures that the visible domain is authenticated.

SPF, DKIM and DMARC – how they work together

In practice the three standards are often lumped together. But they answer different questions:

Only the combination of the three results in functioning spoofing protection. SPF and DKIM are the upfront checks, DMARC is the rule that builds on them and generates the content of the reports.

The path to p=reject

The actual goal of every DMARC rollout is p=reject. Only there does DMARC offer real protection against domain spoofing – before that, it's observation. The path there practically always runs through three phases that shouldn't be skipped.

Why not go straight to reject? Because on day one nobody knows everyone who actually sends under their own domain. Enforcing too early hits the third-party systems first – and they're usually business-critical.

What happens in this phase

The DMARC record is published with policy p=none . Emails are delivered normally. In the background, recipients like Google, Microsoft and Yahoo begin sending daily aggregated XML reports to the address specified in rua .

The goal is a complete assessment: which IPs send under your domain? Which of them are legitimate?

Goal at the end of the phase

• Every legitimate sender is identified and accounted for in the SPF and DKIM configuration.
• The share of emails passing DMARC is stable above 98%.
• The remaining failures are explained.

What happens in this phase

The policy is raised to p=quarantine . From now on, recipients treat non-authenticated emails under your domain like spam – they usually end up in the junk folder.

Goal at the end of the phase

• No more business-critical emails end up in spam due to missing authentication.
• SPF and DKIM coverage is above 99% and stable.
• pct=100 has been running without issues for at least two weeks.

What happens in this phase

The policy is set to p=reject. Receiving servers definitively reject every email that can't be authenticated as coming from your domain. Spoofed messages don't reach the recipient. That's the goal.

When is a domain really ready for reject?

• The DMARC pass rate is permanently stable at a level that no longer suggests business-critical errors.
• Every remaining error is assigned to a specific system – no more “unknown sender” in the reports.
• There are no new third-party onboardings in the pipeline that aren't yet authenticated.

DMARC reports: what they show

Reports are the heart of DMARC. Without them, the policy is blind. Recipients like Google send one or more XML documents to the ruaaddress daily.

<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
  </report_metadata>
  <record>
    <row>
      <source_ip>52.28.144.77</source_ip>
      <count>1842</count>
      <policy_evaluated>
        <dkim>pass</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
  </record>
</feedback>

Each report contains, per sending IP address, the number of mails, the result for SPF and DKIM, and the policy applied.

Why it matters now

DMARC has been specified since 2012, but only in the past two years has the pressure to enforce risen measurably. Three developments are acting in parallel:

What used to be a best practice has thus become a prerequisite for regular mail operation with larger recipients.

Where it gets complex in practice

The documentation makes DMARC out to be a linear process. In real setups there are a few points where it regularly snags.

SPF flattening and the 10-lookup limit

SPF allows a maximum of ten DNS lookups per record. Anyone who has integrated four or five third-parties quickly runs into this limit. The result is a permerror – SPF is effectively broken.

Third-party DKIM for marketing and transactional mail

Services like Mailchimp, Sendgrid or Salesforce Marketing Cloud can in principle handle DKIM signing – but only if the customer sets the appropriate CNAMEs on the domain side and the keys are rotated.

Email forwarding

When a recipient forwards the mail, SPF practically always breaks – the sender IP is then no longer the originally authorized one. DKIM usually stays intact.

Edge cases: mailing lists, shared services, legacy services

There are constellations that can't be solved cleanly. Mailing lists often don't change the Fromheader and therefore break DMARC. Old fax gateways, ticketing systems or internally operated mailers have no way to do DKIM signing.