Technical

DMARC Policy Implementation: From Monitoring to Enforcement

Alex Chen

December 30, 2025

14 min read

A practical guide to implementing DMARC (Domain-based Message Authentication, Reporting & Conformance) for your domain.

Introduction

DMARC (Domain-based Message Authentication, Reporting & Conformance) is the final piece of the email authentication puzzle. Building on SPF and DKIM, DMARC tells receiving servers what to do when authentication fails and provides visibility through aggregate reports.

Email Authentication Stack

┌─────────────────────────────────────────────────────────────┐
│                    INCOMING EMAIL                           │
│              From: user@example.com                         │
└─────────────────────────┬───────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────────┐
│                      SPF CHECK                              │
│    "Is the sending IP authorized for example.com?"         │
│                                                             │
│    ┌─────────┐     ┌─────────┐     ┌─────────┐             │
│    │  Pass   │     │  Fail   │     │SoftFail │             │
│    └────┬────┘     └────┬────┘     └────┬────┘             │
└─────────┼───────────────┼───────────────┼───────────────────┘
          │               │               │
          ▼               ▼               ▼
┌─────────────────────────────────────────────────────────────┐
│                     DKIM CHECK                              │
│    "Is the email signature valid for example.com?"          │
│                                                             │
│    ┌─────────┐     ┌─────────┐     ┌─────────┐             │
│    │  Pass   │     │  Fail   │     │  None   │             │
│    └────┬────┘     └────┬────┘     └────┬────┘             │
└─────────┼───────────────┼───────────────┼───────────────────┘
          │               │               │
          ▼               ▼               ▼
┌─────────────────────────────────────────────────────────────┐
│                    DMARC CHECK                              │
│    "Do SPF/DKIM results align with the From domain?"        │
│    "What policy should be applied?"                         │
│                                                             │
│    Policy: p=none     Policy: p=quarantine   Policy: p=reject│
│    ┌─────────┐        ┌─────────┐           ┌─────────┐    │
│    │ Monitor │        │  Spam   │           │ Reject  │    │
│    │  Only   │        │ Folder  │           │ Email   │    │
│    └─────────┘        └─────────┘           └─────────┘    │
└─────────────────────────────────────────────────────────────┘

Understanding DMARC

What DMARC Does

1**Links SPF/DKIM to the visible From address**

2**Specifies a policy** for handling failures

3**Requests reports** about authentication results

DMARC Alignment

DMARC requires "alignment" between authenticated identifiers and the visible From header:

Check	Identifier	Must Match
SPF Alignment	Envelope From domain	Header From domain
DKIM Alignment	d= domain in signature	Header From domain

Alignment Modes

•Strict (s): Exact domain match required

•Relaxed (r): Organizational domain match (subdomains OK)

From: news@mail.example.com

Relaxed: mail.example.com aligns with example.com ✓
Strict: mail.example.com does NOT align with example.com ✗

DMARC Record Syntax

DMARC records are published as TXT records at _dmarc.example.com:

bash

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

Required Tags

Tag	Description	Values
`v`	Version (required first)	DMARC1
`p`	Policy for domain	none, quarantine, reject

Optional Tags

Tag	Description	Default	Example
`sp`	Subdomain policy	Same as p	`sp=reject`
`rua`	Aggregate report URI	None	`rua=mailto:dmarc@example.com`
`ruf`	Forensic report URI	None	`ruf=mailto:forensic@example.com`
`pct`	Percentage to apply policy	100	`pct=25`
`adkim`	DKIM alignment mode	r	`adkim=s`
`aspf`	SPF alignment mode	r	`aspf=s`
`fo`	Forensic report options	0	`fo=1`
`ri`	Report interval (seconds)	86400	`ri=3600`

DMARC Policy Levels

p=none (Monitor Only)

dns

v=DMARC1; p=none; rua=mailto:dmarc@example.com

•Action: No enforcement

•Use case: Initial deployment, gather data

•Risk: Low

p=quarantine

dns

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com

•Action: Move failures to spam

•Use case: Intermediate enforcement

•Risk: Medium

p=reject

dns

v=DMARC1; p=reject; rua=mailto:dmarc@example.com

•Action: Reject failures outright

•Use case: Full protection

•Risk: High (may block legitimate email)

Implementation Roadmap

Phase 1: Discovery (Week 1-2)

Deploy monitoring-only policy:

dns

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

Goals:

•Identify all legitimate email sources

•Discover shadow IT sending email

•Establish baseline

Phase 2: Analysis (Week 3-4)

Review aggregate reports to identify:

•Authorized senders passing authentication

•Authorized senders failing (need SPF/DKIM fix)

•Unauthorized senders (spoofing attempts)

Phase 3: Remediation (Week 5-8)

Fix authentication for all legitimate sources:

dns

# Add missing services to SPF
v=spf1 mx include:_spf.google.com include:sendgrid.net -all

# Ensure DKIM is configured for all services

Phase 4: Gradual Enforcement (Week 9-12)

Slowly increase enforcement:

dns

# Week 9: 10% quarantine
v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@example.com

# Week 10: 50% quarantine
v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc@example.com

# Week 11: 100% quarantine
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com

# Week 12: Start reject rollout
v=DMARC1; p=reject; pct=10; rua=mailto:dmarc@example.com

Phase 5: Full Enforcement

dns

v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com

DMARC Reports

Aggregate Reports (RUA)

XML reports sent daily containing:

•Sending IP addresses

•Authentication results

•Message counts

•Policy applied

Sample Report Structure:

xml

<?xml version="1.0"?>
<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <date_range>
      <begin>1234567890</begin>
      <end>1234654290</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <p>reject</p>
  </policy_published>
  <record>
    <row>
      <source_ip>192.168.1.100</source_ip>
      <count>1234</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
  </record>
</feedback>

Forensic Reports (RUF)

Individual failure reports containing:

•Full email headers

•Authentication details

•Failure reasons

Note: Many receivers don't send forensic reports due to privacy concerns.

Advanced DMARC Configurations

Subdomain Policy

dns

v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc@example.com

•Main domain: reject

•Subdomains: quarantine

Strict Alignment

dns

v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:dmarc@example.com

Requires exact domain match, no subdomain flexibility.

Multiple Report Destinations

dns

v=DMARC1; p=reject; rua=mailto:dmarc@example.com,mailto:reports@thirdparty.com

External Report Authorization

To receive reports at a different domain, publish authorization record:

dns

# At the receiving domain
example.com._report._dmarc.thirdparty.com    TXT    "v=DMARC1"

Common DMARC Mistakes

1. Starting with p=reject

Problem: Blocks legitimate email before identifying all senders

Solution: Always start with p=none

2. Ignoring Aggregate Reports

Problem: Flying blind, missing unauthorized senders

Solution: Use a DMARC analytics service or regularly review reports

3. Forgetting Subdomains

Problem: Attackers spoof subdomains (marketing.example.com)

Solution: Set explicit subdomain policy (sp=)

4. Not Configuring SPF/DKIM First

Problem: DMARC fails without underlying authentication

Solution: Verify SPF and DKIM pass before enabling DMARC enforcement

DMARC and Email Forwarding

Email forwarding breaks SPF (different server sends), but DKIM survives if the message isn't modified.

Best Practice: Ensure DKIM is configured for DMARC alignment when forwarding is common.

DMARC Report Analysis Tools

Free Options

•Google Postmaster Tools

•dmarcian (free tier)

•DMARC Analyzer (free tier)

Enterprise Solutions

•Valimail

•Agari

•Proofpoint

•Dmarcian

Troubleshooting DMARC

Check Your Record

bash

dig TXT _dmarc.example.com +short

Common Issues

Issue	Cause	Solution
No reports	Wrong email	Verify rua address
All failing	No SPF/DKIM	Configure authentication
Subdomain fails	No sp= tag	Add subdomain policy
Partial failures	Misconfigured service	Fix SPF/DKIM for that service

Conclusion

DMARC is essential for:

•Preventing email spoofing: of your domain

•Gaining visibility: into email authentication

•Protecting your brand: from phishing attacks

•Improving deliverability: with major email providers

The key is gradual implementation:

1Start with monitoring (p=none)

2Fix authentication issues

3Gradually enforce (quarantine → reject)

4Continuously monitor reports

With proper DMARC implementation, you can be confident that only authorized servers send email as your domain.