DMARC: understand alignment, policy and reports

This chapter helps you understand a DMARC record, distinguish message failures from DNS findings and choose a policy suited to your sending operation.

What DMARC does

Domain-based Message Authentication, Reporting and Conformance adds three related functions to SPF and DKIM:

Without DMARC, SPF can pass for an unrelated SMTP sender domain and DKIM can be valid for an unrelated signing domain without confirming the visible From: domain. Both checks and other filters remain possible without DMARC. What is missing is this published connection, including the DMARC policy and requested reports.

DMARC concerns the authorised use of a domain. It does not confirm a person's identity or their authority to request a bank transfer. Lookalike domains, freely chosen display names, misused legitimate accounts and harmful content remain separate problems. A DMARC pass is neither a general security assessment nor a promise of inbox delivery.

The current basis is RFC 9989, published in May 2026 as a Proposed Standard. It replaces RFC 7489 and RFC 9091. Aggregate reports are described in RFC 9990, failure reports in RFC 9991. Older guides and recipients may still use different details.

Alignment: which domain comparison matters?

The starting point is the domain in the visible From: header, called the Author Domain in the standard. It is compared with a successfully authenticated domain:

• For SPF, the checked MAIL FROM identity counts. A separate HELO check is insufficient. For an empty SMTP reverse path, SPF defines a substitute identity using postmaster and the HELO domain.
• For DKIM, d= from a valid signature counts. A message may have several DKIM signatures; one successful aligned signature suffices for the DKIM path.

The Return-Path header can show the SMTP return address recorded at delivery. But the SPF identity originates in the SMTP transaction. An arbitrary header field is no substitute for trusted receiving data. The section on header findings explains this boundary.

DMARC PASS = (SPF pass AND SPF aligned) OR (DKIM pass AND DKIM aligned)

Forwarding can cause SPF to fail because of the new connecting IP address. DKIM may survive as long as the covered message parts are not invalidly changed under the chosen canonicalisation. ARC can pass on earlier verification results; trust in the intermediaries and the recipient's rules determine their treatment. ARC does not repair a signature.

An alias strategy separates addresses for different services; it is an independent measure. BIMI has further prerequisites, including an enforced DMARC policy. Such a policy alone does not guarantee logo display; the BIMI Group points to additional recipient criteria.

DMARC records: current tags and historical parameters

For example.com, an explicit DMARC TXT record is sought at _dmarc.example.com. The version identifier v=DMARC1 must come first. An explicit p= policy is recommended. If it is absent from an otherwise valid record, RFC 9989 applies p=none. The following example also requests aggregate reports; the address is a placeholder and must be set up for actual use:

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

fo=0 requests a failure report when neither method produces an aligned pass. fo=1 requests one when at least one method does not produce an aligned pass, even if the message passes DMARC through the other path. fo=d and fo=s concern DKIM and SPF failures respectively, regardless of alignment. Separate multiple permitted values with colons; 0 and 1 must not be combined. Recipients are not obliged to fulfil every report request.

t=y is not a universal rollback switch. Under the new standard, it treats reject as quarantine and quarantine as none; none remains unchanged. It does not turn off report generation. Older recipients may ignore the tag, and DNS caches can delay changes. The definitions are in RFC 9989, section 4.7 and Appendix C.5.

The three policy values

p=none: observe without requesting special DMARC treatment. Other filters may still reject messages or treat them as spam. A suitable rua destination lets you request reports.

p=quarantine: treat failures as suspicious. At the recipient, this may mean quarantine or a spam folder. It does not guarantee a particular folder or a particular form of access to the message.

p=reject: request rejection. This can also affect legitimate indirect sending routes. It is not a universal target for every domain. RFC 9989 advises against this policy for domains used for general-purpose email whose users may post to mailing lists.

A domain that neither sends nor receives

A domain that neither sends nor receives is a different use case from one with user mailboxes. The following schematic zone example documents this intended non-use:

_dmarc.parked.example.  TXT  "v=DMARC1; p=reject; sp=reject"
parked.example.         TXT  "v=spf1 -all"
parked.example.         MX   0 .

The trailing dots identify fully qualified DNS names here. DNS interfaces may expect other input formats. This example has not been published or tested in practice.

Distinguish aggregate reports from failure reports

Aggregate reports: sending patterns observed by recipients

Aggregate reports under RFC 9990 summarise a reporting recipient's observations for a period in XML. The period is often one day. They include source IP addresses, message counts, published policy, authentication, alignment and treatment. rua= specifies the requested recipients of these reports.

The following XML is an invented, incomplete illustration with two groups, not a received report or a complete valid report file. It omits report metadata, the reporting period, the published policy and other record fields, among other things.

<record>
  <row>
    <source_ip>203.0.113.1</source_ip>
    <count>1524</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
</record>
<record>
  <row>
    <source_ip>198.51.100.42</source_ip>
    <count>3</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
</record>

The first group represents 1524 messages with successful aligned authentication paths. This does not establish that their content is legitimate or harmless. The second group shows three failures; these could be abusive messages, a forgotten legitimate service or an indirect sending route. Here, disposition=none reports no special DMARC policy action; it proves neither inbox placement nor the recipient's approval of the content.

For real reports, always consider the source, period, reported policy, count and possible policy overrides together. Distinguish separate raw results under auth_results from the DMARC evaluation under policy_evaluated. Reports cover only reporting recipients and their observations. Missing reports therefore prove neither an absence of sending nor error-free authentication. RFC 9990, section 3.1

External reporting destinations need authorisation

If a reporting destination lies outside the relevant organisational domain, DMARC provides for DNS authorisation on the report recipient's side. The domain from which the policy actually originates also matters; with inherited policies, it need not be the visible sender domain. Adding someone else's address to rua is not enough to establish an authorised external destination under the protocol. The procedure is described in RFC 9990, section 4 and is also used for ruf.

Failure reports: targeted diagnosis with more content

Failure reports under RFC 9991, often called forensic reports, may contain details of individual failures. Depending on the report, these may include header fields, addresses and message content. They are not a complete raw email archive and are not supplied by every recipient.

Aggregate reports also contain operational data and must fit the chosen processing purpose. The technical possibility of reporting establishes neither blanket legal permission nor a blanket prohibition.

Which tool answers which question?

These examples describe different tasks. A DNS snapshot is not a DMARC report archive, and a DMARC aggregate report is not a domain report produced by Wolf-Agents.

Introduce a policy based on actual sending operations

First establish your sending operation: which services may send? Which domains do they actually use in MAIL FROM, d= and From:? Which forwarding routes and mailing lists matter? Only then can you determine a policy suited to the operation.

Investigate common DMARC errors

RFC 9989, section 4.10 governs policy and organisational domain discovery. A subdomain policy does not prevent misuse of an already legitimately authorised or compromised sending service.

The Email Security Check can show a snapshot of publicly queryable configuration. That may suffice for an initial DNS question. It does not confirm an actual message, a complete sender list, report delivery or uniform adoption of the new standard by all recipients.

Technical and legal limits

Document the chosen policy, its rationale, the sending routes examined and responsibility for reports. A DMARC record or high pass rate does not establish comprehensive security or compliance.

The following legal references concern Germany and the EU:

• Section 30 BSIG requires appropriate and proportionate risk management measures for entities in scope, not a blanket requirement for a particular DMARC policy on every domain.
• BSI TR-03182 covers email authentication; TR-03108 complements it for transport. A DNS check does not replace examination of a whole guideline and its operational requirements.
• Article 32 GDPR concerns technical and organisational measures appropriate to the risk. DMARC does not encrypt communication. For reports, purpose, included data, recipients and access need separate assessment.

A guide for your sending service

Use the available guide for your actual service. The DMARC policy is published through DNS; the identities and signatures needed for a pass must also match the respective sending route.