DMARC explained: alignment, reports, and a careful path to enforcement

Nov 5, 20267 min read

DMARC flow connecting authenticated domains, From alignment, and domain policy

An email can pass SPF or DKIM and still fail to authenticate the sender identity a recipient sees. Domain based Message Authentication, Reporting, and Conformance, or DMARC, connects those authentication results with the visible From domain. It also lets the domain owner publish a handling preference for failed validation and request reports about mail using that domain.

For a campaign team, DMARC is both a security control and an operational discovery tool. Reports can reveal an forgotten billing service, a provider signing with an unrelated domain, or unauthorized use of your identity. The safest rollout starts with observation and remediation rather than immediately requesting rejection for every failure.

The standard changed in 2026

The current protocol specification is RFC 9989, published in May 2026. Aggregate reporting is described separately in RFC 9990, with failure reporting in RFC 9991. Together these replace the older RFC 7489 document that many tutorials still cite.

The updated protocol retains the familiar v=DMARC1 record version and the policy values none, quarantine, and reject. It changes policy discovery and organizational domain determination to a bounded DNS tree walk. It also removes the old pct sampling tag and adds a test mode tag, t. Real recipient implementations and vendor instructions may still reflect the older specification, so deployment needs to account for mixed behavior.

Do not treat a new optional tag as a universal safety switch. An older receiver may ignore it. The practical advice remains to publish explicit records, verify actual traffic, and choose policy changes based on evidence about your legitimate mail streams.

Understand the visible From identity

DMARC evaluates the domain in the message's From header. It does not authenticate the display name alone and does not use Reply-To as the primary author identity. If your newsletter displays [email protected], DMARC asks whether an authenticated identifier from SPF or DKIM aligns with example.com.

This matters because a provider may use its own return path for bounces and its own signing domain by default. Those identifiers can authenticate successfully for the provider while remaining unrelated to your From domain. Adding a recognizable sender name does not establish alignment. Configure the provider's customer domain authentication and inspect a received message to confirm the result.

DMARC authenticates domain use, not whether a particular individual authorized the message or whether its content is truthful. A compromised account on an otherwise authenticated domain can still send harmful mail. Keep account security and recipient protection alongside domain authentication.

A pass needs authentication and alignment

A message can pass DMARC when either SPF passes with an aligned envelope domain or a valid DKIM signature has an aligned signing domain. Both are not required for a particular message to pass, but configuring both provides resilience and is important for current bulk sender requirements.

Strict alignment requires identical domain names. Relaxed alignment requires the same applicable organizational domain. In a conventional domain setup, bounce.mail.example.com and example.com may align in relaxed mode. An unrelated service domain such as example.net does not align merely because the same organization uses both names.

The new DNS tree walk gives policy records more influence over organizational boundaries. Complex delegated subdomains need deliberate configuration, especially when different teams or customers control parts of the namespace. Avoid reducing alignment to a naive last two labels comparison. Domain structures and published policies can be more complicated than that.

Start with a monitoring record

A basic record for a documentation domain could be published at _dmarc.example.com:

v=DMARC1; p=none; rua=mailto:[email protected]

Create an actual report receiving mailbox or reporting service before using your own version. The rua address requests aggregate feedback from participating receivers. The p=none value expresses no specific handling preference for failed messages; receivers still apply their normal filtering and security policies.

Publish one valid DMARC policy at the relevant lookup name. Several competing policy records can prevent reliable discovery. Check whether your DNS interface expects _dmarc or the full name, and verify the result externally after saving. Keep explicit coverage for the organizational domain and each author domain you use rather than assuming a provider dashboard has protected every namespace automatically.

Read reports as grouped evidence

Aggregate reports usually arrive as XML attachments, often compressed. They summarize sending IPs, message counts, author identifiers, raw authentication results, and policy evaluation. A reporting service can turn these records into useful groups without requiring you to inspect every XML element by hand.

Start by mapping observed sources to your sender inventory. A high volume source with failing alignment is more urgent than a single unusual record, but low volume systems can still be business critical. Password recovery, invoice reminders, and support escalations may send infrequently and therefore be absent from a short monitoring window.

Distinguish raw SPF or DKIM results from aligned policy results. A report can show successful authentication in one section and a failing DMARC related result in another because the identifiers do not align. Also examine override reasons: a receiver may treat a known forwarded message differently from your requested policy.

Reports are not a complete inbox placement dashboard. Not every receiver sends them, delivery can be delayed, and counts cover the reporting provider's observations rather than all your mail. Protect the report mailbox and use a safe parser, because compressed and XML attachments are untrusted input.

Fix legitimate failures before enforcement

For each known sender, confirm which From, envelope, and signing domains it uses. Enable custom DKIM signing or an appropriate custom envelope identity through the provider's supported process. Then send tests and confirm alignment in headers added by the receiving system.

Do not authorize unknown IPs merely because they appear in reports. Determine whether a source is legitimate through ownership records, provider logs, and actual message samples. An unauthorized source should remain unauthorized; reports help reveal it rather than provide a list of entries to add blindly.

Cover a representative sending cycle before changing policy. A business with monthly billing, quarterly reports, and seasonal campaigns needs more than a day of observation. Assign each remediation to an owner and record the expected configuration. Retest when a provider changes regions, rotates selectors, or introduces a new sending stream.

Choose quarantine and reject carefully

p=quarantine expresses that failing mail is suspicious. p=reject expresses that validation failures indicate unauthorized domain use. The receiver still makes the final handling decision, so neither value guarantees a precise outcome at every mailbox.

For a dedicated campaign or transactional domain with a well understood pipeline, enforcement can reduce successful use of that exact domain by unauthorized senders. For a general employee domain whose users participate in mailing lists, restrictive policy can interfere with legitimate indirect mail. The updated standard explicitly discusses these risks and cautions against blanket rejection policies for general purpose domains.

A cautious transition observes traffic under none, fixes known failures, evaluates quarantine where appropriate, and assesses the impact before considering reject. Separate domains or subdomains can give different streams clearer operational boundaries. Do not use a universal calendar schedule or assume every domain should reach reject as quickly as possible.

Avoid relying on legacy percentage sampling

Older guidance often recommends pct=10 or pct=25 as a gradual rollout. RFC 9989 removes this tag because implementations did not apply intermediate percentages consistently. You may still encounter it in existing policies or provider specific BIMI instructions, but it should not be your default mechanism for safe enforcement changes.

The newer t=y signal asks supporting receivers to treat a declared policy as testing. An older receiver can ignore that signal and apply the policy you published. That makes a record containing reject plus a testing tag unsuitable as an assumed harmless trial across every mailbox. Start with none, use controlled domains where possible, and validate provider specific behavior before adopting newer controls.

Forwarding and mailing lists deserve attention

A forwarder delivers from its own IP, which can break SPF for the original envelope identity. DKIM can survive if the signed content remains intact. A mailing list that modifies the body or signed headers can invalidate that signature too.

Some intermediaries rewrite the From identity or use additional authentication information to improve handling, but behavior is not uniform. Test representative indirect paths and explain the tradeoff to teams affected by stricter policies. Do not weaken all authentication merely to accommodate one unexamined failure, and do not ignore real users whose expected mail disappears after a policy change.

Maintain reports after the rollout

DMARC is an ongoing configuration, not a record to publish and forget. Monitor new sending sources, increased failure counts, and changes in alignment. Review access to DNS, provider accounts, and delegated subdomains because those controls influence who can authenticate domain use.

Before a campaign, combine authentication checks with the email spam checker for an editorial review and the HTML email preview for message readability. These browser tools do not validate DMARC or promise delivery. Ternloop supports the campaign workflow while your domain authentication establishes the selected sending identity.