What is DMARC? A rollout, not a DNS checkbox

What is DMARC? How alignment and policy actually work

That distinction matters. DMARC is not a third independent signature or password. It connects the identity a person sees in the From header to the identities already authenticated by SPF and DKIM.

The mental model: authenticate, align, then apply policy

Suppose a customer receives this message:

From: Acme <[email protected]>Return-Path: [email protected]DKIM-Signature: ... d=acme.example; s=marketing; ...

3 domains can be involved:

SPF can pass for mailer.vendor.example without helping DMARC for acme.example, because the domains are not aligned. In the example above, DKIM can provide the DMARC pass because its valid d=acme.example identity aligns with the visible From domain. The key rule is an OR, not an AND: > DMARC passes when at least one authenticated SPF or DKIM identity both passes its underlying check and aligns with the Author domain.

You still normally deploy both SPF and DKIM. Forwarding commonly breaks SPF because the forwarding server's IP is not authorized by the original sender's SPF record. A DKIM signature can survive forwarding if the signed content is not modified in a way that invalidates the signature. Relying on only one path makes legitimate mail more fragile.

Alignment is the part most summaries skip

An authentication result and an aligned authentication result are different things. DMARC defines 2 alignment modes:

So if the visible From is news.brand.example and DKIM signs as brand.example, relaxed alignment can succeed while strict alignment does not.

An operator should inspect the actual identifiers, not just a dashboard that says "SPF: pass" or "DKIM: pass." A message can have a valid SPF pass and valid DKIM pass. It can still fail DMARC if neither successful identity aligns with the visible From domain.

The 2026 DMARC standard also changed how Organizational Domains are discovered. RFC 9989 replaced the older Public Suffix List-dependent discovery model with a DNS Tree Walk. That is a protocol-level change worth knowing if you are comparing modern DMARC documentation with older tutorials or libraries.

What the DMARC DNS record controls

A DMARC policy record is published as a DNS TXT record under _dmarc for the relevant domain. A minimal monitoring record might look like:

_dmarc.acme.example TXT "v=DMARC1; p=none; rua=mailto:[email protected]"

The most important concepts are:

• v=DMARC1: identifies the record as DMARC
• p=: the domain owner's requested assessment policy for messages that fail DMARC. Common values are none, quarantine, and reject
• rua=: where aggregate DMARC reports can be requested. Aggregate reporting is now specified separately in RFC 9990
• alignment tags such as adkim= and aspf=: choose strict or relaxed alignment
• subdomain-related policy tags: control policy behavior below the policy domain where applicable

p=none is not "DMARC off." The receiver can still evaluate DMARC, and the domain owner can still use aggregate reporting to map legitimate and unauthorized traffic. What p=none does is avoid asking receivers to quarantine or reject mail solely because it failed the DMARC mechanism.

Likewise, p=reject is not a remote command that forces every mailbox provider to reject. DMARC publishes the domain owner's requested handling policy. Receivers still apply their own local policy and anti-abuse logic.

What DMARC protects, and what it does not

DMARC is especially useful against direct domain spoofing. If an attacker sends a message that visibly claims to be from billing@acme.example but cannot produce an aligned SPF or DKIM pass for acme.example, DMARC can produce a fail result. The receiver can use Acme's policy as one input to handling.

It does not prove that a message is trustworthy in every sense. A scammer can register a visually similar domain such as acme-support.example and authenticate it perfectly. DMARC also does not guarantee inbox placement. RFC 9989 explicitly separates a DMARC pass from an assertion that a message is desirable or safe to deliver to the inbox. Think of DMARC as authorization of the visible domain identity, not a universal trust score.

Policy inheritance and subdomains need deliberate ownership

DMARC is published in DNS, so large organizations need to decide which team owns the policy domain and which subdomains are allowed to send independently. A subdomain without its own applicable record can inherit policy behavior from an ancestor policy domain under DMARC discovery rules. That is useful for protecting forgotten subdomains, but it can surprise teams that quietly started sending from events.example.com or support.example.com without coordinating authentication.

Treat each new visible From domain as an infrastructure change. Before it goes live, answer:

• Which DMARC policy will receivers discover for it?
• Which DKIM domain will sign the traffic?
• Which envelope identity will SPF authenticate?
• Does the intended alignment mode still pass?
• Where will aggregate reports for this traffic be reviewed?

That is safer than letting product teams mint sending subdomains and discovering policy inheritance only after failures appear.

Aggregate reports are a map, not a verdict on every message

DMARC aggregate reporting summarizes authentication observations by receiver and source. It is valuable for inventory because it can reveal sending infrastructure the domain owner did not know existed. It can also reveal sudden changes in pass/fail patterns and unauthorized sources attempting to use the domain.

But an aggregate report is not a per-recipient inbox-placement report. It does not tell you that a particular user saw a message, nor does a high DMARC pass rate prove that the stream has healthy reputation. Use reports to answer identity questions:

• Which sources claim to send for this domain?
• Which sources pass SPF?
• Which DKIM domains are validating?
• Which paths align for DMARC?
• Which failures are growing over time?

Then use provider-specific deliverability evidence for inbox-placement and reputation diagnosis. Mixing those jobs is how teams end up “fixing DMARC” for what is actually a complaint or reputation problem.

Worked example

A customer forward an Acme newsletter from one mailbox to another.

• 1. The original sender used From: newsletter@acme.example
• 2. The sending provider used an aligned DKIM signature with d=acme.example
• 3. The forwarder retransmits the message from an IP that is not in Acme's SPF authorization path
• 4. SPF for the forwarded hop does not produce an aligned pass
• 5. The content covered by the DKIM signature remains intact, so DKIM still passes for acme.example
• 6. Because that DKIM identity aligns with the Author domain, DMARC can pass

This is why the correct operator question is not "Did SPF pass?" It is "Did at least one aligned authentication path pass?"

A practical DMARC rollout

Six steps, in order.

1. 01
   A practical rollout sequenceA reliable rollout is an inventory project before it is an enforcement project.
2. 02
   1. Inventory every legitimate senderList services that send with your domain: marketing, transactional, support, invoicing, authentication, recruiting, internal systems, and agencies. For each source, record: - visible From domain; - DKIM d= domain and selector; - SPF / return-path domain; - whether DKIM survives the actual production path; - whether SPF or DKIM currently aligns.
3. 03
   2. Make DKIM alignment the durable pathSPF alignment can be valid, but it depends on the SMTP envelope path and is vulnerable to forwarding. For important third-party senders, configure provider support for DKIM signing with your aligned domain when available.
4. 04
   3. Publish DMARC in monitoring modeStart with a valid policy and aggregate reporting. Use reports to discover legitimate sources you missed, authentication drift, and unauthorized usage. Do not interpret one failed source as a reason to weaken authentication globally. Fix the sender identity or remove the unauthorized source.
5. 05
   4. Test enforcement without losing observabilityBefore asking receivers to quarantine or reject failing mail, verify that important streams have a stable aligned path and that indirect mail flows have been considered. In a 2026 implementation, review the current RFC 9989 test-mode behavior and the actual behavior of the mailbox providers important to your audience rather than copying a pct= rollout recipe from an older guide.
6. 06
   5. Move to the policy that matches your risk toleranceUse a stricter policy only after mail is authenticated. An incomplete sender inventory can make p=reject cause an outage.

What passes and what does not

• Older DMARC guides commonly recommend moving from p=none to p=quarantine; pct=10, then gradually increasing pct toward 100. That advice came from RFC 7489
• RFC 9989, published in May 2026, removed the `pct` tag. Operational experience showed inconsistent percentage handling. The new standard introduces a t test-mode tag. With t=y, a domain owner does not want the declared enforcement policy applied while testing. The standard also moved aggregate reporting into RFC 9990 and replaced the older Organizational Domain discovery model with the DNS Tree Walk
• This does not mean every provider, BIMI program, validator, or deployment guide instantly changed its documentation in May 2026. During a transition, you can encounter current provider guidance that still refers to legacy DMARC vocabulary. Treat that as an interoperability fact to verify, not a reason to pretend the standards update did not happen

Common mistakes

1. Treating SPF=pass as equivalent to DMARC=pass without checking alignment
2. Requiring both aligned SPF and aligned DKIM for DMARC to pass. One aligned passing path is sufficient
3. Publishing p=reject before finding every legitimate sender
4. Copying a pre-2026 pct= rollout pattern without noticing RFC 9989 removed the tag
5. Assuming DMARC prevents lookalike-domain phishing
6. Assuming a DMARC pass guarantees inbox placement
7. Reading one vendor's DMARC status without looking at the actual visible From, envelope, and DKIM identities

Troubleshooting

• ›
  Troubleshooting DMARC failuresWhen DMARC fails, inspect the message identity chain in this order: 1. What is the actual visible From domain? Do not diagnose a return-path domain as if it were the Author domain. 2. What did SPF authenticate? Record the domain that was checked, the result, and the sending IP. 3. Which DKIM signatures validated? A message can have multiple signatures. Record each valid d= domain. 4. Does either successful identity align? Compare domains under the configured strict or relaxed mode. 5. Was the message forwarded or modified? Forwarding can change SPF conditions; intermediaries can also modify content and break DKIM. 6. Which policy record did the receiver discover? With modern DMARC, policy discovery may involve a DNS Tree Walk. 7. Is the issue authentication or delivery policy? A DMARC pass does not guarantee inbox placement, and a receiver can make local handling decisions beyond DMARC.

Questions we get asked