What is a DMARC Policy?
DMARC (Domain-based Message Authentication, Reporting, and Conformance) is an email authentication protocol that builds on top of SPF and DKIM. While SPF and DKIM verify the technical origin and integrity of an email, DMARC adds two critical capabilities: it tells receiving servers what to do when authentication fails, and it provides a reporting mechanism so domain owners can monitor authentication results.
- Always start with
p=none(monitoring mode) and collect data before enforcing stricter policies - Include a
rua=reporting address to receive aggregate reports that reveal all senders using your domain - DMARC alignment (matching the From: domain with SPF/DKIM domains) is what makes DMARC effective
- Gradually upgrade enforcement from none to quarantine to reject over 4 to 12 weeks
- What is a DMARC Policy?
- DMARC Record Structure
- Policy: none (Monitoring Mode)
- Policy: quarantine (Soft Enforcement)
- Policy: reject (Full Enforcement)
- Subdomain Policy (sp=)
- DMARC Alignment (Strict vs Relaxed)
- DMARC Reporting (rua and ruf)
- Migration Path: none to quarantine to reject
- Generating Your DMARC Record
The DMARC policy is the instruction you publish in your DNS that tells receiving mail servers how to handle messages that fail both SPF and DKIM alignment checks. There are three policy levels: none, quarantine, and reject.
DMARC was created in 2012 by a consortium of industry leaders including Google, Microsoft, Yahoo, PayPal, Facebook, and several other major email senders and receivers. PayPal was one of the earliest and strongest advocates for the protocol, as phishing attacks impersonating PayPal were costing the company and its users millions of dollars annually.
DMARC Record Structure
A DMARC record is a DNS TXT record published at _dmarc.yourdomain.com. Here is a complete example with all common tags:
v=DMARC1; p=quarantine; sp=none; adkim=r; aspf=r; pct=100; rua=mailto:dmarc@yourdomain.com; ruf=mailto:forensic@yourdomain.com; fo=1Let's break down each tag:
| Tag | Required | Description |
|---|---|---|
v=DMARC1 |
Yes | Protocol version. Must be DMARC1. |
p= |
Yes | Policy for the domain: none, quarantine, or reject. |
sp= |
No | Policy for subdomains. Defaults to the value of p= if not specified. |
adkim= |
No | DKIM alignment mode: r (relaxed) or s (strict). Default is r. |
aspf= |
No | SPF alignment mode: r (relaxed) or s (strict). Default is r. |
pct= |
No | Percentage of messages subject to the policy (1-100). Default is 100. |
rua= |
No | Aggregate report destination (mailto: URI). Highly recommended. |
ruf= |
No | Forensic/failure report destination (mailto: URI). |
fo= |
No | Failure reporting options: 0 (both fail), 1 (either fails), d (DKIM fails), s (SPF fails). |
Policy: none (p=none) - Monitoring Mode
The p=none policy is monitoring mode. It tells receiving servers to deliver all messages normally regardless of authentication results, but to send aggregate reports back to the domain owner.
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.comWhen to use p=none:
- When you are first implementing DMARC and need to discover all sources sending email as your domain
- When you are not yet confident that all legitimate senders pass SPF and DKIM alignment
- As a starting point before moving to stricter policies
Tip: Always include a rua= tag when using p=none. Without reporting, monitoring mode provides no value. The aggregate reports will show you every source sending email as your domain, including any unauthorized senders you may not be aware of.
What p=none does NOT do:
- It does not prevent unauthorized senders from spoofing your domain
- It does not improve your deliverability directly
- It does not block phishing or impersonation attacks
Think of p=none as installing security cameras without hiring guards. You can see what is happening, but you are not yet taking action against unauthorized activity.
Policy: quarantine (p=quarantine) - Soft Enforcement
The p=quarantine policy tells receiving servers to treat messages that fail DMARC as suspicious. In practice, this usually means the message is delivered to the recipient's spam or junk folder rather than the inbox.
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@yourdomain.comWhen to use p=quarantine:
- After monitoring with
p=nonefor several weeks and confirming that all legitimate senders pass alignment - As a transitional step before moving to
p=reject - When you want to start protecting against spoofing without risking legitimate email being outright rejected
Important: Use the pct= tag to roll out quarantine gradually. Start with pct=10 (only 10% of failing messages are quarantined) and increase over time as you gain confidence. This limits the blast radius if a legitimate sender is accidentally not aligned.
Example of a gradual rollout:
- Week 1:
p=quarantine; pct=10 - Week 2:
p=quarantine; pct=25 - Week 3:
p=quarantine; pct=50 - Week 4:
p=quarantine; pct=100
Policy: reject (p=reject) - Full Enforcement
The p=reject policy is the strongest protection level. It tells receiving servers to reject (bounce) messages that fail DMARC alignment. These messages are never delivered to the recipient, not even to spam.
v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:forensic@yourdomain.com; fo=1When to use p=reject:
- After successfully running
p=quarantineat 100% with minimal false positives - When you are confident that all legitimate email sources are properly authenticated and aligned
- When maximum protection against domain spoofing and phishing is required
- For domains that have been targeted by phishing attacks
Warning: Moving to p=reject prematurely can cause legitimate email to bounce. Once rejected, there is no way for the recipient to find the message - it is gone. Make absolutely sure all legitimate senders pass alignment before enabling reject.
The p=reject policy is the gold standard for DMARC and is required by Google and Yahoo for the strongest sender reputation signals. Major email providers like Google, Microsoft, and Yahoo themselves use p=reject on their domains.
Use a dedicated DMARC report analysis tool or service to process your aggregate reports. Raw DMARC XML reports are difficult to read manually. Services like Postmark, dmarcian, or Valimail parse these reports into readable dashboards that show you exactly which senders pass or fail, how much volume each source sends, and where alignment issues exist. This visibility is essential for safely moving from p=none to p=reject.
Subdomain Policy (sp=)
The sp= tag lets you set a different DMARC policy for subdomains. This is particularly useful because attackers often spoof subdomains (like mail.yourdomain.com or support.yourdomain.com) rather than the parent domain.
v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@yourdomain.comIf sp= is not specified, subdomains inherit the parent domain's policy. Common configurations include:
p=reject; sp=reject- Full protection for the domain and all subdomainsp=reject; sp=quarantine- Strict on the parent domain, softer on subdomains while you audit themp=quarantine; sp=reject- Transitioning the parent domain while subdomains that do not send email are fully protected
Tip: For subdomains that never send email, publish their own DMARC record with p=reject and an SPF record of v=spf1 -all. This explicitly blocks all email from those subdomains.
Even if your main domain is still at p=none or p=quarantine, set sp=reject for subdomains that do not send email. Attackers frequently target subdomains because they are often left unprotected. A subdomain like invoice.yourdomain.com or secure.yourdomain.com can be very convincing in a phishing attack.
DMARC Alignment (Strict vs Relaxed)
DMARC alignment refers to the relationship between the domain in the From: header (what the recipient sees) and the domains used in SPF and DKIM authentication. For DMARC to pass, at least one of SPF or DKIM must both authenticate and align with the From: domain.
Relaxed alignment (default)
With relaxed alignment (adkim=r and aspf=r), the authenticated domain only needs to share the same organizational domain (root domain) as the From: header domain.
Example: An email with From: user@example.com passes relaxed DKIM alignment if DKIM is signed with d=mail.example.com, because both share the organizational domain example.com.
Strict alignment
With strict alignment (adkim=s and aspf=s), the authenticated domain must exactly match the From: header domain.
Example: An email with From: user@example.com would fail strict DKIM alignment if DKIM is signed with d=mail.example.com, because the domains are not an exact match.
| Alignment | From: Domain | Auth Domain | Result |
|---|---|---|---|
| Relaxed | example.com | mail.example.com | Pass |
| Strict | example.com | mail.example.com | Fail |
| Relaxed | example.com | example.com | Pass |
| Strict | example.com | example.com | Pass |
| Relaxed | example.com | otherdomain.com | Fail |
For most organizations, relaxed alignment is recommended. Strict alignment is useful in high-security environments but can cause failures with some third-party senders that sign with a subdomain.
DMARC Reporting (rua and ruf)
DMARC reporting is one of the most valuable features of the protocol. There are two types of reports:
Aggregate reports (rua)
Aggregate reports are XML files sent daily (usually) by receiving mail servers. They contain statistics about all emails received claiming to be from your domain, including authentication results, source IP addresses, and the volume from each source.
rua=mailto:dmarc-aggregate@yourdomain.comWhat aggregate reports tell you:
- Which IP addresses are sending email as your domain
- Whether each source passes or fails SPF and DKIM
- Whether alignment passes or fails
- The policy applied to each message (none, quarantine, reject)
- The volume of messages from each source
Forensic reports (ruf)
Forensic reports (also called failure reports) provide details about individual messages that failed DMARC. They can include message headers or even the full message body, depending on the sending server's policy.
ruf=mailto:dmarc-forensic@yourdomain.com; fo=1The fo= tag controls when forensic reports are sent:
fo=0- Send a report when both SPF and DKIM fail alignment (default)fo=1- Send a report when either SPF or DKIM fails alignment (recommended)fo=d- Send a report when DKIM fails (regardless of alignment)fo=s- Send a report when SPF fails (regardless of alignment)
Note: Many large mailbox providers (including Gmail) do not send forensic reports due to privacy concerns. Do not rely solely on forensic reports for monitoring. Aggregate reports are more reliable and universally supported.
Migration Path: none to quarantine to reject
The safe way to implement DMARC is a gradual, phased approach. Rushing to p=reject without proper preparation can block legitimate email.
Phase 1: Monitor (2 to 4 weeks)
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1Publish a p=none record with reporting. Collect and analyze aggregate reports. Identify all legitimate sending sources. Fix any SPF or DKIM issues for authorized senders.
Phase 2: Soft enforcement (2 to 4 weeks)
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@yourdomain.comMove to p=quarantine starting with a low percentage. Monitor reports for any legitimate senders that are failing. Increase the percentage gradually (25, 50, 75, 100).
Phase 3: Full enforcement
v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; ruf=mailto:forensic@yourdomain.com; fo=1Once quarantine is at 100% and reports show no legitimate failures, move to p=reject. Continue monitoring reports to catch any new senders or configuration changes.
Tip: The entire migration typically takes 4 to 12 weeks, depending on the complexity of your email infrastructure and the number of third-party senders you need to authenticate. Do not rush it - the reporting data is essential for making informed decisions.
DMARC has three policy levels: p=none (monitor only), p=quarantine (send failures to spam), and p=reject (block failures entirely). Always start at p=none with reporting enabled, then gradually move to quarantine and reject over 4 to 12 weeks. Use the pct= tag to roll out enforcement gradually and monitor aggregate reports at every stage to avoid blocking legitimate email.
Generating Your DMARC Record
Use our DMARC Record Generator to create a properly formatted DMARC record for your domain. The generator walks you through each tag and produces a ready-to-publish DNS TXT record.
After publishing your record, verify it with the DMARC Record Checker to confirm it is properly formatted and accessible.
← Back to Blog