DMARC Setup Guide

How DMARC works

DMARC builds on SPF and DKIM. When a receiving server gets an email from your domain, it:

1. Checks SPF — is the sending server authorized?
2. Checks DKIM — is the email signature valid?
3. Checks alignment — does the SPF or DKIM domain match the From header?
4. Applies your DMARC policy — none, quarantine, or reject
5. Sends you a report about the result

DMARC passes if either SPF or DKIM passes with alignment. It does not require both.

Step 1: Verify SPF and DKIM are working

Before adding DMARC, confirm your existing authentication is passing:

# Check SPF
dig TXT yourapp.com +short | grep spf

# Check DKIM
dig TXT relaypost._domainkey.yourapp.com +short

Send a test email and verify the headers show spf=pass and dkim=pass. If either is failing, fix it first.

→ SPF setup guide · DKIM setup guide

Step 2: Create the DMARC record

Add a TXT record at _dmarc.yourapp.com:

This starts in monitoring mode (p=none). No email will be blocked — you are just collecting data.

DMARC tag reference

*Technically optional, but strongly recommended. Without rua, you get no visibility into authentication results.

Step 3: Monitor reports (2-4 weeks)

Receiving servers will start sending aggregate reports to your rua address. These are XML files that show:

• Which IP addresses sent email using your domain
• Whether SPF and DKIM passed or failed for each source
• What DMARC policy was applied
• How many emails were sent from each source

Use a DMARC report analyzer (like dmarcian, Postmark's DMARC tool, or EasyDMARC) to parse the XML into readable dashboards. Look for:

• Legitimate senders that are failing SPF or DKIM — fix their authentication
• Unknown senders — these may be spoofing attempts or forgotten services
• High failure rates from specific IPs — investigate before tightening policy

Step 4: Tighten the policy

Once all legitimate email passes authentication, progressively tighten your DMARC policy:

# Phase 1: Monitoring (start here)
v=DMARC1; p=none; rua=mailto:[email protected]; pct=100

# Phase 2: Quarantine 10% (test the waters)
v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=10

# Phase 3: Quarantine 100%
v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100

# Phase 4: Reject (full enforcement)
v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100

# Phase 5: Reject + subdomain protection
v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected]; pct=100

Wait 1-2 weeks between each phase. Monitor reports at each stage to catch any issues before they affect delivery.

Common mistakes

• Jumping straight to p=reject — blocks legitimate email you forgot to authenticate
• Not setting up rua — you have no visibility into what is happening
• Forgetting subdomain policy — spoofers can use anything.yourapp.com if sp is not set
• Not fixing SPF/DKIM failures before tightening — legitimate email gets quarantined or rejected
• Ignoring DMARC reports — authentication can break when you add new services or change infrastructure

Verify your DMARC record

# Check DMARC record
dig TXT _dmarc.yourapp.com +short

# Expected output:
"v=DMARC1; p=none; rua=mailto:[email protected]; pct=100"

Related guides

• Email Authentication: SPF, DKIM & DMARC
• SPF Record Setup Guide
• DKIM Setup Guide
• Email Deliverability Guide