What does DMARC stand for and what does each part mean?

What are the requirements?

The domain owner publishes a DMARC TXT record

RFC 9989 defines a DMARC policy record as a DNS TXT record at _dmarc. followed by the domain name. The record begins with the v=DMARC1 version tag and includes a p= tag that states the requested policy.

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

Use example values only. Do not copy another organization's report address or publish a report destination that you do not control.

The p= value can be none, quarantine, or reject. none asks the receiver to take no specific action based on DMARC failure, while quarantine and reject express progressively stronger requested handling. The standard does not say that a domain owner must begin at one policy or move through them on a fixed schedule.

Message authentication must align with the visible domain

DMARC uses SPF and DKIM results. Under RFC 9989's DMARC evaluation rules, a message passes if either SPF or DKIM produces a passing result with an identifier aligned with the Author Domain.

Alignment means the authenticated identity is compared with the visible From: domain. The default alignment mode is relaxed. Domain owners can request strict alignment with the adkim tag for DKIM or the aspf tag for SPF. Strict alignment is a policy choice, not a universal requirement.

DMARC does not require both SPF and DKIM to pass. One aligned pass is sufficient for DMARC to pass. A message can therefore pass DKIM but fail SPF and still pass DMARC if the DKIM identity aligns with the visible domain.

The record can request aggregate reports

A domain owner can request aggregate reports with the rua tag. RFC 9990 specifies that an aggregate report is an XML document and that a receiver can send it to a destination declared in the DMARC record.

Aggregate reports help identify which sources claim to send using a domain and how receivers evaluated their mail. They are evidence about reported traffic, not a complete inventory of every message sent by every system. Receiver participation, report timing, and report coverage vary.

Failure reporting is a separate part of the current DMARC specification. RFC 9991 defines DMARC failure reporting and obsoletes the corresponding RFC 7489 material. Do not assume that a failure-report destination will receive an individual report for every failed message.

The requested policy applies to the domain and can cover subdomains

The p= tag states the requested policy for the domain where the DMARC record is found. The sp= tag can state a separate requested policy for subdomains. If a domain owner needs to decide whether subdomains inherit a policy or need a different one, see how the DMARC sp tag works.

A receiver evaluates the applicable DMARC record and message authentication before it considers the requested policy. Publishing p=reject does not repair an SPF authorization, create a DKIM signature, or make a third-party sender align with the visible domain.

When does the requirement take effect?

RFC 9989 was published in May 2026 as an IETF Proposed Standard. It is the current core DMARC specification and obsoletes RFC 7489 and RFC 9091. RFC 9990, also published in May 2026 as a Proposed Standard, defines aggregate reporting. RFC 9991, published at the same time, defines failure reporting.

There is no single protocol-wide date on which every domain must publish DMARC. A domain owner chooses whether to deploy the protocol unless a mailbox provider, customer contract, regulator, or other separate rule imposes a requirement. Those external requirements have their own scope, dates, and enforcement terms.

For existing implementations, treat RFC 9989 as the controlling core source rather than relying on the obsolete RFC 7489. The record format and policy concepts remain familiar, but the current standard is the source to use when interpreting current protocol behavior.

How do I implement the requirement?

1. Identify the domain in the visible From: address

List the domains your organization uses in the visible From: field for transactional, marketing, support, and employee mail. DMARC protects the Author Domain in that field, so a return-path domain alone is not enough to determine the DMARC policy you need.

2. Confirm SPF or DKIM can align

For each sending path, confirm that SPF or DKIM can produce a passing identity aligned with the visible From: domain. A sending platform may authenticate a domain that it owns by default, which may leave its result unaligned with your domain.

Use the strictness settings only after you understand the sending paths that need to pass. The adkim and aspf tags change alignment evaluation. They do not make an unauthenticated message valid.

3. Publish a monitoring record

Start with a valid DNS TXT record that includes v=DMARC1 and an appropriate p= value. A reporting address in rua gives participating receivers a destination for aggregate reports.

Check the DNS record through the authoritative DNS service and at least one public resolver after publishing it. DNS visibility does not confirm that a sender is using the intended authentication setup.

4. Review reported sources before requesting stronger handling

Use aggregate reports to identify legitimate sending sources and investigate sources that fail SPF, DKIM, or alignment. Correct the sending configuration before increasing policy strength.

A p=none record is still a DMARC policy record. It requests no specific receiver action for failure, so it is useful while the domain owner gathers evidence. Move to quarantine or reject only when the organization has reviewed the production paths that send with the protected domain.

How do I validate compliance?

Validate DMARC compliance at four layers, from the DNS record through to a delivered message.

• DNS: confirm that _dmarc.yourdomain.com returns one syntactically valid DMARC TXT record from the authoritative DNS service and a public resolver.
• Vendor: confirm in each sending platform that SPF or DKIM has been configured for the domain used in the visible From: address.
• Message: send a real message through each production path and inspect its raw headers. Confirm that the receiver's DMARC result is pass and that the passing SPF or DKIM identity aligns with the visible From: domain.
• DMARC: review aggregate reports after they accumulate to identify reported sources and recurring authentication or alignment failures.

Turn a valid record into an enforcement plan

A published record answers whether a public DMARC policy is visible. It does not show which production sources still fail alignment, which source needs remediation first, or when the domain is ready for a stronger policy.

Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and creates prioritized remediation tickets. It can propose the next policy step when the evidence supports it. Your team reviews the evidence and applies the DNS change.

Start with Palisade

Palisade does not autonomously change your DMARC policy, control a receiver's private mail decision, or guarantee delivery or inbox placement.