What is DMARC? Setup Guide & Policy Explained

Updated February 6, 2026

DMARC is the policy layer that ties SPF and DKIM together. While SPF specifies who can send and DKIM proves message integrity, DMARC answers two critical questions that neither SPF nor DKIM addresses alone: what should receivers do when authentication fails, and how can the domain owner find out about it?

Without DMARC, receiving servers make their own decisions about unauthenticated email. Some might reject it, others might deliver it to spam, and others might accept it outright. DMARC gives you, the domain owner, control over that decision.

How DMARC Works

1. You publish a DMARC policy as a TXT record at _dmarc.yourdomain.com.
2. When a receiving server gets an email claiming to be from your domain, it checks SPF and DKIM.
3. DMARC then verifies alignment — the domain in the From header must match the domain that passed SPF or DKIM.
4. If both SPF and DKIM fail alignment, the receiver applies your DMARC policy (none, quarantine, or reject).
5. The receiver sends you reports about the authentication results.

DMARC Record Syntax

A DMARC record is a DNS TXT record published at _dmarc.yourdomain.com. Here is a fully-featured example:

v=DMARC1; p=reject; sp=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected]; adkim=r; aspf=r; pct=100; fo=1

Tag Reference

Policy Levels

p=none (Monitor)

v=DMARC1; p=none; rua=mailto:[email protected]

No action is taken on failing email. This is purely a monitoring mode — you receive reports about who is sending email as your domain and whether authentication passes. Always start here.

p=quarantine (Spam)

v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100

Emails that fail DMARC are sent to the recipient's spam or junk folder. This is the intermediate step that catches unauthorized email without silently discarding it.

p=reject (Block)

v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100

Emails that fail DMARC are blocked entirely — the receiving server rejects them during the SMTP transaction. This is the strongest protection against spoofing and the goal of every DMARC deployment.

Alignment: Strict vs. Relaxed

Alignment is the mechanism that prevents attackers from bypassing DMARC by authenticating with a different domain than the one in the From header.

Relaxed Alignment (Default)

The authenticated domain and the From header domain must share the same organizational domain. For example:

• From: [email protected] + SPF passes for mail.example.com = aligned (same organizational domain)
• From: [email protected] + DKIM d=marketing.example.com = aligned

Strict Alignment

The authenticated domain must exactly match the From header domain:

• From: [email protected] + SPF passes for mail.example.com = not aligned (different subdomain)
• From: [email protected] + DKIM d=example.com = aligned (exact match)

Relaxed alignment is recommended for most organizations because many legitimate email services send from subdomains.

DMARC Reporting

Aggregate Reports (rua)

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

• Which IPs sent email claiming to be from your domain
• How many messages were sent
• SPF and DKIM pass/fail results
• What policy was applied

These reports are essential for understanding your email ecosystem. Use a DMARC report analyzer to parse and visualize them — raw XML is difficult to read.

Forensic Reports (ruf)

Forensic reports contain details about individual messages that failed DMARC. They are useful for debugging but many large email providers do not send them due to privacy concerns.

Deployment Strategy

A safe DMARC rollout follows this sequence:

Phase 1: Monitor (2-4 Weeks)

v=DMARC1; p=none; rua=mailto:[email protected]

• Publish a p=none record with rua reporting.
• Collect and analyze aggregate reports.
• Identify all legitimate email sources (marketing platforms, CRM, support tools, etc.).
• Ensure each source has proper SPF and DKIM configuration.

Phase 2: Quarantine (2-4 Weeks)

v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]

• Start with pct=25 to apply the policy to only 25% of failing messages.
• Monitor reports for legitimate email being quarantined.
• Fix any issues and gradually increase pct to 50, then 75, then 100.

Phase 3: Reject

v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100

• Move to p=reject once you are confident all legitimate senders pass authentication.
• Continue monitoring reports — new services may be added over time.

Subdomain Policy

The sp tag lets you set a separate policy for subdomains. This is useful if you want strict enforcement on your main domain but need flexibility for subdomains:

v=DMARC1; p=reject; sp=quarantine; rua=mailto:[email protected]

If sp is not specified, subdomains inherit the p policy.

Common Mistakes

No rua Tag

Publishing a DMARC record without rua means you get no reports. You're flying blind — you won't know if legitimate email is failing or if attackers are spoofing your domain.

Jumping to p=reject

Deploying p=reject without monitoring first is the most common cause of self-inflicted email outages. Third-party services, marketing tools, and transactional email platforms all need proper SPF and DKIM setup first.

Ignoring Subdomains

If your main domain has p=reject but you haven't set sp, subdomains inherit the reject policy. This is actually good. But if you set sp=none to avoid issues, attackers can spoof any subdomain.

DMARC Without SPF or DKIM

DMARC requires SPF or DKIM to function. A DMARC record without SPF and DKIM in place will result in all email failing alignment. Make sure the underlying authentication mechanisms are configured first.

Checking Your DMARC Setup

You can inspect your DMARC record manually:

dig TXT _dmarc.example.com +short

Or use DNS Kit's Email Health Checker for an instant, comprehensive analysis of your DMARC configuration alongside SPF and DKIM.

For a complete understanding of how DMARC works with SPF and DKIM, read our email authentication overview. To learn more about the underlying protocols, see our guides on SPF records and DKIM.