Email Security - Learning Module

Loading content...

0/240

DMARC — Unifying Email Authentication with Policy Enforcement

The Missing Policy Layer

SPF validates sending IP addresses. DKIM validates message signatures. But a critical question remains unanswered: What should receivers do when these checks fail?

Before DMARC, every receiving mail server made its own decision. Some rejected SPF failures; others ignored them. Some quarantined DKIM failures; others delivered them anyway. Domain owners had no visibility into whether their domain was being spoofed and no control over how receivers handled spoofed messages.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) solves both problems:

Policy: Domain owners declare how receivers should handle authentication failures
Alignment: Connects SPF/DKIM to the visible From header users actually see
Reporting: Provides visibility into authentication results and attack attempts

Published as RFC 7489 (2015), DMARC is now a requirement for bulk senders to major mailbox providers. Gmail, Yahoo, and Microsoft require DMARC for domains sending over 5,000 emails daily. Understanding DMARC is no longer optional for any organization sending email at scale.

What You Will Learn

By the end of this page, you will understand DMARC's alignment model, policy options, reporting mechanisms, and deployment strategies. You'll be able to construct DMARC records for any domain, interpret aggregate and forensic reports, and troubleshoot alignment failures.

The Alignment Problem: Why SPF and DKIM Aren't Enough

SPF and DKIM authenticate different identifiers, neither of which is the visible From header that end users see and trust.

The Identity Gap

SPF authenticates: The envelope sender (MAIL FROM / Return-Path)

This is a behind-the-scenes address for bounces
Users never see this address

DKIM authenticates: The signing domain (d= tag in DKIM-Signature)

Can be any domain the sender controls
Doesn't have to match the visible From

Users see and trust: The From header (From: "CEO" <ceo@company.com>)

This is what appears in email clients
This is what phishing attacks spoof

The Attack Scenario

spoofing-despite-spf-dkim.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# Attacker sends phishing email that PASSES both SPF and DKIM
# but spoofs the visible From header
 
Return-Path: <bounce@attacker-domain.com>    ← SPF checks this
Received: from mail.attacker-domain.com [198.51.100.50]
DKIM-Signature: v=1; d=attacker-domain.com; s=sel1; ...  ← DKIM checks d=
From: "CEO John Smith" <ceo@legitimate-bank.com>  ← USER SEES THIS
To: victim@target.com
Subject: Urgent: Wire Transfer Required
 
Click here to authorize payment...
 
# SPF result: PASS (198.51.100.50 authorized for attacker-domain.com)
# DKIM result: PASS (valid signature for attacker-domain.com)
# User sees: "From: ceo@legitimate-bank.com"
# Attack: SUCCESSFUL without DMARC!
 
# Why this works:
# - SPF validates envelope (attacker-domain.com) ✓
# - DKIM validates signature (attacker-domain.com) ✓
# - Neither validates the visible From header!

DMARC's Solution: Identifier Alignment

DMARC requires that SPF and/or DKIM authenticate an identifier that aligns with the visible From domain.

SPF Alignment: The domain in the envelope sender (MAIL FROM) must align with the From header domain.

DKIM Alignment: The signing domain (d= tag) must align with the From header domain.

At least one must pass AND align for DMARC to pass.

Alignment Modes

DMARC supports two alignment modes:

Strict (s): Exact domain match required. mail.example.com does NOT align with example.com.

Relaxed (r): Organizational domain match. mail.example.com DOES align with example.com (shares the same organizational domain).

Default is relaxed, which is more forgiving for subdomains.

How DMARC Works: The Evaluation Process

DMARC evaluation occurs after SPF and DKIM checks have completed. It ties their results together through alignment and applies the domain owner's policy.

DMARC Evaluation Algorithm

Extract From domain: Parse the RFC 5322 From header to get the domain (e.g., example.com)
Query DMARC record: Look up _dmarc.example.com TXT record
Check SPF alignment:
- Did SPF pass?
- Does the MAIL FROM domain align with the From domain?
- If both yes → SPF alignment passes
Check DKIM alignment:
- Did DKIM pass?
- Does the DKIM d= domain align with the From domain?
- If both yes → DKIM alignment passes
Determine DMARC result:
- If SPF alignment passes OR DKIM alignment passes → DMARC Pass
- If neither passes → DMARC Fail
Apply policy: Based on the p= tag, take action (none, quarantine, reject)
Generate reports: Collect data for aggregate/forensic reports

Converting Mermaid diagram...

dmarc-alignment-examples.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
# Example 1: SPF Alignment PASS (relaxed mode)
 
From: user@mail.example.com
MAIL FROM: bounce@marketing.example.com
SPF: PASS for marketing.example.com
 
Alignment check (relaxed):
- From domain: example.com (organizational)
- MAIL FROM domain: example.com (organizational)
- Same organizational domain → SPF ALIGNED ✓
 
# Example 2: DKIM Alignment PASS (relaxed mode)
 
From: user@example.com
DKIM-Signature: d=news.example.com; ...
DKIM: PASS
 
Alignment check (relaxed):
- From domain: example.com (organizational)
- DKIM d= domain: example.com (organizational)
- Same organizational domain → DKIM ALIGNED ✓
 
# Example 3: Both Fail Alignment (strict mode)
 
DMARC policy: p=reject; aspf=s; adkim=s
 
From: user@example.com
MAIL FROM: bounce@mail.example.com
DKIM-Signature: d=mail.example.com; ...
 
Alignment check (strict):
- From domain: example.com
- MAIL FROM domain: mail.example.com (different!)
- DKIM d= domain: mail.example.com (different!)
- Neither aligns strictly → DMARC FAIL
- Policy: reject → Message blocked

DMARC Record Syntax: Complete Reference

DMARC records are published as DNS TXT records at the _dmarc subdomain. Understanding each tag enables precise policy configuration.

Record Structure

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

DMARC Record Tags Reference
Tag	Required	Description	Values/Example
`v=`	Yes	Protocol version	`v=DMARC1` (always)
`p=`	Yes	Policy for domain	`none`, `quarantine`, `reject`
`sp=`	No	Policy for subdomains	`none`, `quarantine`, `reject` (defaults to p=)
`pct=`	No	Percent of messages to apply policy	`pct=50` (gradual rollout)
`rua=`	No	Aggregate report URI(s)	`rua=mailto:dmarc@example.com`
`ruf=`	No	Forensic report URI(s)	`ruf=mailto:forensic@example.com`
`adkim=`	No	DKIM alignment mode	`r` (relaxed, default), `s` (strict)
`aspf=`	No	SPF alignment mode	`r` (relaxed, default), `s` (strict)
`fo=`	No	Forensic reporting options	`0` (default), `1`, `d`, `s`
`ri=`	No	Reporting interval (seconds)	`ri=86400` (daily, default)

Policy Definitions

p=none (Monitor Only)

Take no action on DMARC failures
Deliver messages normally
Collect data via reports
Use during initial deployment

p=quarantine (Flag Suspicious)

Treat DMARC failures as suspicious
Typically delivered to spam/junk folder
Users can find and recover if needed
Intermediate step before reject

p=reject (Block Completely)

Reject DMARC failures at SMTP level
Messages never reach inbox
Strongest protection against spoofing
Final goal for most domains

dmarc-record-examples.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
# Example 1: Monitoring mode (initial deployment)
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-agg@example.com"
# - No enforcement, just collect reports
# - Analyze reports to identify all legitimate senders
 
# Example 2: Gradual enforcement (5% quarantine)
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; pct=5; rua=mailto:dmarc@example.com"
# - 5% of failing messages quarantined
# - 95% still delivered (with DMARC failure noted)
# - Monitor for false positives before increasing
 
# Example 3: Full enforcement with reporting
_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com"
# - 100% DMARC failures rejected
# - Aggregate reports for statistics
# - Forensic reports for detailed failure analysis
 
# Example 4: Strict alignment with subdomain policy
_dmarc.example.com. TXT "v=DMARC1; p=reject; sp=quarantine; aspf=s; adkim=s; rua=mailto:dmarc@example.com"
# - Main domain: strict reject
# - Subdomains: quarantine only (more lenient)
# - Strict alignment for both SPF and DKIM
 
# Example 5: Multiple report destinations
_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com,mailto:reports@thirdparty.com"
# - Reports sent to both internal and third-party analyzer

DMARC Reporting: Visibility into Authentication

DMARC's reporting mechanism is arguably as valuable as its policy enforcement. Reports provide visibility into how your domain is being used (and abused) across the internet.

Aggregate Reports (RUA)

Aggregate reports are XML files sent daily (by default) containing statistics about DMARC evaluation for your domain.

Contents:

Reporting organization identity
Date range covered
Published DMARC policy
Statistics by source IP:
- Message count
- SPF result and alignment
- DKIM result and alignment
- Policy applied
- Disposition (none/quarantine/reject)

Use cases:

Identify legitimate senders not yet in SPF/DKIM
Detect spoofing/abuse from unauthorized sources
Verify authentication is working correctly
Track policy enforcement over time

dmarc-aggregate-report.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <report_id>12345678901234567890</report_id>
    <date_range>
      <begin>1705363200</begin>
      <end>1705449600</end>
    </date_range>
  </report_metadata>
  
  <policy_published>
    <domain>example.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>reject</p>
    <sp>reject</sp>
    <pct>100</pct>
  </policy_published>
  
  <record>
    <row>
      <source_ip>203.0.113.50</source_ip>
      <count>2547</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>
        <selector>sel1</selector>
      </dkim>
      <spf>
        <domain>example.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
  
  <!-- Suspicious record: spoofing attempt -->
  <record>
    <row>
      <source_ip>198.51.100.99</source_ip>
      <count>347</count>
      <policy_evaluated>
        <disposition>reject</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <spf>
        <domain>malicious.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

Forensic Reports (RUF)

Forensic reports contain detailed information about individual message failures.

Contents:

Redacted or full message headers
Authentication results
Delivery disposition
Time of receipt

Privacy considerations:

Many large mailbox providers don't send forensic reports (privacy concerns)
Some redact sensitive information
Use carefully—may expose end-user data

Forensic reporting options (fo= tag):

fo=0: Generate report if all mechanisms fail (default)
fo=1: Generate report if any mechanism fails
fo=d: Generate report if DKIM fails
fo=s: Generate report if SPF fails

DMARC Report Processing

Raw DMARC reports are XML and can be overwhelming in volume. Use dedicated services (DMARC Analyzer, Dmarcian, Valimail, PowerDMARC) or open-source tools (parsedmarc, DMARC Report Analyzer) to aggregate, visualize, and alert on report data. These tools transform raw XML into actionable dashboards.

External Report Destinations

By default, DMARC reports can only be sent to addresses within the domain being authenticated. Sending reports to external addresses requires explicit authorization to prevent abuse.

The Problem

If anyone could specify rua=mailto:victim@example.com in a DMARC record, attackers could flood arbitrary mailboxes with reports. DMARC defines a verification mechanism for external destinations.

External Destination Verification

To receive DMARC reports for example.com at reports@thirdparty.com:

Domain owner publishes: rua=mailto:reports@thirdparty.com

Third party must authorize by publishing:

example.com._report._dmarc.thirdparty.com. TXT "v=DMARC1"

Report generator checks: Before sending to external address, looks up the authorization record
If authorized: Reports sent to third party
If not authorized: Reports not sent, or sent only to internal addresses

external-report-auth.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# Scenario: example.com wants reports sent to dmarcservice.net
 
# Step 1: example.com publishes DMARC with external RUA
_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:reports@dmarcservice.net"
 
# Step 2: dmarcservice.net authorizes receiving reports for example.com
example.com._report._dmarc.dmarcservice.net. TXT "v=DMARC1"
 
# Step 3: Report generator (e.g., Google) 
# - Processes mail for example.com
# - Sees rua points to dmarcservice.net (external)
# - Queries: example.com._report._dmarc.dmarcservice.net
# - Finds authorization record
# - Sends aggregate reports to reports@dmarcservice.net
 
# Multiple domains can authorize the same external destination
customer1.com._report._dmarc.dmarcservice.net. TXT "v=DMARC1"
customer2.com._report._dmarc.dmarcservice.net. TXT "v=DMARC1"
customer3.com._report._dmarc.dmarcservice.net. TXT "v=DMARC1"
 
# The third-party service receives reports for all customers

Report Volume Considerations

Large domains can receive hundreds of megabytes of report data daily. The rua mailbox should be a dedicated address with appropriate storage and automated processing, not a human's inbox. Consider using a subdomain specifically for DMARC (e.g., dmarc-reports@example.com).

DMARC Deployment: A Phased Approach

DMARC deployment should be methodical and phased to avoid blocking legitimate email. Rushing to p=reject without proper preparation causes outages.

The DMARC Journey

DMARC Deployment Phases

•Phase 1: Inventory and Preparation — Identify all legitimate email sources. Ensure SPF and DKIM are deployed and working for each source. Fix any alignment issues.
•Phase 2: Monitor (p=none) — Deploy DMARC with p=none and reporting. Collect 2-4 weeks of data. Analyze reports to find missed sources or configuration issues.
•Phase 3: Quarantine Rollout (p=quarantine, pct=5→100) — Start with pct=5 to affect only 5% of failing messages. Monitor for user complaints. Gradually increase pct while monitoring.
•Phase 4: Reject Rollout (p=reject, pct=5→100) — After quarantine at 100% shows no issues, switch to reject. Again start at low pct and increase gradually.
•Phase 5: Ongoing Maintenance — Monitor reports continuously. Update SPF/DKIM when adding new senders. Review alignment for new services.

DMARC Rollout Timeline Example
Week	Policy	pct	Actions
1-4	`p=none`		Deploy, collect reports, analyze senders
5-6	`p=quarantine`	`5`	Begin quarantine, monitor complaints
7-8	`p=quarantine`	`25`	Expand quarantine coverage
9-10	`p=quarantine`	`50`	Half of failures quarantined
11-12	`p=quarantine`	`100`	Full quarantine enforcement
13	`p=reject`	`5`	Begin reject with caution
14	`p=reject`	`25`	Expand reject coverage
15	`p=reject`	`50`	Half of failures rejected
16+	`p=reject`	`100`	Full enforcement achieved

dmarc-progression.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
# Week 1: Start monitoring
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
 
# Week 5: Begin quarantine (5%)
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; pct=5; rua=mailto:dmarc@example.com"
 
# Week 8: Increase quarantine
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com"
 
# Week 12: Full quarantine
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@example.com"
 
# Week 13: Begin reject (5%)
_dmarc.example.com. TXT "v=DMARC1; p=reject; pct=5; rua=mailto:dmarc@example.com"
 
# Week 16+: Full enforcement
_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
 
# Final state (production)
_dmarc.example.com. TXT "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc@example.com"

Common DMARC Challenges and Solutions

Several scenarios commonly complicate DMARC deployment. Understanding these challenges helps avoid pitfalls.

Challenge 1: Email Forwarding

When email is forwarded (e.g., university.edu → gmail.com), SPF fails because the forwarding server's IP isn't authorized by the original domain. DKIM usually survives if the forwarder doesn't modify the message.

Solution:

Rely on DKIM alignment (survives forwarding)
Encourage use of ARC (Authenticated Received Chain)
Accept that some forwarded mail may fail DMARC

Challenge 2: Third-Party Senders

Marketing platforms, CRM systems, and other third parties send email "as" your domain but from their infrastructure.

Solution:

Ensure each third party is in your SPF
Configure DKIM signing with your domain (d=yourdomain.com)
Verify alignment before deploying enforcement

Additional DMARC Challenges

•Mailing Lists — Often modify Subject/body, breaking DKIM. May rewrite envelope sender, breaking SPF alignment. Use ARC-supporting lists where possible.
•Shadow IT — Departments using unauthorized email services that aren't in SPF/DKIM. Discovery through DMARC reports before enforcement.
•Partner/Vendor Communications — Some partners send email 'as' your employees via their systems. Requires careful authentication setup.
•Legacy Systems — Old applications that send email but don't support DKIM. May need relay through a signing server.
•Customer Reply-To Confusion — Customer replies may go to unexpected addresses, confusing authentication expectations.

ARC: Solving the Forwarding Problem

Authenticated Received Chain (ARC) is a newer standard (RFC 8617) that preserves authentication results through forwarding chains.

When a forwarder receives a message that passes authentication:

It records the authentication results in an ARC header
It signs this record
Downstream receivers can evaluate the ARC chain
If the forwarder is trusted, original authentication is preserved

ARC is now widely supported by major mailbox providers and helps legitimate forwarded mail pass DMARC despite SPF failures.

Subdomain Strategy

Consider using dedicated subdomains for different email purposes:

• mail.example.com — Corporate mail (full DMARC enforcement) • marketing.example.com — Marketing platforms (separate SPF/DKIM) • transactional.example.com — Automated system emails • support.example.com — Help desk system

This isolates authentication configurations and limits blast radius if one system is compromised.

Summary: The Complete Authentication Stack

DMARC completes the email authentication triad by adding policy enforcement and alignment requirements to SPF and DKIM. Let's consolidate the key concepts:

Key Takeaways

•DMARC bridges SPF/DKIM to the visible From — The alignment requirement connects authentication to what users actually see, preventing spoofing despite passing SPF/DKIM.
•Policy controls receiver behavior — Domain owners can specify none/quarantine/reject, giving them control over how failures are handled globally.
•Alignment can be strict or relaxed — Relaxed allows subdomain matching, while strict requires exact domain match. Relaxed is default and more forgiving.
•Reporting provides visibility — Aggregate reports reveal all sources sending as your domain, legitimate and malicious. This data drives informed deployment.
•Deploy incrementally — Monitor → Quarantine (5%→100%) → Reject (5%→100%). Rushing causes legitimate mail to be blocked.
•SPF + DKIM + DMARC together provide robust protection — Each protocol addresses different attack vectors. Together they form complete email authentication.

The Complete Email Authentication Stack
Protocol	What It Validates	Published In	Survives Forwarding
SPF	Sending IP is authorized for envelope domain	`example.com TXT`	No
DKIM	Message signed by domain, content unmodified	`selector._domainkey.example.com TXT`	Usually yes
DMARC	SPF/DKIM align with visible From; policy enforcement	`_dmarc.example.com TXT`	Via DKIM & ARC

What's Next:

SPF, DKIM, and DMARC authenticate email senders. But they don't protect message content from being read by adversaries. The final page covers Email Encryption, including:

S/MIME (Secure/Multipurpose Internet Mail Extensions)
PGP/GPG (Pretty Good Privacy)
Transport Layer Security (TLS for SMTP)

These technologies ensure email content confidentiality in addition to sender authentication.

Page Complete

You now understand DMARC's alignment model, policy options, reporting mechanisms, and deployment strategies. You can construct DMARC records for any domain, interpret aggregate reports, troubleshoot alignment failures, and guide organizations through DMARC deployment from monitoring to full enforcement.

DMARC — Unifying Email Authentication with Policy Enforcement

The Missing Policy Layer

SPF validates sending IP addresses. DKIM validates message signatures. But a critical question remains unanswered: What should receivers do when these checks fail?

DMARC (Domain-based Message Authentication, Reporting, and Conformance) solves both problems:

Policy: Domain owners declare how receivers should handle authentication failures
Alignment: Connects SPF/DKIM to the visible From header users actually see
Reporting: Provides visibility into authentication results and attack attempts

What You Will Learn

The Alignment Problem: Why SPF and DKIM Aren't Enough

SPF and DKIM authenticate different identifiers, neither of which is the visible From header that end users see and trust.

The Identity Gap

SPF authenticates: The envelope sender (MAIL FROM / Return-Path)

This is a behind-the-scenes address for bounces
Users never see this address

DKIM authenticates: The signing domain (d= tag in DKIM-Signature)

Can be any domain the sender controls
Doesn't have to match the visible From

Users see and trust: The From header (From: "CEO" <ceo@company.com>)

This is what appears in email clients
This is what phishing attacks spoof

The Attack Scenario

spoofing-despite-spf-dkim.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# Attacker sends phishing email that PASSES both SPF and DKIM
# but spoofs the visible From header
 
Return-Path: <bounce@attacker-domain.com>    ← SPF checks this
Received: from mail.attacker-domain.com [198.51.100.50]
DKIM-Signature: v=1; d=attacker-domain.com; s=sel1; ...  ← DKIM checks d=
From: "CEO John Smith" <ceo@legitimate-bank.com>  ← USER SEES THIS
To: victim@target.com
Subject: Urgent: Wire Transfer Required
 
Click here to authorize payment...
 
# SPF result: PASS (198.51.100.50 authorized for attacker-domain.com)
# DKIM result: PASS (valid signature for attacker-domain.com)
# User sees: "From: ceo@legitimate-bank.com"
# Attack: SUCCESSFUL without DMARC!
 
# Why this works:
# - SPF validates envelope (attacker-domain.com) ✓
# - DKIM validates signature (attacker-domain.com) ✓
# - Neither validates the visible From header!

DMARC's Solution: Identifier Alignment

DMARC requires that SPF and/or DKIM authenticate an identifier that aligns with the visible From domain.

SPF Alignment: The domain in the envelope sender (MAIL FROM) must align with the From header domain.

DKIM Alignment: The signing domain (d= tag) must align with the From header domain.

At least one must pass AND align for DMARC to pass.

Alignment Modes

DMARC supports two alignment modes:

Strict (s): Exact domain match required. mail.example.com does NOT align with example.com.

Relaxed (r): Organizational domain match. mail.example.com DOES align with example.com (shares the same organizational domain).

Default is relaxed, which is more forgiving for subdomains.

How DMARC Works: The Evaluation Process

DMARC evaluation occurs after SPF and DKIM checks have completed. It ties their results together through alignment and applies the domain owner's policy.

DMARC Evaluation Algorithm

Extract From domain: Parse the RFC 5322 From header to get the domain (e.g., example.com)
Query DMARC record: Look up _dmarc.example.com TXT record
Check SPF alignment:
- Did SPF pass?
- Does the MAIL FROM domain align with the From domain?
- If both yes → SPF alignment passes
Check DKIM alignment:
- Did DKIM pass?
- Does the DKIM d= domain align with the From domain?
- If both yes → DKIM alignment passes
Determine DMARC result:
- If SPF alignment passes OR DKIM alignment passes → DMARC Pass
- If neither passes → DMARC Fail
Apply policy: Based on the p= tag, take action (none, quarantine, reject)
Generate reports: Collect data for aggregate/forensic reports

Converting Mermaid diagram...

dmarc-alignment-examples.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
# Example 1: SPF Alignment PASS (relaxed mode)
 
From: user@mail.example.com
MAIL FROM: bounce@marketing.example.com
SPF: PASS for marketing.example.com
 
Alignment check (relaxed):
- From domain: example.com (organizational)
- MAIL FROM domain: example.com (organizational)
- Same organizational domain → SPF ALIGNED ✓
 
# Example 2: DKIM Alignment PASS (relaxed mode)
 
From: user@example.com
DKIM-Signature: d=news.example.com; ...
DKIM: PASS
 
Alignment check (relaxed):
- From domain: example.com (organizational)
- DKIM d= domain: example.com (organizational)
- Same organizational domain → DKIM ALIGNED ✓
 
# Example 3: Both Fail Alignment (strict mode)
 
DMARC policy: p=reject; aspf=s; adkim=s
 
From: user@example.com
MAIL FROM: bounce@mail.example.com
DKIM-Signature: d=mail.example.com; ...
 
Alignment check (strict):
- From domain: example.com
- MAIL FROM domain: mail.example.com (different!)
- DKIM d= domain: mail.example.com (different!)
- Neither aligns strictly → DMARC FAIL
- Policy: reject → Message blocked

DMARC Record Syntax: Complete Reference

DMARC records are published as DNS TXT records at the _dmarc subdomain. Understanding each tag enables precise policy configuration.

Record Structure

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

DMARC Record Tags Reference
Tag	Required	Description	Values/Example
`v=`	Yes	Protocol version	`v=DMARC1` (always)
`p=`	Yes	Policy for domain	`none`, `quarantine`, `reject`
`sp=`	No	Policy for subdomains	`none`, `quarantine`, `reject` (defaults to p=)
`pct=`	No	Percent of messages to apply policy	`pct=50` (gradual rollout)
`rua=`	No	Aggregate report URI(s)	`rua=mailto:dmarc@example.com`
`ruf=`	No	Forensic report URI(s)	`ruf=mailto:forensic@example.com`
`adkim=`	No	DKIM alignment mode	`r` (relaxed, default), `s` (strict)
`aspf=`	No	SPF alignment mode	`r` (relaxed, default), `s` (strict)
`fo=`	No	Forensic reporting options	`0` (default), `1`, `d`, `s`
`ri=`	No	Reporting interval (seconds)	`ri=86400` (daily, default)

Policy Definitions

p=none (Monitor Only)

Take no action on DMARC failures
Deliver messages normally
Collect data via reports
Use during initial deployment

p=quarantine (Flag Suspicious)

Treat DMARC failures as suspicious
Typically delivered to spam/junk folder
Users can find and recover if needed
Intermediate step before reject

p=reject (Block Completely)

Reject DMARC failures at SMTP level
Messages never reach inbox
Strongest protection against spoofing
Final goal for most domains

dmarc-record-examples.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
# Example 1: Monitoring mode (initial deployment)
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-agg@example.com"
# - No enforcement, just collect reports
# - Analyze reports to identify all legitimate senders
 
# Example 2: Gradual enforcement (5% quarantine)
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; pct=5; rua=mailto:dmarc@example.com"
# - 5% of failing messages quarantined
# - 95% still delivered (with DMARC failure noted)
# - Monitor for false positives before increasing
 
# Example 3: Full enforcement with reporting
_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com"
# - 100% DMARC failures rejected
# - Aggregate reports for statistics
# - Forensic reports for detailed failure analysis
 
# Example 4: Strict alignment with subdomain policy
_dmarc.example.com. TXT "v=DMARC1; p=reject; sp=quarantine; aspf=s; adkim=s; rua=mailto:dmarc@example.com"
# - Main domain: strict reject
# - Subdomains: quarantine only (more lenient)
# - Strict alignment for both SPF and DKIM
 
# Example 5: Multiple report destinations
_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com,mailto:reports@thirdparty.com"
# - Reports sent to both internal and third-party analyzer

DMARC Reporting: Visibility into Authentication

DMARC's reporting mechanism is arguably as valuable as its policy enforcement. Reports provide visibility into how your domain is being used (and abused) across the internet.

Aggregate Reports (RUA)

Aggregate reports are XML files sent daily (by default) containing statistics about DMARC evaluation for your domain.

Contents:

Reporting organization identity
Date range covered
Published DMARC policy
Statistics by source IP:
- Message count
- SPF result and alignment
- DKIM result and alignment
- Policy applied
- Disposition (none/quarantine/reject)

Use cases:

Identify legitimate senders not yet in SPF/DKIM
Detect spoofing/abuse from unauthorized sources
Verify authentication is working correctly
Track policy enforcement over time

dmarc-aggregate-report.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <report_id>12345678901234567890</report_id>
    <date_range>
      <begin>1705363200</begin>
      <end>1705449600</end>
    </date_range>
  </report_metadata>
  
  <policy_published>
    <domain>example.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>reject</p>
    <sp>reject</sp>
    <pct>100</pct>
  </policy_published>
  
  <record>
    <row>
      <source_ip>203.0.113.50</source_ip>
      <count>2547</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>
        <selector>sel1</selector>
      </dkim>
      <spf>
        <domain>example.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
  
  <!-- Suspicious record: spoofing attempt -->
  <record>
    <row>
      <source_ip>198.51.100.99</source_ip>
      <count>347</count>
      <policy_evaluated>
        <disposition>reject</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <spf>
        <domain>malicious.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

Forensic Reports (RUF)

Forensic reports contain detailed information about individual message failures.

Contents:

Redacted or full message headers
Authentication results
Delivery disposition
Time of receipt

Privacy considerations:

Many large mailbox providers don't send forensic reports (privacy concerns)
Some redact sensitive information
Use carefully—may expose end-user data

Forensic reporting options (fo= tag):

fo=0: Generate report if all mechanisms fail (default)
fo=1: Generate report if any mechanism fails
fo=d: Generate report if DKIM fails
fo=s: Generate report if SPF fails

DMARC Report Processing

External Report Destinations

By default, DMARC reports can only be sent to addresses within the domain being authenticated. Sending reports to external addresses requires explicit authorization to prevent abuse.

The Problem

If anyone could specify rua=mailto:victim@example.com in a DMARC record, attackers could flood arbitrary mailboxes with reports. DMARC defines a verification mechanism for external destinations.

External Destination Verification

To receive DMARC reports for example.com at reports@thirdparty.com:

Domain owner publishes: rua=mailto:reports@thirdparty.com

Third party must authorize by publishing:

example.com._report._dmarc.thirdparty.com. TXT "v=DMARC1"

Report generator checks: Before sending to external address, looks up the authorization record
If authorized: Reports sent to third party
If not authorized: Reports not sent, or sent only to internal addresses

external-report-auth.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# Scenario: example.com wants reports sent to dmarcservice.net
 
# Step 1: example.com publishes DMARC with external RUA
_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:reports@dmarcservice.net"
 
# Step 2: dmarcservice.net authorizes receiving reports for example.com
example.com._report._dmarc.dmarcservice.net. TXT "v=DMARC1"
 
# Step 3: Report generator (e.g., Google) 
# - Processes mail for example.com
# - Sees rua points to dmarcservice.net (external)
# - Queries: example.com._report._dmarc.dmarcservice.net
# - Finds authorization record
# - Sends aggregate reports to reports@dmarcservice.net
 
# Multiple domains can authorize the same external destination
customer1.com._report._dmarc.dmarcservice.net. TXT "v=DMARC1"
customer2.com._report._dmarc.dmarcservice.net. TXT "v=DMARC1"
customer3.com._report._dmarc.dmarcservice.net. TXT "v=DMARC1"
 
# The third-party service receives reports for all customers

Report Volume Considerations

DMARC Deployment: A Phased Approach

DMARC deployment should be methodical and phased to avoid blocking legitimate email. Rushing to p=reject without proper preparation causes outages.

The DMARC Journey

DMARC Deployment Phases

•Phase 1: Inventory and Preparation — Identify all legitimate email sources. Ensure SPF and DKIM are deployed and working for each source. Fix any alignment issues.
•Phase 2: Monitor (p=none) — Deploy DMARC with p=none and reporting. Collect 2-4 weeks of data. Analyze reports to find missed sources or configuration issues.
•Phase 3: Quarantine Rollout (p=quarantine, pct=5→100) — Start with pct=5 to affect only 5% of failing messages. Monitor for user complaints. Gradually increase pct while monitoring.
•Phase 4: Reject Rollout (p=reject, pct=5→100) — After quarantine at 100% shows no issues, switch to reject. Again start at low pct and increase gradually.
•Phase 5: Ongoing Maintenance — Monitor reports continuously. Update SPF/DKIM when adding new senders. Review alignment for new services.

DMARC Rollout Timeline Example
Week	Policy	pct	Actions
1-4	`p=none`		Deploy, collect reports, analyze senders
5-6	`p=quarantine`	`5`	Begin quarantine, monitor complaints
7-8	`p=quarantine`	`25`	Expand quarantine coverage
9-10	`p=quarantine`	`50`	Half of failures quarantined
11-12	`p=quarantine`	`100`	Full quarantine enforcement
13	`p=reject`	`5`	Begin reject with caution
14	`p=reject`	`25`	Expand reject coverage
15	`p=reject`	`50`	Half of failures rejected
16+	`p=reject`	`100`	Full enforcement achieved

dmarc-progression.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
# Week 1: Start monitoring
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
 
# Week 5: Begin quarantine (5%)
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; pct=5; rua=mailto:dmarc@example.com"
 
# Week 8: Increase quarantine
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com"
 
# Week 12: Full quarantine
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@example.com"
 
# Week 13: Begin reject (5%)
_dmarc.example.com. TXT "v=DMARC1; p=reject; pct=5; rua=mailto:dmarc@example.com"
 
# Week 16+: Full enforcement
_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
 
# Final state (production)
_dmarc.example.com. TXT "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc@example.com"

Common DMARC Challenges and Solutions

Several scenarios commonly complicate DMARC deployment. Understanding these challenges helps avoid pitfalls.

Challenge 1: Email Forwarding

Solution:

Rely on DKIM alignment (survives forwarding)
Encourage use of ARC (Authenticated Received Chain)
Accept that some forwarded mail may fail DMARC

Challenge 2: Third-Party Senders

Marketing platforms, CRM systems, and other third parties send email "as" your domain but from their infrastructure.

Solution:

Ensure each third party is in your SPF
Configure DKIM signing with your domain (d=yourdomain.com)
Verify alignment before deploying enforcement

Additional DMARC Challenges

•Mailing Lists — Often modify Subject/body, breaking DKIM. May rewrite envelope sender, breaking SPF alignment. Use ARC-supporting lists where possible.
•Shadow IT — Departments using unauthorized email services that aren't in SPF/DKIM. Discovery through DMARC reports before enforcement.
•Partner/Vendor Communications — Some partners send email 'as' your employees via their systems. Requires careful authentication setup.
•Legacy Systems — Old applications that send email but don't support DKIM. May need relay through a signing server.
•Customer Reply-To Confusion — Customer replies may go to unexpected addresses, confusing authentication expectations.

ARC: Solving the Forwarding Problem

Authenticated Received Chain (ARC) is a newer standard (RFC 8617) that preserves authentication results through forwarding chains.

When a forwarder receives a message that passes authentication:

It records the authentication results in an ARC header
It signs this record
Downstream receivers can evaluate the ARC chain
If the forwarder is trusted, original authentication is preserved

ARC is now widely supported by major mailbox providers and helps legitimate forwarded mail pass DMARC despite SPF failures.

Subdomain Strategy

Consider using dedicated subdomains for different email purposes:

This isolates authentication configurations and limits blast radius if one system is compromised.

Summary: The Complete Authentication Stack

DMARC completes the email authentication triad by adding policy enforcement and alignment requirements to SPF and DKIM. Let's consolidate the key concepts:

Key Takeaways

•DMARC bridges SPF/DKIM to the visible From — The alignment requirement connects authentication to what users actually see, preventing spoofing despite passing SPF/DKIM.
•Policy controls receiver behavior — Domain owners can specify none/quarantine/reject, giving them control over how failures are handled globally.
•Alignment can be strict or relaxed — Relaxed allows subdomain matching, while strict requires exact domain match. Relaxed is default and more forgiving.
•Reporting provides visibility — Aggregate reports reveal all sources sending as your domain, legitimate and malicious. This data drives informed deployment.
•Deploy incrementally — Monitor → Quarantine (5%→100%) → Reject (5%→100%). Rushing causes legitimate mail to be blocked.
•SPF + DKIM + DMARC together provide robust protection — Each protocol addresses different attack vectors. Together they form complete email authentication.

The Complete Email Authentication Stack
Protocol	What It Validates	Published In	Survives Forwarding
SPF	Sending IP is authorized for envelope domain	`example.com TXT`	No
DKIM	Message signed by domain, content unmodified	`selector._domainkey.example.com TXT`	Usually yes
DMARC	SPF/DKIM align with visible From; policy enforcement	`_dmarc.example.com TXT`	Via DKIM & ARC

What's Next:

SPF, DKIM, and DMARC authenticate email senders. But they don't protect message content from being read by adversaries. The final page covers Email Encryption, including:

S/MIME (Secure/Multipurpose Internet Mail Extensions)
PGP/GPG (Pretty Good Privacy)
Transport Layer Security (TLS for SMTP)

These technologies ensure email content confidentiality in addition to sender authentication.

Page Complete