← RFC Reference

DMARC — Domain-based Message Authentication, Reporting and Conformance

Why This RFC Exists

SPF and DKIM are powerful, but each has a critical gap. SPF validates the envelope sender domain, which users never see. DKIM validates whatever domain the signer chose, which may be an ESP's domain rather than the visible sender. Neither one, alone, prevents an attacker from spoofing the From: header that users actually read.

DMARC closes this gap by introducing two concepts:

1. Identifier alignment: At least one of SPF or DKIM must both pass and have its authenticated domain align with the From: header domain.
2. Domain owner policy: The domain owner publishes a DNS record declaring what receivers should do when alignment fails: monitor (p=none), quarantine (p=quarantine), or reject (p=reject).

DMARC also defines an aggregate reporting mechanism, allowing domain owners to receive daily XML reports showing how their domain is being used (and abused) across the internet.

How It Works

The DMARC Evaluation Flow

1. A message arrives with From: user@example.com.
2. The receiver checks SPF against the envelope sender domain. If SPF passes and the envelope domain matches example.com (or a subdomain, depending on alignment mode), SPF is "aligned."
3. The receiver checks DKIM. If a valid signature has d=example.com (or a subdomain), DKIM is "aligned."
4. If at least one of SPF or DKIM is both passing and aligned, DMARC passes.
5. If DMARC fails, the receiver queries _dmarc.example.com for the policy and applies it.

DMARC DNS Record

Alignment in Practice

Key Technical Details

Policy Tags

Alignment Modes

Relaxed alignment (default, adkim=r / aspf=r): The authenticated domain and the From: domain share the same organizational domain. For example, mail.example.com aligns with example.com.

Strict alignment (adkim=s / aspf=s): The authenticated domain must exactly match the From: domain. mail.example.com does not align with example.com.

Aggregate Reports (rua)

Receivers that support DMARC send daily aggregate reports in XML format to the rua address. These reports contain:

• The sending IP addresses that used your domain
• SPF and DKIM pass/fail results for each source
• The DMARC policy applied and the disposition (none, quarantine, reject)
• Message counts per source IP

These reports are invaluable for discovering unauthorized senders, identifying misconfigured legitimate sources, and building confidence before tightening your policy from none to reject.

External Destination Verification

If your rua or ruf address is at a different domain (e.g., rua=mailto:reports@analytics.com), the receiving domain must publish a DNS record authorizing it:

Without this record, report senders will not deliver reports to the external address, as a protection against using DMARC reports as a denial-of-service vector.

Common Mistakes

• Jumping straight to p=reject: Deploying a reject policy without first monitoring with p=none can silently block legitimate mail from forgotten sources (marketing platforms, CRM systems, SaaS apps sending on your behalf). Always start with p=none, analyze reports, fix alignment issues, then ramp up.
• Forgetting subdomain policy: Without sp=, subdomains inherit the domain's policy. If you set p=reject but have a subdomain sending mail without proper authentication, those messages will be rejected. Use sp= to control subdomain policy independently.
• Not setting up rua: DMARC without aggregate reports is flying blind. The reports tell you who is sending mail as your domain and whether authentication is working. Always configure rua.
• Misunderstanding alignment: A common mistake is thinking that having SPF and DKIM pass is enough. They must also align with the From: header domain. If your ESP uses bounce@esp.com as the envelope sender and signs DKIM as d=esp.com, neither aligns with your From: header, and DMARC fails.
• Using pct=0 as "monitoring only": While pct=0 technically means "apply the policy to 0% of failures," some receivers interpret it differently. Use p=none for monitoring, not pct=0 with a stricter policy.
• Mailing list breakage: Traditional mailing lists rewrite the envelope sender but preserve the From: header, breaking both SPF alignment and sometimes DKIM (if the list modifies the message). This is a known issue; ARC was created to address it.

Deliverability Impact

• Mandatory for bulk senders: Since February 2024, Gmail requires domains sending 5,000+ messages per day to have a DMARC policy (at minimum p=none). Yahoo has similar requirements. This makes DMARC non-optional for any serious sender.
• Brand protection: A p=reject policy prevents attackers from spoofing your domain in phishing campaigns. This protects your customers and your domain's reputation.
• Improved inbox placement: Domains with strong DMARC policies (quarantine or reject) demonstrate authentication maturity. Many receivers factor this into reputation scoring.
• BIMI eligibility: Brand Indicators for Message Identification (BIMI) requires a DMARC policy of p=quarantine or p=reject. BIMI displays your brand logo next to messages in supporting mail clients.
• Visibility into your email ecosystem: Aggregate reports reveal every IP sending mail as your domain. This visibility alone makes DMARC worth deploying, even at p=none.

Related RFCs