1. Library
  2. Computer Networks
  3. Email Protocols
  4. Authentication

Updated 8 hours ago

DMARC is a gun. p=none is pointing it at the floor. p=quarantine is pointing it at the target. p=reject is pulling the trigger.

You don't pull the trigger until you're certain you know where all your legitimate mail is coming from.

This guide walks through a phased deployment—from monitoring through enforcement—designed to get you to maximum protection without blocking legitimate email along the way. The timeline feels slow. That's intentional. The alternative is discovering, after you've deployed p=reject, that your marketing platform wasn't properly authenticated and three weeks of customer communications vanished into the void.

Before You Start

DMARC builds on SPF and DKIM. Without them, DMARC has nothing to evaluate.

SPF must be configured. Your domain needs an SPF record authorizing your legitimate mail sources.

DKIM must be deployed. Your mail servers should be signing outbound messages.

You need somewhere to receive reports. DMARC generates daily XML reports that can be large. Prepare a dedicated address.

If SPF and DKIM aren't working, fix them first. Deploying DMARC without authentication infrastructure is like installing a burglar alarm with no sensors.

Phase 1: Monitor Everything

Start with a policy that watches but doesn't act:

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

Publish this as a TXT record at _dmarc.example.com:

FieldValue
TypeTXT
Name_dmarc
Valuev=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
TTL3600

Verify it's published:

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

Now wait. Reports arrive daily, typically within 24-48 hours. Major providers—Google, Microsoft, Yahoo—send them reliably.

Run this phase for 2-4 weeks. That's not arbitrary. You need enough time to capture all your mail sources: the daily newsletters, the weekly invoices, the monthly reports, the quarterly statements. Miss one, and you'll discover it the hard way after tightening policy.

Phase 2: Understand Your Traffic

Aggregate reports are XML files containing authentication results for every message claiming to be from your domain. Manually parsing them is miserable. Use a tool:

Free options: Postmark DMARC Digests, Google's DMARC Analyzer

Commercial options: dmarcian, Valimail, OnDMARC, EasyDMARC, Mimecast

These services parse the XML and show you dashboards: pass rates over time, failing sources with identification, volume trends.

What you're looking for:

Legitimate sources passing authentication:

Source: 203.0.113.10 (your mail server)
Messages: 1,247
SPF: pass, aligned | DKIM: pass, aligned
→ Working correctly. No action needed.

Legitimate sources failing authentication:

Source: 198.51.100.25 (marketing platform)
Messages: 3,456
SPF: fail | DKIM: pass, aligned
→ Legitimate but needs SPF configuration.

Unknown sources failing everything:

Source: 192.0.2.50 (unknown)
Messages: 87
SPF: fail | DKIM: fail
→ Either spoofing or a forgotten legitimate source. Investigate.

The goal: identify every legitimate source and understand why any are failing.

Phase 3: Fix What's Broken

For each legitimate source that's failing:

SPF failures: Add the source to your SPF record.

# Before
v=spf1 mx -all

# After (adding marketing platform)
v=spf1 mx include:sendgrid.net -all

DKIM failures: Configure the service to sign with your domain. This typically means:

  1. The service provides DKIM public keys
  2. You publish those keys in your DNS
  3. The service signs messages with d=yourdomain.com

Third-party services: Contact each provider. They do this constantly—they'll have documentation for setting up DKIM signing and SPF includes.

Subdomain delegation: For services that resist proper configuration, consider delegating a subdomain entirely. Let them handle newsletter.example.com with their own DMARC record.

Target: >95% pass rate for legitimate mail before moving forward. Anything less means you haven't found all your sources.

Phase 4: Begin Enforcement Gradually

Once legitimate mail passes consistently, start enforcing—but gently:

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

The pct=10 means: apply this policy to only 10% of failing messages. The other 90% are still delivered normally.

This is your safety net. If you missed a legitimate source, only 10% of its mail gets quarantined. You'll notice the problem before it becomes catastrophic.

Monitor for problems:

  • User complaints about missing email
  • Unexpected failures in reports
  • Legitimate messages appearing in spam folders

If nothing breaks, increase gradually:

WeekPolicy
1pct=10
2pct=25
3pct=50
4pct=75
5pct=100 (or remove pct=)

Once you're at 100% quarantine with no issues:

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

Run quarantine for 2-4 weeks before considering reject. Quarantine is recoverable—messages go to spam folders where users can find them. Reject is final.

Phase 5: Full Protection

When you're confident all legitimate mail passes:

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

Messages failing DMARC are now rejected outright. They don't reach spam folders. They don't reach the recipient at all.

If you want extra caution, start reject at a low percentage too:

v=DMARC1; p=reject; pct=10; rua=mailto:dmarc-reports@example.com

Then ramp up over weeks until you reach full reject.

This is the destination: spoofed emails claiming to be from your domain are blocked before they can do damage.

Advanced Options

Subdomain policy: Treat subdomains differently than the main domain:

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

Main domain gets p=reject, subdomains get sp=quarantine. Useful when you control the main domain tightly but subdomains are delegated to services.

Strict alignment: Require exact domain matches:

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

The default is relaxed alignment (aspf=r; adkim=r), which allows subdomains to align. Strict (s) requires exact matches.

Forensic reports: Get detailed failure information:

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

Warning: Many receivers don't send forensic reports due to privacy concerns. Don't rely on them.

Multiple report destinations:

rua=mailto:dmarc@example.com,mailto:dmarc@analyzer-vendor.com

Send to both your address and an analysis service.

Troubleshooting

No reports arriving:

  • Verify DNS record with dig _dmarc.example.com TXT
  • Check spam folders—reports often trigger filters
  • Confirm the rua= address can receive mail

Legitimate mail being quarantined or rejected:

  • Review aggregate reports to identify the failing source
  • Configure SPF/DKIM for that source
  • Contact the service provider—this is a common request

High failure rates after deployment:

  • Could be spoofing attempts (good—DMARC is working)
  • Could be forgotten legitimate sources (investigate)
  • Could be misconfigured third-party services (fix the configuration)

Ongoing Maintenance

DMARC isn't set-and-forget:

Monthly: Review reports for new failures, spoofing attempts, authentication health.

When adding services: Configure SPF/DKIM before the service starts sending, verify authentication in reports, document the change.

Annually: Audit all mail sources, verify SPF record accuracy, check DKIM key rotation, confirm policy is still appropriate.

Even at p=reject, keep receiving reports. New legitimate sources appear. Spoofing attempts happen. The reports tell you what's happening to mail claiming to be from your domain.

Frequently Asked Questions About DMARC Setup

Was this page helpful?

😔
🤨
😃