DMARC - Email Authentication Policy

Define how to handle emails that fail authentication.

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the policy layer that unifies SPF and DKIM. It allows defining what receiving servers should do with emails that fail authentication: accept them, quarantine them (spam), or reject them.

Without DMARC, even with SPF and DKIM configured, receiving servers decide for themselves how to handle suspicious emails. DMARC lets you express your policy and receive reports on spoofing attempts against your domain.

DMARC also solves the alignment problem: it verifies that the visible domain in the From header matches the domain authenticated by SPF or DKIM, closing a vulnerability that attackers exploited.

How DMARC Works

DMARC adds a policy layer to email authentication:

Alignment: DMARC verifies that the From header domain aligns with the one authenticated by SPF or DKIM. Blocks visible From spoofing.
Policy (p=): none = monitoring only, quarantine = send to spam, reject = reject. Progress from none to reject over time.
Reports (rua=): DMARC sends aggregate XML reports listing all processed emails. Essential for identifying forgotten legitimate sources.
Percentage (pct=): Allows applying the policy to only a percentage of emails (pct=10 = 10%). Useful for gradual deployment.

Why DMARC is Indispensable

DMARC completes the email authentication trilogy:

Explicit policy: You decide how to handle unauthenticated emails, not receiving servers. Total control over your email policy.
Visibility: DMARC reports reveal who sends emails for your domain - legitimately or fraudulently. Discover forgotten sources.
Complete protection: DMARC alignment closes the forged From vulnerability. Attackers can no longer spoof your visible domain.
Growing requirement: Google, Yahoo and others require DMARC for large senders. Without DMARC, your emails risk being blocked.

How to Configure DMARC

Deploy DMARC gradually:

Prepare SPF and DKIM: DMARC requires working SPF and/or DKIM. Verify both are correctly configured and tested.
Start with p=none: Create _dmarc.example.com with p=none and rua= to your email. Collect reports for a few weeks.
Analyze reports: XML reports show all email sources. Identify legitimate sources not covered by SPF/DKIM and fix.
Progress to reject: Once all legitimate sources are identified, move to p=quarantine then p=reject. Use pct= for gradual transition.

DMARC Configuration Examples

Here are DMARC policy examples:

; DMARC monitoring only (starting)
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]"

; DMARC quarantine (intermediate)
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=25"

; DMARC reject (maximum protection)
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]"

; DMARC with complete options
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; sp=quarantine; adkim=s; aspf=s; rua=mailto:[email protected]; ri=86400"

; Verification
$ dig _dmarc.example.com TXT +short
"v=DMARC1; p=reject; rua=mailto:[email protected]"

v=DMARC1 is mandatory. p= defines policy (none/quarantine/reject). rua= receives aggregate reports. sp= defines subdomain policy. adkim/aspf define strict or relaxed alignment.

DMARC Best Practices

Deploy DMARC effectively:

Gradual progression: none → quarantine → reject over several months. Analyze reports at each step to avoid blocking legitimate emails.
Analyze reports: Use tools like dmarcian, Postmark DMARC or free services to automatically analyze XML reports.
Subdomains: Define sp= for subdomains. By default, they inherit p=. You can be stricter or more lenient depending on cases.
Monitor continuously: Even after p=reject, continue monitoring reports and DNS records with MoniTao.

DMARC Checklist

SPF configured and functional
DKIM configured and functional
_dmarc.domain.com record created
rua= address configured for reports
Reports analyzed regularly
Progression planned toward p=reject

Frequently Asked Questions - DMARC

Can I enable DMARC without SPF or DKIM?

Technically yes, but DMARC will always fail because it requires SPF OR DKIM to pass AND align. Without either, DMARC makes no sense.

What do DMARC reports mean?

Aggregate reports (rua) list all IPs that sent emails for your domain with SPF/DKIM/DMARC results. Forensic reports (ruf) contain samples of failed emails.

Will p=reject block my legitimate emails?

Only if you forgot sources in SPF or DKIM isn't configured for a service. Hence the importance of starting with p=none and analyzing reports.

Are subdomains covered?

By default, subdomains inherit the parent domain policy. Use sp= for a different policy, or create specific DMARC records for each subdomain.

How long before p=reject?

Typically 2-3 months minimum. Move from p=none to p=quarantine after verifying reports, then to p=reject when confident all sources are covered.

What if I receive too many reports?

Use a DMARC analysis service that aggregates and visualizes reports. ri=86400 (1 per day) instead of ri=3600 also reduces volume.

Complete Your Authentication with DMARC

DMARC is the final piece of the email authentication puzzle. It transforms SPF and DKIM from simple checks into an actionable policy, and gives you visibility on all attempts to use your domain.

Deploy DMARC gradually, analyze your reports, and aim for p=reject for maximum protection. Monitor your DNS records with MoniTao to ensure your policy stays active.

Useful Links

Ready to Sleep Soundly?

Start free, no credit card required.

Create My Account See pricing