Skip to content

DMARC (Domain-based Message Authentication)

DMARC builds on SPF and DKIM to provide policy enforcement and reporting for email authentication.

How DMARC Works

The Problem

SPF and DKIM each provide authentication, but:

  • Neither enforces what happens when authentication fails
  • Neither aligns with the visible "From" header
  • Neither provides visibility into authentication results

The Solution

DMARC:

  1. Aligns SPF and DKIM with the From header domain
  2. Enforces policy when authentication fails
  3. Reports authentication results back to domain owners

DMARC Record Format

DMARC records are TXT records at:

_dmarc.example.com

Example record:

v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com; adkim=r; aspf=r; pct=100

Required Tags

TagDescriptionValues
vVersionDMARC1 (required, must be first)
pPolicynone, quarantine, reject

Optional Tags

TagDescriptionDefault
ruaAggregate report addressNone
rufForensic report addressNone
adkimDKIM alignment moder (relaxed)
aspfSPF alignment moder (relaxed)
pctPercentage to apply policy100
spSubdomain policySame as p
foFailure reporting options0

Policies

p=none (Monitor)

v=DMARC1; p=none; rua=mailto:dmarc@example.com
  • No action taken on failures
  • Receive reports to understand traffic
  • Use case: Initial deployment, monitoring

p=quarantine (Soft Enforcement)

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com
  • Failed emails sent to spam/junk
  • Some protection against spoofing
  • Use case: Testing before full enforcement

p=reject (Full Enforcement)

v=DMARC1; p=reject; rua=mailto:dmarc@example.com
  • Failed emails rejected entirely
  • Maximum protection against spoofing
  • Use case: Production, after verification

Alignment

DMARC requires alignment between authentication and the From header.

SPF Alignment

The envelope sender (MAIL FROM) domain must align with the From header domain.

Relaxed (aspf=r):

  • Organizational domain match
  • bounce.example.com aligns with example.com

Strict (aspf=s):

  • Exact domain match required

DKIM Alignment

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

Relaxed (adkim=r):

  • Organizational domain match
  • d=mail.example.com aligns with From: @example.com

Strict (adkim=s):

  • Exact domain match required

Alignment Diagram

Email From: user@example.com

    ┌───────────┴───────────┐
    ▼                       ▼
SPF (Envelope)          DKIM (d=)
bounce.example.com      mail.example.com
    │                       │
    ▼                       ▼
Relaxed: ✅ PASS        Relaxed: ✅ PASS
(same org domain)       (same org domain)
    │                       │
    ▼                       ▼
Strict: ❌ FAIL         Strict: ❌ FAIL
(not exact match)       (not exact match)

DMARC Reports

Aggregate Reports (RUA)

Daily summaries from email receivers:

Contents:

  • Reporting organization
  • Your published policy
  • Date range
  • Source IPs that sent email
  • Authentication results (SPF, DKIM, DMARC)
  • Volume per source

Format: XML (usually compressed)

Example configuration:

rua=mailto:dmarc@example.com

Multiple addresses:

rua=mailto:dmarc@example.com,mailto:reports@mailshield.app

Forensic Reports (RUF)

Individual failure reports:

Contents:

  • Full email headers
  • Authentication failure details
  • Message information

Note: Many providers no longer send forensic reports due to privacy concerns.

Example configuration:

ruf=mailto:forensic@example.com

Failure Options (fo)

Control when forensic reports are sent:

ValueMeaning
0Generate if all mechanisms fail (default)
1Generate if any mechanism fails
dGenerate if DKIM fails
sGenerate if SPF fails

Multiple options: fo=1:d:s

Implementation Strategy

Phase 1: Monitor

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

Duration: 2-4 weeks

Actions:

  • Monitor reports
  • Identify all legitimate senders
  • Add missing SPF/DKIM configurations

Phase 2: Quarantine

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

Progression:

  1. Start with pct=10 (10% of failures quarantined)
  2. Increase to pct=25, pct=50, pct=75
  3. Finally pct=100

Duration: 2-4 weeks per increment

Phase 3: Reject

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

Progression:

  1. Start with pct=10
  2. Gradually increase to pct=100

Duration: 2-4 weeks per increment

Subdomain Policy

The sp tag controls policy for subdomains:

v=DMARC1; p=reject; sp=none; rua=mailto:dmarc@example.com
  • p=reject for example.com
  • sp=none for sub.example.com

Use cases:

  • Different security requirements for subdomains
  • Gradual rollout across organization

The pct Tag

Apply policy to a percentage of failing messages:

v=DMARC1; p=reject; pct=25; rua=mailto:dmarc@example.com
  • 25% of failures → rejected
  • 75% of failures → delivered (with p=none behavior)

Use case: Gradual enforcement rollout

Common Issues

No Reports Received

Causes:

  • DMARC record doesn't have rua
  • Report address incorrect
  • DNS propagation incomplete

Solutions:

  • Verify rua tag is present
  • Check for typos in email address
  • Wait 24-48 hours after DNS change

Legitimate Email Failing

Causes:

  • SPF not configured for sender
  • DKIM not configured for sender
  • Alignment issues

Solutions:

  • Add sender to SPF record
  • Configure DKIM signing
  • Check alignment modes

Third-Party Senders

Services sending on your behalf need configuration:

  1. SaaS platforms - Add to SPF, configure DKIM
  2. Marketing tools - Usually provide DKIM, add to SPF
  3. CRM systems - Check their email setup guides

Email Forwarding

Forwarding can break authentication:

  • SPF fails (forwarding server IP not in SPF)
  • DKIM may survive if not modified

Solution: Rely on DKIM with relaxed alignment

DMARC and Mailing Lists

Mailing lists modify emails, breaking authentication:

Problem:

  • List adds headers/footers → DKIM fails
  • List sends from its server → SPF fails

Solutions:

  • Lists implementing ARC (Authenticated Received Chain)
  • Relaxed alignment settings
  • Accept some failures from known lists

Best Practices

Do

✅ Start with p=none to understand traffic
✅ Configure reporting (rua)
✅ Analyze reports before enforcing
✅ Use gradual rollout with pct
✅ Progress to p=reject for full protection

Don't

❌ Start with p=reject without monitoring
❌ Ignore third-party senders
❌ Use strict alignment without testing
❌ Skip the monitoring phase

Example Records

Minimal (Monitoring)

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

Standard (Enforcing)

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

Advanced

v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com; adkim=r; aspf=r; pct=100; fo=1

Using MailShield for DMARC

MailShield helps you:

  1. Monitor DMARC records - Validation and best practices
  2. Receive reports - Use MailShield's reporting address
  3. Analyze reports - Visual breakdowns of authentication
  4. Discover senders - Identify legitimate and suspicious sources
  5. Track progress - Monitor improvement toward enforcement

Secure your email infrastructure with confidence.