Guide

The Complete Guide to DMARC

Q: Should I use p=quarantine or p=reject as the final state?

p=reject. Quarantine is a stepping stone. Reject is stronger, provides clearer feedback to legitimate senders when something is misconfigured, and prevents spoofed mail from reaching spam folders where users may still see and act on it.

Q: Can spoofers just publish their own DMARC record?

No. A spoofer sending mail as alice@example.com cannot modify example.com's DNS. The DMARC record that governs a message is always the one published by the owner of the From header domain, retrieved by the receiver at the time the message is evaluated.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the standard that tells receiving mail servers what to do with email that fails authentication against your domain, and asks those servers to report back on what they saw. This guide covers how DMARC works, what every tag in a DMARC record means, how to read the aggregate reports it generates, and how to roll it out safely from a monitoring-only record to full enforcement.

What is DMARC?

DMARC is a standard published as RFC 7489 that tells receiving mail servers what to do with email that fails authentication checks against your domain, and asks those servers to send you reports about what they saw.

DMARC does three things:

Establishes a policy that receiving servers apply to email claiming to be from your domain but failing authentication.
Instructs receiving servers where to send aggregate reports describing which senders passed and failed, and how many messages each represented.
Enables gradual rollout so you can monitor authentication first, then enforce a policy once you understand your legitimate senders.

DMARC does not authenticate messages by itself. It works on top of two underlying standards, SPF and DKIM, and specifies what receivers should do when those checks fail.

Why DMARC exists

Before DMARC, receiving mail servers had no consistent instruction from domain owners about what to do with unauthenticated email. Spam filters made their own decisions. Legitimate mail from misconfigured senders was quarantined. Spoofed mail from lookalike domains reached inboxes.

DMARC gives domain owners a mechanism to state clearly, and cryptographically enforce, which servers are allowed to send email on their behalf. It also gives receivers the confidence to reject spoofed mail rather than deliver it defensively.

The practical outcome, when DMARC is deployed correctly with p=reject:

Legitimate mail from authorized senders lands in the inbox.
Spoofed mail from unauthorized senders is rejected before reaching the recipient.
The domain owner receives daily reports showing exactly what is being sent on their behalf, worldwide.

How DMARC works: the three-step check

When a receiving mail server accepts a message that claims to come from your domain, it runs three sequential checks:

Step 1. SPF check. The receiver examines the envelope sender's IP address and asks: is this IP authorized to send mail for the domain in the envelope's MAIL FROM? SPF answers this by publishing a list of authorized IPs in a DNS TXT record.

Step 2. DKIM check. The receiver looks for a DKIM signature in the message headers, retrieves the public key from DNS, and verifies the signature cryptographically. A valid signature proves the message was not modified in transit and that whoever signed it holds the private key associated with the published domain.

Step 3. Alignment and DMARC evaluation. DMARC then asks two questions:

Did SPF pass, and did the SPF-authenticated domain match the visible From: header domain?
Did DKIM pass, and did the DKIM-signing domain match the visible From: header domain?

If either check produces an aligned pass, DMARC passes. If both fail alignment, DMARC fails, and the receiver applies the policy declared in your DMARC record.

The key mechanic here is called alignment. SPF authenticates the envelope sender. DKIM authenticates whoever signed the message. Neither of them, on its own, verifies the address the user actually sees in their mail client. DMARC's contribution is to require that at least one of the two authenticated domains matches the visible From: address.

The DMARC record explained tag by tag

A DMARC record is a TXT record published at _dmarc.example.com. Its value is a single string containing tag-value pairs separated by semicolons.

Here is a minimal record:

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

Here is a fully specified record:

v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; pct=100; fo=1; rua=mailto:reports@example.com; ruf=mailto:forensic@example.com

Every tag DMARC supports:

v= (version). Must be DMARC1. Required. Must be the first tag in the record.

p= (policy). Required. Declares what receiving servers should do with mail that fails DMARC. Three valid values:

p=none: monitor only. Do not change delivery. Send reports.
p=quarantine: mark failing mail as suspicious. Most receivers deliver to spam.
p=reject: refuse failing mail. Most receivers bounce it during SMTP.

sp= (subdomain policy). Optional. Declares the policy for subdomains of the domain publishing this record. If omitted, subdomains inherit the p= policy. Same three valid values as p=.

adkim= (DKIM alignment mode). Optional. Controls how strict DKIM alignment must be.

adkim=r (default): relaxed. The organizational domain of the DKIM-signing domain must match the organizational domain of the From: header. mail.example.com signing a message from example.com is aligned.
adkim=s: strict. The DKIM-signing domain must exactly match the From: header domain.

aspf= (SPF alignment mode). Optional. Same semantics as adkim=, applied to the SPF check.

aspf=r (default): relaxed alignment.
aspf=s: strict alignment.

pct= (percentage). Optional. Integer 0 to 100. Instructs receivers to apply the declared policy to only a percentage of failing messages, chosen randomly. pct=100 is the default and means the policy applies to all failing messages. pct=25 applies it to a quarter, with the remaining three-quarters treated as if the next-weaker policy were declared.

fo= (forensic options). Optional. Controls when forensic (failure) reports are generated. Valid values:

fo=0 (default): generate a forensic report only when both SPF and DKIM fail.
fo=1: generate a forensic report when either SPF or DKIM fails.
fo=d: generate a forensic report on DKIM failure regardless of alignment.
fo=s: generate a forensic report on SPF failure regardless of alignment.

rua= (aggregate report URI). Optional but strongly recommended. A comma-separated list of mailto: URIs that will receive daily aggregate reports summarizing all mail claiming to be from the domain.

ruf= (forensic report URI). Optional. A comma-separated list of mailto: URIs that will receive per-message forensic reports. Rarely honored by receivers today because of privacy concerns.

rf= (report format). Optional. The only currently valid value is afrf (Authentication Failure Reporting Format).

ri= (report interval). Optional. Integer number of seconds between aggregate reports. Default is 86400 (24 hours). Most receivers ignore requests for shorter intervals.

What are DMARC aggregate reports?

Aggregate reports are XML documents sent by receiving mail servers to the address in your rua= tag, typically once per 24-hour period. Each report describes what one receiver saw for one domain over one time window.

An aggregate report contains:

Report metadata: the sender (for example, google.com or enterprise.protection.outlook.com), the report ID, the date range covered, and contact information.
Policy published: the DMARC policy the receiver saw when it looked up your record.
Records: one entry per unique combination of source IP, SPF result, DKIM result, and disposition. Each record includes a count of how many messages fit that combination.

Reports do not include message content. They do not identify individual recipients. They tell you, for each IP address that sent mail claiming to be from your domain during the reporting window: how many messages, whether SPF passed, whether DKIM passed, whether alignment worked, and what disposition the receiver applied.

A typical medium-sized domain receives 20 to 100 aggregate reports per day from a dozen or more different receiving providers. Processing these manually is impractical. This is what DMARC monitoring platforms exist to do.

You can send aggregate reports to DmarcSignal by signing up and creating a collector, then adding its address to your rua= tag. The service parses the XML, deduplicates by IP and time window, enriches each record with WHOIS and geolocation, and presents a dashboard of what actually happens to your domain in the wild.

How to implement DMARC safely

DMARC implementation is a staged rollout. Skipping stages is the single most common cause of legitimate mail being dropped during DMARC deployment.

Stage 1. Inventory your senders. Before publishing anything, list every service that sends email on your behalf. Marketing platform, transactional email service, CRM, help desk, HR system, calendar invites, monitoring alerts, personal mail from employees. Every service.

For each sender, note:

The domain it sends From:
Whether it supports SPF, DKIM, or both
Whether it can be configured to sign DKIM using your domain

Stage 2. Configure SPF and DKIM for each sender. For SPF, ensure your published SPF record includes every authorized sending source. For DKIM, configure each service to sign messages with a key published under your domain. Most modern senders provide the exact records to add.

Stage 3. Publish p=none. Publish a DMARC record with p=none and a rua= address you control. This changes nothing about delivery. It only asks receivers to send you reports. Wait at least two weeks. Longer is better. Watch the reports.

Stage 4. Fix what the reports reveal. Reports will surface legitimate senders you forgot about, misconfigured DKIM, SPF records missing an authorized IP, and legitimate mail that fails alignment because a service signs with its own domain rather than yours. Address each one. Move to Stage 5 only when your reports show consistent alignment for all legitimate mail.

Stage 5. Move to p=quarantine with a low pct=. Publish p=quarantine; pct=10. Ten percent of failing messages will now be quarantined. Watch reports for one to two weeks. If nothing unexpected fails, raise pct= to 25, then 50, then 100.

Stage 6. Move to p=reject. Once p=quarantine; pct=100 produces no surprises, change p=quarantine to p=reject. This is the goal state. All spoofed mail is now rejected before reaching recipients.

The full rollout typically takes 8 to 16 weeks for an organization with a modest sender inventory. Complex organizations with dozens of senders may take longer.

Why is DMARC failing when SPF and DKIM both pass?

The most common cause of this failure mode is alignment. SPF and DKIM can each pass in isolation while DMARC fails, because DMARC requires that at least one of them pass with an aligned domain.

Consider a message where:

The visible From: header is alice@example.com
The SMTP envelope's MAIL FROM is bounce@mailer.thirdparty.com
The DKIM signature is by thirdparty.com

SPF passes because mailer.thirdparty.com is authorized in thirdparty.com's SPF record. DKIM passes because the signature is cryptographically valid.

DMARC fails, though. Neither the SPF-authenticated domain (thirdparty.com) nor the DKIM-signing domain (thirdparty.com) matches or is a subdomain of the From: header domain (example.com).

The fix is to configure the third-party sender to sign DKIM using your domain rather than its own. Most modern services support this and provide a DNS record you publish to make it work. Once your domain signs, alignment succeeds.

What if I don't have a DMARC record yet?

Start with the simplest possible monitoring record. Publish this TXT record at _dmarc.example.com (replace example.com and the report address):

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

This publishes a DMARC policy of p=none, which does not change delivery of any mail. It only asks receivers to send you daily aggregate reports.

Wait for reports to accumulate. Then proceed through the staged rollout described above.

How long do DMARC changes take to take effect?

DMARC record changes are DNS TXT record changes. They take effect as quickly as your DNS TTL allows plus caching at receiving servers. In practice, most receivers begin honoring a new record within a few hours of publication, and all receivers honor it within 24 to 48 hours.

Aggregate reports lag your policy changes by their own reporting cadence. A receiver that generates a daily aggregate report will typically send you a report describing your new policy the day after you publish it.

DMARC record examples

A monitoring-only record for a new deployment:

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

A monitoring record that also asks for forensic reports on any authentication failure:

v=DMARC1; p=none; fo=1; rua=mailto:reports@example.com; ruf=mailto:forensic@example.com

A phased quarantine record applying the policy to 25 percent of failing mail:

v=DMARC1; p=quarantine; pct=25; rua=mailto:reports@example.com

A production reject record with strict alignment for both SPF and DKIM:

v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:reports@example.com

A record applying a different policy to subdomains than to the main domain:

v=DMARC1; p=reject; sp=quarantine; rua=mailto:reports@example.com

Frequently asked questions

Do I need SPF and DKIM before I publish DMARC?

Yes, you need at least one of them working with correct alignment. Without either, DMARC cannot pass, and any policy stronger than p=none will cause your legitimate mail to be rejected or quarantined.

Should I use p=quarantine or p=reject as the final state?

p=reject. Quarantine is a stepping stone. Reject is stronger, provides clearer feedback to legitimate senders when something is misconfigured, and prevents spoofed mail from reaching spam folders where users may still see and act on it.

Can I publish DMARC on a domain I don't send mail from?

Yes, and you should. A "reject everything" DMARC record on a parked or non-sending domain prevents spoofers from using it. The record for a non-sending domain is:

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

Do all receivers honor DMARC?

The largest providers (Gmail, Yahoo, Microsoft, Apple, ProtonMail, and most enterprise gateways) fully honor DMARC. Smaller and older systems may honor it partially or not at all. The coverage is high enough that a full deployment protects the majority of your recipients.

What's the difference between aggregate reports and forensic reports?

Aggregate reports are daily XML summaries of what receivers saw. They contain counts, IPs, and authentication results, no message content. Forensic reports are per-message reports about individual authentication failures, sometimes containing message headers. Aggregate reports are widely sent. Forensic reports are rarely sent today because of privacy concerns.

Can spoofers just publish their own DMARC record?

No. A spoofer sending mail as alice@example.com cannot modify example.com's DNS. The DMARC record that governs a message is always the one published by the owner of the From: header domain, retrieved by the receiver at the time the message is evaluated.

Does DMARC prevent all phishing?

DMARC prevents direct spoofing of your exact domain. It does not prevent lookalike domains (exarnple.com), display-name spoofing (a From: header showing Alice <attacker@evil.com>), or compromised legitimate accounts. DMARC is one layer in a defense-in-depth email security strategy.

What to do next

If you're new to DMARC, publish a p=none record with a rua= address you control and let reports accumulate for two to three weeks. If you'd like a monitoring dashboard that parses and enriches those reports for you, create a free DmarcSignal account and add your collector address to your rua= tag.

If you already have a DMARC record but you're stuck at p=none and unsure what to fix, the guide to verifying and troubleshooting your DMARC, DKIM, and SPF configuration walks through the specific diagnostics for each authentication step.

If you're ready to progress from p=none toward enforcement, the post on moving safely from p=none to p=reject covers the staged rollout in detail.