DMARC

In 2012, PayPal was drowning in phishing. Attackers were sending millions of emails that appeared to come from @paypal.com, and recipients had no reliable way to tell the real messages from the fakes. PayPal was one of the first major organizations to deploy DMARC with a p=reject policy — instructing every receiving mail server in the world to silently discard any email claiming to be from PayPal that failed authentication.

The result: a 70% drop in phishing attacks against the PayPal brand. Not a gradual decline. A cliff.

That single deployment demonstrated something the email industry had known for years but had never been able to act on: SPF and DKIM were necessary but not sufficient. They could authenticate messages, but they could not tell receiving servers what to do when authentication failed. And without a policy, most servers did nothing — they accepted the spoofed messages anyway.

DMARC was built to close that gap.

The Problem: Authentication Without a Policy

By 2011, SPF and DKIM had been deployed across millions of domains. But two fundamental problems remained unsolved.

Problem 1: No policy. SPF could determine that a message came from an unauthorized server, and DKIM could determine that a signature was missing or invalid. But neither protocol told the receiving server what action to take. Should it reject the message? Quarantine it? Accept it anyway? Each receiver made its own decision, and most erred on the side of delivery. The domain owner had no say.

Problem 2: No alignment. SPF authenticates the envelope sender (MAIL FROM), and DKIM authenticates the domain in the d= tag of the signature. But the address users actually see — the From: header — could be completely different from both. An attacker could pass SPF using their own domain as the envelope sender while putting ceo@yourcompany.com in the visible From: header. SPF would pass. DKIM might be absent. The user would see a message that looked legitimate.

Problem 3: No visibility. Domain owners had no way to know who was sending email using their domain. They could not see which messages passed or failed authentication, which IP addresses were sending on their behalf, or how many spoofed messages were circulating. They were defending blind.

DMARC solves all three problems with a single DNS record.

How DMARC Works

DMARC adds three capabilities on top of SPF and DKIM:

1. Alignment — it requires that the domain authenticated by SPF or DKIM matches the domain in the visible From: header
2. Policy — it lets domain owners specify what should happen to messages that fail authentication
3. Reporting — it provides a feedback loop so domain owners can see exactly what is happening with their email

The evaluation flow:

Email received
  |
  +--> SPF check --> Pass? --> MAIL FROM domain aligns with From: header?
  |                              YES --> DMARC Pass (via SPF)
  |                              NO  --> fall through
  |
  +--> DKIM check --> Pass? --> DKIM d= domain aligns with From: header?
                                 YES --> DMARC Pass (via DKIM)
                                 NO  --> DMARC Fail --> Apply policy

A message passes DMARC if either SPF or DKIM passes and the authenticated domain aligns with the From: header domain. Both do not need to pass — one aligned authentication is sufficient.

This design is intentional. SPF breaks when messages are forwarded (because the forwarding server’s IP is not in the original domain’s SPF record). DKIM survives forwarding as long as the signed headers and body are not modified. By accepting either mechanism, DMARC remains robust in the face of legitimate forwarding scenarios.

The DMARC DNS Record

DMARC records are published as TXT records at a specific location: _dmarc.<domain>.

_dmarc.example.com.  IN TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensic@example.com; adkim=s; aspf=s; pct=100"

Record Tags

Tag	Required	Description	Values
v	Yes	Version identifier	DMARC1 (must be the first tag)
p	Yes	Policy for the domain	none, quarantine, reject
sp	No	Policy for subdomains	none, quarantine, reject (defaults to p value)
rua	No	Where to send aggregate reports	mailto:reports@example.com
ruf	No	Where to send forensic/failure reports	mailto:forensic@example.com
adkim	No	DKIM alignment mode	r (relaxed, default) or s (strict)
aspf	No	SPF alignment mode	r (relaxed, default) or s (strict)
pct	No	Percentage of failing messages to apply policy to	0-100 (default: 100)
fo	No	Failure reporting options	0 (default), 1, d, s
ri	No	Aggregate report interval in seconds	Default: 86400 (24 hours)

The Three Policies

DMARC offers three policy levels, representing a spectrum from passive observation to active enforcement.

p=none — Monitor

_dmarc.example.com.  IN TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

The receiving server takes no action on failing messages. It delivers them normally. But if you have specified a rua address, you will receive aggregate reports showing all authentication results. This is the data-gathering phase: you learn who is sending email as your domain, which messages pass, and which fail.

p=quarantine — Flag

_dmarc.example.com.  IN TXT  "v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc@example.com"

Failing messages are routed to the recipient’s spam or junk folder. The pct=50 tag in this example means only 50% of failing messages are quarantined; the rest are treated as if the policy were none. This allows gradual rollout.

p=reject — Block

_dmarc.example.com.  IN TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=s; aspf=s"

Failing messages are rejected outright. The receiving server returns an SMTP error and does not deliver the message. This is the strongest protection and the recommended end state.

Google’s own DMARC record uses p=reject:

_dmarc.google.com.  IN TXT  "v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com"

Alignment: Relaxed vs. Strict

Alignment determines how strictly the authenticated domain must match the From: header domain.

Relaxed alignment (default, adkim=r / aspf=r): The organizational domains must match. If the From: header is user@mail.example.com and DKIM signs with d=example.com, the alignment passes because both share the organizational domain example.com.

Strict alignment (adkim=s / aspf=s): The domains must match exactly. mail.example.com does not align with example.com. This is more secure but can break legitimate configurations where subdomains send email signed by the parent domain.

Most deployments use relaxed alignment. Strict alignment is used by organizations with tightly controlled email infrastructure who want to prevent subdomain-based attacks.

DMARC Reports

Reports are one of DMARC’s most valuable and underused features. They provide visibility into your email ecosystem that no other protocol offers.

Aggregate Reports (rua)

Aggregate reports are XML-formatted summaries sent daily (by default) from receiving mail servers to the address specified in your rua tag.

Each report contains:

• The IP addresses of servers that sent email using your domain
• How many messages each IP sent
• SPF and DKIM authentication results for each source
• The DMARC disposition (none, quarantine, reject) applied to each message
• The alignment results

These reports are essential during the p=none monitoring phase. They reveal every legitimate and illegitimate source of email for your domain. Without them, tightening your policy is guesswork.

You can specify multiple report recipients:

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

Forensic Reports (ruf)

Forensic reports (also called failure reports) are sent for individual messages that fail DMARC. They contain redacted copies of the failing email’s headers and sometimes the full message body.

These are more detailed but come with a caveat: many receivers do not send forensic reports due to privacy regulations, particularly GDPR. The data can include recipient addresses and message content. Rely on aggregate reports as your primary data source and treat forensic reports as a bonus.

Cross-Domain Reporting

If your rua or ruf address points to a different domain (e.g., reports for example.com sent to thirdparty.com), that domain must publish a DNS authorization record:

example.com._report._dmarc.thirdparty.com.  IN TXT  "v=DMARC1"

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

Deployment Strategy: The Crawl-Walk-Run Approach

Deploying DMARC is not a one-step process. Moving directly from no DMARC to p=reject will almost certainly block legitimate email that you did not know existed — forgotten SaaS tools, legacy systems, third-party senders that were never properly authenticated.

The proven deployment path:

Phase 1: Monitor (p=none) — 2 to 4 weeks minimum

_dmarc.example.com.  IN TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Deploy with p=none and a rua address. Collect aggregate reports. Identify every legitimate email source. Fix SPF and DKIM for each one.

Phase 2: Quarantine with gradual rollout — 2 to 8 weeks

_dmarc.example.com.  IN TXT  "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com"

Start quarantining 25% of failing messages. Monitor reports for false positives. Increase pct gradually: 25 to 50 to 75 to 100.

Phase 3: Reject — the end state

_dmarc.example.com.  IN TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

Once you are confident that all legitimate senders are authenticated, move to p=reject. Continue monitoring aggregate reports indefinitely — new email sources will appear as the organization evolves.

Adoption: The 2024 Inflection Point

DMARC adoption was stagnant for years. Then Google and Yahoo changed everything.

On October 3, 2023, Google and Yahoo jointly announced that starting February 2024, all bulk senders (those sending 5,000+ emails per day to personal accounts) must implement SPF, DKIM, and DMARC with at least p=none. In April 2025, Microsoft announced identical requirements for Outlook, Hotmail, and Live.

The impact was immediate and dramatic:

Metric	Before (2023)	After (2024-2025)	Change
DMARC adoption (top 10M domains)	27.2%	47.7%	+75% relative increase
New DMARC records published	—	500,000+ by Feb 2024	Massive surge
Unauthenticated messages to Gmail	Baseline	65% reduction	265 billion fewer messages in 2024
Bulk senders following best practices	Baseline	+50% adherence	Significant shift

But the numbers also reveal a persistent gap. Among domains that have deployed DMARC:

Policy Level	Share of DMARC-Enabled Domains
p=none (monitoring only)	~59%
p=quarantine	~16%
p=reject	~25%

Nearly 60% of DMARC-enabled domains are still in monitoring mode — they have published a record but are not actually enforcing it. Their DMARC deployment is a checkbox, not a defense. The gap between p=none and p=reject is where the real work remains.

The US government recognized this early. In October 2017, the Department of Homeland Security issued Binding Operational Directive 18-01, requiring all federal agencies to implement DMARC at p=reject. The UK followed with similar mandates for public sector domains.

How to Check DMARC with dig

Querying a domain’s DMARC record is straightforward:

dig +short TXT _dmarc.example.com

For a major domain like Google:

dig +short TXT _dmarc.google.com

"v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com"

To check a domain’s subdomain policy, look for the sp= tag in the record. If absent, subdomains inherit the parent domain’s p= policy.

To verify that your monitoring is working, check that you are receiving aggregate reports at your rua address within 24-48 hours of publishing the record. The reports arrive as gzipped XML files from major receivers like Google, Yahoo, Microsoft, and others.

The Bigger Picture

DMARC is the policy layer that makes email authentication actionable. Without it, SPF and DKIM are diagnostic tools — they can tell a receiving server whether a message is authenticated, but they cannot compel any particular response.

The cost of implementing DMARC is effectively zero: it is a DNS TXT record. The cost of not implementing it is measured in billions — $2.8 billion in BEC losses and $12.5 billion in phishing losses in 2024 alone, per the FBI. Google reported that its authentication requirements prevented 265 billion unauthenticated messages from reaching Gmail users in a single year.

DMARC is still evolving. The IETF is developing DMARCbis (DMARC 2.0), a Standards Track specification intended to replace RFC 7489, with better handling of indirect mail flows and improved ARC (Authenticated Received Chain) interoperability. Email authentication is moving from optional to mandatory. For any domain that sends email, DMARC at p=reject is the destination.