How DMARC Works: Email Authentication Step by Step

Understanding how DMARC actually processes email helps you configure it correctly and diagnose issues when legitimate email fails authentication. This article walks through the full DMARC evaluation flow — from the moment a message arrives at a receiving server to how a policy decision is made and reported.

The DMARC Evaluation Flow

When a mail server receives an inbound email, it runs a series of checks before deciding what to do with the message. DMARC is evaluated after SPF and DKIM have already been checked. Here is the complete flow:

The receiving server extracts the From header domain from the message (this is the domain the human recipient sees as the sender).
It looks up the DMARC record at _dmarc.{from-header-domain}.com to find the policy.
It evaluates SPF — checks whether the sending IP is authorized for the envelope sender domain (Return-Path domain).
It evaluates DKIM — verifies the DKIM signature and extracts the signing domain (d= tag).
It performs DMARC alignment — checks whether the SPF domain or DKIM domain aligns with the From header domain.
Based on the results, it applies the DMARC policy (none, quarantine, or reject).
It sends a DMARC aggregate report to the address in the rua= tag.

Step 1: Locating the DMARC Record

The receiving server queries DNS for a TXT record at _dmarc.{from-domain}. For example, if the From header shows user@example.com, the server queries:

bash

dig _dmarc.example.com TXT +short
# Returns: "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

If no DMARC record exists, DMARC evaluation ends — no policy is applied and no reports are sent. The message is treated as if DMARC does not apply.

If the From domain is a subdomain (e.g., mail.example.com) and has no DMARC record, the server checks the organizational domain (example.com) and uses that record if found. The sp= tag in the parent DMARC record can specify a separate policy for subdomains.

Step 2: SPF Evaluation

SPF is evaluated against the Return-Path (also called the envelope sender or MAIL FROM domain) — not the From header. The receiving server checks whether the IP address that sent the email is listed in the SPF record of the Return-Path domain.

text

Return-Path: <bounce@sendingservice.com>   ← SPF checks this domain
From: user@example.com                      ← DMARC alignment checks this domain

If SPF passes but the Return-Path domain (sendingservice.com) doesn't match the From header domain (example.com), SPF passes the authentication check but fails DMARC alignment.

Step 3: DKIM Evaluation

The receiving server looks for a DKIM-Signature header in the email. It extracts the signing domain (d= tag) and selector (s= tag), fetches the corresponding public key from DNS, and verifies the cryptographic signature.

text

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=example.com;   ← DMARC checks alignment with this domain
  s=selector1;
  h=from:to:subject:date;
  bh=...;
  b=...

If the DKIM signature verifies successfully, DKIM passes. If the signing domain (d=example.com) matches (or aligns with) the From header domain (example.com), DMARC alignment passes via DKIM.

Step 4: DMARC Alignment

This is the critical step that sets DMARC apart from plain SPF/DKIM. DMARC requires alignment between the From header domain and the domain that passed SPF or DKIM.

Relaxed alignment (default, adkim=r or aspf=r): The organizational domain must match. Subdomains are allowed. mail.example.com aligns with example.com.

Strict alignment (adkim=s or aspf=s): The exact domain must match. mail.example.com does NOT align with example.com.

From Domain	Auth Domain	Relaxed Alignment	Strict Alignment
example.com	example.com	Pass	Pass
example.com	mail.example.com	Pass	Fail
example.com	otherdomain.com	Fail	Fail

DMARC passes if either SPF or DKIM alignsDMARC passes if at least one of SPF or DKIM produces an aligned pass. Both do not need to pass. However, configuring both SPF and DKIM provides redundancy — if one fails (e.g., email forwarding breaks SPF), the other can still carry DMARC.

Step 5: Policy Enforcement

If DMARC fails (neither SPF nor DKIM passed with alignment), the receiving server looks at the p= tag to decide what to do:

p=none: Deliver the message normally. Only generate a report. This mode is for monitoring — it does not protect recipients.
p=quarantine: Move the message to the spam/junk folder. The recipient may still read it, but it is flagged as suspicious.
p=reject: Reject the message at the SMTP level. The sender receives a bounce notification. The message never reaches the inbox.

The pct= tag (percentage) allows gradual rollout. pct=10 means the policy is applied to only 10% of failing messages — useful when transitioning from quarantine to reject.

Step 6: Aggregate Reports

Regardless of whether DMARC passed or failed, the receiving server generates report data and sends it to the address in the rua= tag once per day in XML format. Reports include:

The sending IP address and volume of messages.
SPF and DKIM authentication results.
DMARC alignment result (pass or fail).
Which policy was applied.

xml

<record>
  <row>
    <source_ip>192.0.2.1</source_ip>
    <count>1250</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>example.com</domain>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>example.com</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

Use DMARC lookup toolsCheck your DMARC record and validate its syntax with the ShowDNS DMARC Lookup tool.

Common DMARC Failure Scenarios

Understanding why DMARC fails helps you fix configuration issues:

Email forwarding: When a message is forwarded, the sending IP changes, breaking SPF. If DKIM is also not present or breaks during forwarding, DMARC will fail. This is a known limitation of SPF-only setups.
Third-party senders not in SPF: If you use an ESP (email service provider) that sends from its own IP range but hasn't been added to your SPF record, SPF fails and DMARC may fail depending on DKIM.
DKIM key mismatch: If the DKIM public key in DNS doesn't match the private key used to sign the message (e.g., after a key rotation), DKIM fails.
Subdomain with no SPF: If email is sent from a subdomain that has no SPF record, SPF returns a none result, which does not count as a pass.

Frequently Asked Questions

Does DMARC work without SPF or DKIM?

No. DMARC requires at least one of SPF or DKIM to pass with alignment. If neither is configured, DMARC will always fail. Configure SPF and DKIM before enabling a DMARC policy.

Why is my email marked as spam even with DMARC passing?

DMARC passing means the message is authenticated, but spam filtering is a separate layer. Receiving servers also evaluate content, IP reputation, domain reputation, and other signals. DMARC passing reduces the risk of spam marking but does not guarantee inbox placement.

What is the difference between DMARC aggregate and forensic reports?

Aggregate reports (rua=) are daily summaries of all email from a domain, grouped by source IP. Forensic reports (ruf=) are per-message reports generated immediately when DMARC fails, including message headers. Forensic reports may contain personally identifiable information, so not all providers send them.

How long does it take for DMARC to take effect?

The DMARC TXT record propagates like any other DNS change — typically within minutes to an hour, but potentially up to 48 hours depending on TTL values. Once published, receiving servers will begin evaluating and enforcing the policy for new incoming messages.