How to Set Up DMARC: Complete Guide

What Is DMARC?

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is an email authentication protocol defined in RFC 7489. It builds on top of SPF and DKIM to give domain owners control over what happens when an email fails authentication.

Without DMARC, a receiving mail server that sees a failed SPF or DKIM check has no guidance from the domain owner. It might deliver the message, flag it as spam, or reject it — the behavior varies by provider. DMARC solves this by letting you publish a policy that tells receivers exactly what to do with unauthenticated mail.

DMARC also introduces alignment — the requirement that the domain in the From: header matches the domain authenticated by SPF or DKIM. This closes the gap where an attacker could pass SPF using their own domain in the envelope sender while spoofing your domain in the visible From: header.

Beyond policy enforcement, DMARC provides a reporting mechanism. Receivers send aggregate reports back to you, showing which IPs are sending email using your domain and whether those messages pass or fail authentication. This visibility is critical for identifying unauthorized use of your domain.

How DMARC Works

When a receiving mail server gets a message claiming to be from @example.com, it performs these checks:

1. SPF check: Does the sending IP match the SPF record for the envelope sender domain (MAIL FROM)?
2. SPF alignment: Does the envelope sender domain match the From: header domain? DMARC requires this alignment — a passing SPF check alone is not enough.
3. DKIM check: Is there a valid DKIM signature on the message?
4. DKIM alignment: Does the d= domain in the DKIM signature match the From: header domain?
5. DMARC evaluation: If either SPF or DKIM passes and aligns, DMARC passes. If both fail alignment, the receiver applies the domain's DMARC policy.

Alignment Modes

DMARC supports two alignment modes for both SPF and DKIM:

Relaxed alignment is the default and is appropriate for most organizations. Use strict alignment only if you need to prevent subdomain spoofing and you are certain all your legitimate mail uses the exact From: domain.

Creating Your DMARC Record

A DMARC record is a DNS TXT record published at _dmarc.example.com. Here is the syntax breakdown:

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

* While rua is technically optional, a DMARC record without it provides no visibility. Always include it.

Minimal Starting Record

If you are setting up DMARC for the first time, start with monitoring only:

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

This tells receivers: "Don't change how you handle my mail, but send me reports about authentication results." This is the safe starting point — it cannot break your email delivery.

Publishing the Record

Add a TXT record in your DNS with:

• Host/Name: _dmarc (your DNS provider may auto-append the domain)
• Type: TXT
• Value: Your DMARC policy string
• TTL: 3600 (1 hour) is a good starting value

You can verify the record is published by querying DNS:

dig TXT _dmarc.example.com +short

DMARC Policy Progression

DMARC deployment is a phased process. Jumping straight to p=reject without monitoring will almost certainly break legitimate email from third-party services you have forgotten about.

Phase 1: Monitor (p=none)

Deploy p=none with rua reporting. Run this for 2–4 weeks minimum. During this phase:

• Review aggregate reports to identify all legitimate sending sources
• Ensure each source passes either SPF or DKIM with alignment
• Fix any sources that fail — add them to your SPF record or configure DKIM signing

Phase 2: Quarantine (p=quarantine)

Once all legitimate sources pass alignment, move to quarantine. You can use pct to roll out gradually:

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

Start at pct=10 (10% of failing messages get quarantined), monitor for a week, then increase to 25, 50, and finally 100. If you see legitimate mail being quarantined, investigate and fix before increasing.

Phase 3: Reject (p=reject)

After running quarantine at 100% with no issues for at least 2 weeks:

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

This is the strongest protection. Receivers will reject messages that fail DMARC alignment. This is the policy required by Google and Yahoo for bulk senders as of 2024.

Subdomain Policy

If you don't send email from subdomains, add sp=reject to prevent subdomain spoofing even while your main domain is still in monitoring:

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

Setting Up DMARC Reporting

Aggregate Reports (rua)

Aggregate reports are XML files sent daily by receiving mail servers. They contain:

• The sending IP address
• The number of messages from that IP
• SPF and DKIM authentication results
• DMARC alignment results
• The policy applied

These reports are essential for understanding who is sending email using your domain. The rua tag accepts multiple recipients separated by commas:

rua=mailto:dmarc@example.com,mailto:dmarc@thirdparty.com

Cross-Domain Reporting

If you want reports sent to an address at a different domain (e.g., a DMARC monitoring service), the receiving domain must authorize it by publishing a DNS record:

example.com._report._dmarc.monitoring-service.com TXT "v=DMARC1"

Without this authorization record, receivers will not send reports to the external address.

Forensic Reports (ruf)

Forensic reports contain details about individual failing messages, including headers. They are useful for investigating specific spoofing incidents but have privacy implications — many large providers (Gmail, Yahoo) do not send them. Use fo=1 to request reports when either SPF or DKIM fails (not just when both fail):

ruf=mailto:dmarc-forensic@example.com; fo=1

Common DMARC Mistakes

1. Skipping the Monitoring Phase

Deploying p=reject without first running p=none is the most common and most damaging mistake. Third-party services (marketing platforms, CRM systems, ticketing tools) often send email on your behalf. If they are not properly authenticated, p=reject will cause those messages to be silently dropped.

2. Misaligned Domains

SPF passes for the envelope sender domain, but DMARC checks alignment with the From: header domain. If your marketing tool sends with an envelope sender of bounce.mailservice.com but a From: of you@example.com, SPF passes for mailservice.com but fails DMARC alignment for example.com. The fix: ensure the service signs with DKIM using your domain, or configure the envelope sender to use your domain.

3. Missing SPF or DKIM

DMARC requires at least one of SPF or DKIM to pass with alignment. If you only have SPF and email is forwarded (which breaks SPF), DMARC will fail. Best practice: always configure both SPF and DKIM so that DMARC can pass via either mechanism.

4. Forgetting Subdomains

Without an sp tag, subdomains inherit the parent domain's policy. If your policy is p=none, attackers can spoof anything.example.com. If you don't send email from subdomains, add sp=reject immediately.

5. Not Monitoring Reports

Publishing a DMARC record and never reading the reports defeats the purpose. Aggregate reports reveal unauthorized use of your domain, misconfigured services, and authentication failures. Set up a dedicated mailbox or use a DMARC reporting service.

6. Multiple DMARC Records

A domain must have exactly one DMARC record. If you have two TXT records at _dmarc.example.com, the behavior is undefined — most receivers will treat it as no DMARC record at all. Check for duplicates before publishing.