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

Tag	Description	Values
v	Version	DMARC1 (required, must be first)
p	Policy	none, quarantine, reject

Optional Tags

Tag	Description	Default
rua	Aggregate report address	None
ruf	Forensic report address	None
adkim	DKIM alignment mode	r (relaxed)
aspf	SPF alignment mode	r (relaxed)
pct	Percentage of failing mail the policy applies to	100
sp	Subdomain policy	Same as p
fo	Failure reporting options	0

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:abc123@reports.mailshield.app

To send reports to MailShield, use your domain's Reporting address (shown on the domain's Overview page in MailShield) in place of abc123@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

Forensic reports can contain headers and content of the failed messages, including personal data. If you point ruf at your MailShield Reporting address, MailShield stores the reports it receives, but doesn't show them in the dashboard.

Failure Options (fo)

Control when forensic reports are sent:

Value	Meaning
0	Generate if all mechanisms fail (default)
1	Generate if any mechanism fails
d	Generate if DKIM fails
s	Generate if SPF fails

Multiple options: fo=1:d:s

Implementation Strategy

Move to enforcement in three phases:

1. Monitor with p=none and a rua address until you know every service that sends as your domain, and they all pass.
2. Quarantine with p=quarantine, optionally raising pct in steps.
3. Reject with p=reject.

The DMARC Enforcement Roadmap covers each phase, how long to stay in it and when to move on.

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

pct applies the policy to a share of the messages that fail DMARC. The rest get the next weaker policy, not a free pass (RFC 7489, section 6.6.4):

Record	Failing messages in the sample	The rest of the failing messages
p=quarantine; pct=25	25% quarantined	75% handled as p=none (delivered normally)
p=reject; pct=25	25% rejected	75% quarantined

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

Use case: a gradual rollout. Remove pct (or set it to 100) once you're confident.

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

Multiple DMARC Records

If _dmarc.example.com has more than one TXT record starting with v=DMARC1, receivers ignore all of them and no DMARC policy applies (RFC 7489, section 6.6.3). Keep exactly one record, and add extra report addresses to its rua tag.

Email Forwarding

Forwarding can break authentication:

• SPF fails, because the forwarding server's IP isn't in your SPF record
• DKIM usually survives, unless the forwarder changes the message

Solution: sign all mail with an aligned DKIM signature, so DMARC passes on DKIM alone. The alignment mode doesn't fix forwarding: relaxed alignment doesn't make the forwarder's IP pass SPF. Don't add the forwarding server to your SPF record either. When it's a mailbox provider such as Gmail or Outlook, that would let every one of its users pass SPF as your domain.

MailShield recognizes mail forwarded from mailbox providers such as Gmail and Outlook, marks it as Forwarded in your reports, and leaves it out of pass rates, policy readiness and failure alerts. See Forwarded Mail.

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:

• Many lists rewrite the From address to the list's own domain, so your DMARC policy no longer applies to the list's copy
• Lists and receivers that support ARC (Authenticated Received Chain) can pass on the original authentication results
• Expect some failures from mailing lists and forwarders in your reports. Mail forwarded from mailbox providers such as Gmail is shown as forwarded instead

Best Practices

Do

✅ Start with p=none to understand traffic
✅ Configure reporting (rua)
✅ Analyze reports before enforcing
✅ Move to enforcement gradually
✅ 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 every 2 hours, and alerts when the policy changes
2. Receive reports: put your domain's Reporting address in rua
3. Analyze reports: see which sources pass and fail under Reports
4. Discover senders: the Sending Sources table groups mail by sending IP
5. Track progress: Reports → DMARC Progression tells you when a domain is ready for a stricter policy