What is DMARC and why do I need it?

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is an email authentication protocol defined in RFC 7489 that builds on SPF (RFC 7208) and DKIM (RFC 6376). It gives domain owners two things they do not have otherwise: control over what happens to messages that fail authentication, and visibility into who is sending email using their domain. Without DMARC, anyone can forge your domain in the From: header of phishing emails and you would never know. The p= tag tells receivers how to handle failures (none for monitoring, quarantine for spam folder, reject for blocking), while rua= directs daily aggregate reports to your email address. These XML reports list every IP that sent mail as your domain, with SPF and DKIM pass/fail counts. Gmail, Outlook, and Yahoo all enforce DMARC policies and generate these reports.

What is the difference between p=none, p=quarantine, and p=reject?

These three policy levels, defined in RFC 7489 Section 6.3, represent a progression from monitoring to full enforcement. p=none is monitoring-only. Receivers take no action on failing messages but still send aggregate reports to your rua= address. This is the safe starting point for every deployment. p=quarantine tells receivers to route failing messages to the spam folder instead of the inbox, giving you protection while keeping messages accessible if a legitimate sender is misconfigured. p=reject is the strongest option: receivers reject failing messages during the SMTP transaction, so they never get delivered at all. The recommended path moves from p=none through p=quarantine to p=reject over 4-12 weeks. Use aggregate report data at each stage to verify all legitimate senders pass authentication before tightening. The pct= tag lets you apply the policy to a percentage of messages for gradual rollout.

What are DMARC aggregate reports (rua=)?

Aggregate reports are daily XML summaries that receiving mail servers send to the addresses in your rua= tag, as defined in RFC 7489 Section 7.1. Each report covers roughly a 24-hour window and breaks down every IP address that sent mail using your domain in the From: header. You get per-IP counts of SPF and DKIM pass/fail results along with the DMARC policy action taken. The XML schema is documented in RFC 7489 Appendix C. These reports serve three purposes: finding all legitimate mail sources that need SPF or DKIM coverage, spotting unauthorized spoofing campaigns using your domain, and building enough confidence to tighten your policy from p=none toward p=reject. Google, Microsoft, Yahoo, and Apple all generate aggregate reports. The raw XML can be hard to read, so tools like Postmark, Valimail, and dmarcian can parse and visualize the data for you.

What are DMARC forensic reports (ruf=)?

Forensic reports (ruf=) are per-message failure notifications sent when individual messages fail DMARC authentication, as defined in RFC 7489 Section 7.3. They use the AFRF format from RFC 6591 and can include message headers or even full message content, making them useful for debugging specific failures or investigating phishing attempts. The fo= tag controls when they fire: fo=0 (the default) reports only when all authentication mechanisms fail, fo=1 reports when any mechanism fails, fo=d targets DKIM failures specifically, and fo=s targets SPF failures. Here is the catch though: forensic reports have major practical limitations. Gmail and Yahoo no longer send them due to privacy concerns about forwarding message content to third parties. For most deployments, aggregate reports through rua= provide enough visibility without the privacy complications. Focus your effort on getting aggregate reporting working well first.

What is alignment in DMARC?

Alignment, defined in RFC 7489 Section 3.1, means the domain in the visible From: header (RFC5322.From) must match the domain authenticated by SPF or DKIM. This stops attackers from passing SPF with one domain while spoofing a completely different domain in the From: header that recipients actually see. There are two modes. Relaxed alignment (aspf=r or adkim=r, the default) allows organizational domain matches, so mail.example.com aligns with example.com. Strict alignment (aspf=s or adkim=s) requires an exact match, meaning mail.example.com would fail against example.com. A message passes DMARC if either SPF or DKIM alignment passes, as specified in RFC 7489 Section 4.2. You do not need both. DKIM alignment tends to be more reliable in practice because DKIM signatures survive email forwarding, while SPF breaks when messages route through intermediary servers.

What does the sp= subdomain policy tag do?

The sp= tag, defined in RFC 7489 Section 6.3, sets a separate DMARC policy specifically for subdomains. Without it, subdomains inherit the parent domain's p= policy. This is useful during staged rollouts. Say your root domain already uses p=reject but dev.example.com or staging.example.com are not fully set up with SPF and DKIM yet. Setting sp=none keeps subdomain mail flowing while the parent domain stays protected. For example, v=DMARC1; p=reject; sp=none means spoofed mail from example.com gets rejected, but failing mail from sub.example.com passes through in monitoring mode. The reverse pattern works too. Some organizations set sp=reject with p=none to lock down unused subdomains against spoofing while they are still monitoring authentication on their primary domain during initial DMARC deployment.

How does pct= work for gradual DMARC rollout?

The pct= tag from RFC 7489 Section 6.3 controls what percentage of failing messages actually get the stated policy applied. Messages outside that percentage are treated as p=none and delivered normally. This lets you enforce gradually without risking a sudden disruption to legitimate mail. A typical rollout starts with p=quarantine pct=10, quarantining only 10% of failures. Then you bump to 25%, 50%, and finally 100% over several weeks while watching aggregate reports for any legitimate mail getting caught. If pct= is omitted, the default is 100, meaning the policy applies to everything. Once you hit pct=100 with p=quarantine and your reports show 98%+ pass rates across all mail sources, you can confidently move to p=reject. That gives you full enforcement where spoofed email is stopped at the SMTP level.

How do I implement DMARC progressively?

Follow the five-stage path outlined in RFC 7489 Section 6.6.1. Start by publishing p=none with rua= pointing to your monitoring address and collect aggregate reports for 2-4 weeks to see every mail source using your domain. Next, review those reports and make sure every legitimate sender is covered by SPF includes or has DKIM signing set up. Then move to p=quarantine pct=10, quarantining only 10% of failures while watching for legitimate mail getting caught. Gradually increase to pct=25, 50, then 100 as reports confirm 98%+ pass rates. Finally, switch to p=reject for full enforcement. Do not skip stages. Jumping straight to p=reject will block legitimate email from third-party services like CRMs, marketing platforms, and support tools. The whole process typically takes 4-12 weeks depending on how many mail sources your domain uses.

Do I need external report authorization for DMARC?

Yes, whenever your rua= or ruf= points to a domain different from the one publishing the DMARC record. RFC 7489 Section 7.1 defines this verification mechanism to prevent report flooding attacks. Say example.com publishes rua=mailto:reports@thirdparty.com. For that to work, thirdparty.com must publish a TXT record at example.com._report._dmarc.thirdparty.com containing v=DMARC1 to explicitly authorize receiving reports for example.com. Without that authorization record, compliant receivers will silently skip sending reports to the external address, and you will end up with incomplete data. This trips people up frequently when using third-party DMARC monitoring services like Postmark, Valimail, or dmarcian, since each service domain needs authorization records for every customer domain. Most providers handle this during onboarding, but verify with a DNS lookup to be sure.

DMARC Record Checker

Analyze your domain's DMARC policy per RFC 7489, inspect reporting configuration, check SPF and DKIM alignment modes, and generate a ready-to-publish DMARC record.

DMARC Record Generator

Generate a ready-to-publish TXT record for _dmarc.yourdomain.com

Written by Ishan Karunaratne · Last reviewed: March 11, 2026

What Is DMARC?

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is an email authentication protocol specified in RFC 7489 (published March 2015). It builds on two existing authentication mechanisms — SPF (RFC 7208) and DKIM (RFC 6376) — to give domain owners control over what happens to messages that fail authentication and visibility into who is sending email using their domain.

A DMARC record is published as a TXT record at _dmarc.yourdomain.com. It instructs receivers on three things: the policy to apply to failing messages, the alignment rules for SPF and DKIM identifiers, and where to send authentication reports.

How Does DMARC Authentication Work?

When a receiving mail server gets a message, it performs the DMARC evaluation flow defined in RFC 7489 Section 4.2:

Extract From Domain

The receiver extracts the domain from the RFC5322.From header — this is the domain whose DMARC policy will be checked.

Query DMARC Record

DNS lookup for TXT at _dmarc.domain. If no record is found, the receiver checks the organizational domain as a fallback.

Check SPF & DKIM Alignment

SPF/DKIM must not only pass, but their authenticated identifiers must align with the From domain (relaxed or strict per aspf/adkim).

Apply Policy

If both SPF and DKIM alignment fail, the receiver applies the policy (none/quarantine/reject) subject to the pct= sampling rate.

A message passes DMARC if either SPF passes with alignment or DKIM passes with alignment — both are not required. This is an important distinction from how SPF and DKIM work independently.

What Are the DMARC Policy Levels?

The p= tag is the most important part of a DMARC record, defined in RFC 7489 Section 6.3:

p=none

Monitor

No action taken on failing messages. Reports are sent so you can observe traffic. This is the starting point for all DMARC deployments.

p=quarantine

Quarantine

Failing messages are moved to the recipient's spam or junk folder. Used as an intermediate step to verify no legitimate mail is affected.

p=reject

Enforce

Failing messages are rejected during the SMTP transaction and never delivered. Maximum protection against spoofing and phishing.

What Are Common DMARC Misconfigurations?

Missing rua= tag

Without aggregate report URIs, you fly blind — no visibility into authentication results, spoofing attempts, or misconfigured senders. Always include rua=.

RFC 7489 Section 6.2

Jumping to p=reject too fast

Enforcing reject without first collecting and reviewing aggregate reports will block legitimate email from third-party senders (ESPs, CRMs, support tools) that aren't covered by SPF/DKIM.

RFC 7489 Section 6.6.1

Multiple DMARC records

Publishing more than one DMARC TXT record at _dmarc.domain causes all records to be discarded. Receivers treat this as no DMARC record at all.

RFC 7489 Section 6.6.3

Missing external report authorization

If rua= points to an address outside your domain, the receiving domain must publish an authorization TXT record. Without it, receivers will not send reports.

RFC 7489 Section 7.1

How Does DMARC Reporting Work?

DMARC reporting, defined in RFC 7489 Section 7, turns every participating mail receiver into a sensor for your domain. There are two report types:

Aggregate Reports (rua=)

Daily XML summaries (schema in RFC 7489 Appendix C) covering every IP that sent mail using your From domain. Includes SPF/DKIM pass/fail counts and applied policy per source IP.

Forensic Reports (ruf=)

Per-message failure details using AFRF format (RFC 6591). Can include headers or full message content. Many providers no longer send these due to privacy.

How Do You Implement DMARC Progressively?

Moving too fast to p=reject without proper preparation is the most common mistake in DMARC deployment. The recommended path per RFC 7489 Section 6.6.1:

1
Publish p=none with rua= — Start collecting aggregate reports. Wait 2-4 weeks to get a complete picture of all mail streams.
2
Fix SPF and DKIM for all senders — Ensure all legitimate senders (ESP, CRM, support tools, marketing platforms) are covered by SPF includes or have DKIM signing configured.
3
Move to p=quarantine pct=10 — Apply quarantine to 10% of failing messages. Monitor reports for any legitimate failures.
4
Increase to p=quarantine pct=100 — Gradually increase sampling. Once reports show consistent 98%+ pass rates, apply to all messages.
5
Switch to p=reject — Full enforcement. Spoofed email using your domain is rejected at the receiver.

Which RFCs Define DMARC?

RFC 7489(2015)

DMARC — Domain-based Message Authentication, Reporting, and Conformance

The core DMARC specification. Defines the policy record format, alignment rules, authentication flow, aggregate and forensic reporting, and deployment guidelines.

RFC 6591(2012)

Authentication Failure Reporting Using ARF

Defines the AFRF format used for DMARC forensic reports (ruf=). Extends the Abuse Reporting Format (ARF) from RFC 5965 with authentication failure details.

RFC 7208(2014)

Sender Policy Framework (SPF)

The SPF specification that DMARC builds upon. Defines which mail servers are authorized to send for a domain via DNS TXT records.

RFC 6376(2011)

DomainKeys Identified Mail (DKIM) Signatures

The DKIM specification that DMARC builds upon. Defines cryptographic message signing and verification using DNS-published public keys.

What Other Tools Help With Email Authentication?

DMARC depends on SPF and DKIM being correctly configured. Use these tools to verify your complete email authentication setup:

•SPF Checker — Validate which servers are authorized to send email for your domain, check for SPF include errors, DNS lookup limit violations per RFC 7208
•DKIM Checker — Look up a DKIM public key by selector and domain, verify record syntax per RFC 6376, check key strength per RFC 8301
•MX Lookup — Find mail servers for any domain, detect email providers, verify reverse DNS records per RFC 5321
•SMTP Diagnostics — Test mail server connectivity, TLS certificate validity, and open relay status
•Blacklist Checker — Check whether your mail server IP is listed on any DNSBL or RBL that could affect deliverability

Frequently Asked Questions