DMARC — policy, reporting, and the p=reject failure mode.

What DMARC actually does

A receiving mail server, upon delivery of an inbound message, performs three independent operations. It verifies SPF — does the sending IP appear in the SPF record published at the envelope MAIL FROM domain. It verifies DKIM — does the cryptographic signature in the message header validate against the public key published at the signing domain. And then, only if either SPF or DKIM passed, it performs the DMARC check: does the domain that passed alignment match the domain in the visible From: header.

This alignment step is the actual purpose of DMARC. SPF and DKIM, on their own, do not prevent a spammer from sending mail with From: ceo@yourbank.com as long as the spammer's own infrastructure has valid SPF and DKIM for some other domain — the one they actually send from. DMARC closes that gap by requiring the authenticated domain to align with the visible From: domain that the recipient sees in their mail client.

The policy published at _dmarc.example.com tells receivers what to do when alignment fails: ignore the failure, route the message to a spam quarantine, or reject the message outright at the SMTP transaction.

The three policy values

A DMARC policy is a TXT record at the _dmarc subdomain of the sending domain. The minimum-viable record looks approximately like this:

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

The p= tag is the policy. It accepts three values, commonly understood as a deployment progression but functionally distinct:

p=none — monitoring posture

p=none instructs receivers to take no action on alignment failure, but to still produce the aggregate reports specified by the rua tag. This is the correct initial deployment. It is a monitoring posture, not a protection posture, and remaining at p=none indefinitely is the most common configuration error in B2B sending infrastructure: the operator deploys the record, never reads the reports, and assumes DMARC is configured.

A domain at p=none provides zero protection against display-name and look-alike-domain phishing of the brand. It does, however, produce the diagnostic stream required to safely escalate.

p=quarantine — soft enforcement

p=quarantine instructs receivers to route alignment-failed mail to the spam folder. This is the first policy that produces a behavioral change at recipients, and consequently the first policy that exposes any misconfigured legitimate sending flow. Most production deployments first discover the existence of a SaaS vendor sending transactional mail on the domain's behalf — invoice notifications, calendar invites, support tool replies — at the moment p=quarantine activates.

The pct= tag is the staged-rollout mechanism: p=quarantine; pct=10 applies the policy to a random 10% of failing mail, allowing the operator to observe the impact in aggregate reports before extending to the full population. A staged rollout from pct=10 to pct=25 to pct=50 to pct=100 over two to four weeks is the conservative deployment path.

p=reject — hard enforcement

p=reject instructs receivers to reject alignment-failed mail at the SMTP transaction — the message is bounced, the sender receives an explicit failure notification, and the mail does not enter the recipient's mailbox or spam folder. This is the policy required for full anti-phishing protection of the brand and the policy required to enable BIMI (Chapter 5).

It is also the policy that has, in production, silently broken every revenue-impacting flow built on assumed mail delivery: password resets, two-factor authentication codes, billing invoices, calendar invites from any mail client that re-sends from a different infrastructure than the original sender. The set of legitimate sending flows on a corporate domain is, in our observation, larger than the operator's mental model of it by a factor of two to four.

Deploying p=reject without a complete alignment audit of every legitimate sending flow — every SaaS vendor, every personal cloud mail client, every marketing platform, every transactional service — is the single most common cause of a production deliverability incident on an otherwise correctly configured sending estate.

Alignment modes — strict vs relaxed

DMARC alignment is governed by two additional tags: aspf for SPF alignment and adkim for DKIM alignment. Each accepts the values r (relaxed, the default) or s (strict).

Relaxed alignment requires that the authenticated domain share an organizational domain with the From: header domain. From: hello@mail.example.com with DKIM signed by d=example.com passes relaxed alignment because both resolve to example.com as their organizational domain.

Strict alignment requires an exact match. The same message would fail strict alignment because mail.example.com is not identical to example.com.

The practical implication: strict alignment is the correct posture for senders whose threat model includes subdomain takeover attacks against the organizational domain. It is the wrong posture for any sender using third-party platforms — sequencing tools, transactional providers, CRM-integrated mail — that sign DKIM under the platform's organizational domain rather than the sender's own.

Aggregate reports — RUA

The rua=mailto: tag specifies an address to receive DMARC aggregate reports. Receivers that honor the protocol — Gmail, Yahoo, Microsoft, Apple, Comcast, and most major enterprise providers — produce daily XML reports containing, per sending source IP: total volume, SPF result, DKIM result, alignment result, and applied policy.

A single domain receiving meaningful inbound mail volume generates between 20 and 200 aggregate reports per day, with individual report sizes ranging from a few kilobytes to several megabytes. The reports are XML, compressed in .gz or .zip, and contain no actionable information when read directly by a human operator.

The correct posture is to route rua mail to an automated parsing service — a self-hosted parser writing to a SQL store, or a managed service that exposes a dashboard. The relevant queries against the parsed data: (a) which source IPs are sending under our domain that we did not authorize, (b) which authorized sources have inconsistent SPF or DKIM results, (c) what fraction of total volume is currently failing alignment, (d) is this fraction stable or trending up.

Forensic reports — RUF

The ruf=mailto: tag specifies an address to receive per-message forensic reports — one report per alignment-failing message, including a redacted copy of the failing message. In practice, the major mailbox providers no longer send forensic reports, citing privacy concerns regarding the partial-message content. The tag is published by some operators for completeness and produces minimal traffic.

The operational signal in forensic reports, when received, is the visibility into what specific message content is failing alignment — useful for debugging a single misbehaving sending platform, but redundant once the aggregate reports have identified the source IP.

Subdomain policy inheritance

DMARC published at the organizational domain applies to all subdomains by default. The sp= tag explicitly sets the subdomain policy and is required for any sender intending to apply different enforcement at the corporate vs sending tier.

A common production architecture: p=reject at example.com for the corporate domain, sp=quarantine for any subdomain. This protects the corporate root from look-alike phishing while leaving operational room for transactional services on subdomains that may not yet have completed their alignment audit.

The cold-sending domain — a separate organizational domain entirely, registered for the purpose of housing outbound sequence traffic — has its own DMARC record with its own escalation path, independent of the corporate domain. This separation is the central premise of Chapter 7 (subdomain and domain isolation).

The escalation path

A correctly executed DMARC deployment progresses through five stages, each gated on observed signal from the prior stage's aggregate reports. Compressing the timeline below 60 days has, in our observation, a roughly 70% probability of producing a production incident:

Common deployment failures observed in production

• Skipping straight to p=reject. The operator reads a security best-practices guide, publishes p=reject without staged rollout, and silently breaks one or more transactional flows for the seven to fourteen days before the support tickets aggregate.
• Deploying p=none with no rua. The record exists; the receivers honor it; no reports flow anywhere. The deployment is functionally a no-op masquerading as configured. This is the most frequent stable failure state.
• Routing rua to an unmonitored inbox. Reports flow but nobody parses them. The aggregate volume saturates the inbox within ninety days and the operator's eventual investigation discovers, retrospectively, that an unauthorized sender has been spoofing the domain for the prior quarter.
• Setting aspf=s; adkim=s with a third-party sending platform. The platform signs DKIM under its own domain, the sender enforces strict alignment, all mail from the platform fails DMARC. The operator typically discovers this when an outbound marketing campaign produces zero opens.
• Omitting sp= on a corporate domain with transactional subdomains. The organizational p=reject inherits to every subdomain, including subdomains that have not been audited. Subdomain transactional flow regresses without warning.
• Forwarding-induced alignment failure. A meaningful fraction — typically 3 to 8% — of legitimate mail is forwarded by recipients through mailing-list servers or personal forwarding rules. The forwarder rewrites the envelope, breaking SPF; if DKIM also breaks (typical for older forwarders), DMARC fails. ARC (Chapter 6) is the protocol that mitigates this; deploying p=reject on a domain without ARC-aware downstream receivers is observably destructive at the 5%-of-volume tier.

The reporting parse and what to look for

An aggregate report is an XML document with a metadata block and one or more <record> elements. Each record represents a (source IP, applied policy) tuple and contains the message count, SPF result, DKIM result, and alignment results. The signal a sender needs to extract:

• Total volume by source IP, descending. The top five IPs typically account for >95% of volume and should map to known sending infrastructure.
• Alignment failure rate by source IP. An authorized sender with consistent >10% alignment failures has a configuration issue. An unauthorized sender with any volume is a spoofing attempt.
• New source IPs week-over-week. An unfamiliar IP appearing in reports is either a new authorized service that was not catalogued, or an active spoofing attempt. Both require investigation.
• Volume trend at the receiver level. A sudden drop in volume from Gmail's reporting IPs typically indicates a sending issue, not a reporting issue.

Pre-deployment checklist

• SPF record published at the organizational domain, under the 10-DNS-lookup limit (Chapter 1)
• DKIM signing operational on at least one selector, with a 2048-bit key (Chapter 2)
• All third-party sending services catalogued, with their DKIM and SPF requirements documented
• An rua destination configured and an aggregate-report parser running before publication
• A documented rollback procedure to p=none with TTL-aware DNS
• An internal-communications plan for the day quarantine activates — affected employees identified, support team briefed
• For the cold-sending domain specifically: p=reject from day one is acceptable, because there is no legitimate inbound or transactional flow to protect

Where DMARC fits in the broader infrastructure

DMARC is the protocol that gives operational meaning to SPF and DKIM. Without DMARC, the two underlying mechanisms validate identity but enforce nothing — a receiver may use the results as one of many spam-classifier signals, but no action is required. With DMARC, the sender publishes an explicit policy contract with receivers, and the receivers honor it.

For a cold-sending estate specifically, DMARC at p=reject on the sending domain is a hard prerequisite for Gmail and Yahoo bulk-sender compliance (Chapter 10), for BIMI logo display (Chapter 5), and for the receiver-side reputation systems that distinguish authenticated bulk mail from impersonated bulk mail. A sender at p=none is, from the receiver's perspective, indistinguishable from a sender with no policy at all.