What is DMARC and how does it work?

DMARC is an email-authentication protocol that validates whether SPF or DKIM passed with a domain aligned to the visible From domain. The domain owner publishes a DNS policy record, and a receiving mail system can use that policy when DMARC fails.

Is DMARC really necessary?

No. DMARC is not a universal requirement of networking. It is needed when a domain owner wants DMARC's validation, policy, and reporting functions, or when a receiver's current sender rules require it. A domain that fully participates in DMARC must publish a policy record and send aligned authenticated mail.

What is an example of a DMARC?

An example is v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com, published as a TXT record at dmarc.yourdomain.com. It identifies the record as DMARC, requests no special handling preference for failures, and requests aggregate reports at the listed address.

What is the difference between DNS and DMARC?

DNS is the system that stores and answers queries for domain-related records. DMARC is an email-authentication protocol that uses a DNS TXT record to publish a domain owner's policy and reporting preferences.

Does DMARC replace SPF or DKIM?

No. DMARC uses SPF and DKIM authentication results. A DMARC pass requires an SPF or DKIM pass that aligns with the visible From domain.

Back to Learning Center Email Authentication

DMARC meaning in networking

By Samuel ChenardAugust 13, 20267 min read

Ask AI to explain

In brief

DMARC meaning in networking: a DNS-based email-authentication protocol that validates authorized use of a From domain and requests handling.

DMARC means Domain-based Message Authentication, Reporting, and Conformance. In networking, it is an email-authentication protocol that lets a domain owner publish a DNS policy for messages that use its visible From domain. A receiver evaluates whether SPF or DKIM passed with an aligned domain, then can consider the domain owner's requested handling for a DMARC failure. The receiver still makes its own delivery decision.

At a glance

Quick takeaways

DMARC is an email protocol, not a replacement for DNS.
A DMARC pass needs an aligned SPF pass or DKIM pass for the visible From domain.
The DMARC policy record is a DNS TXT record, usually published at _dmarc.yourdomain.com.
p=none, p=quarantine, and p=reject express a domain owner's requested handling for DMARC failures.
A receiving mail system can use the request in its filtering decision, but it does not have to follow it exactly.
A DMARC pass does not guarantee inbox placement or prove that every future message will authenticate.

How DMARC works in a network

The IETF DMARC standard defines DMARC as a protocol through which an email's Author Domain owner can validate use of that domain, publish a handling preference for failed validation, and request reports about its use.

The Author Domain is the domain in the message's visible From: address. DMARC checks whether the message has either:

An SPF pass whose authenticated domain aligns with the Author Domain.
A DKIM pass whose signing domain aligns with the Author Domain.

Alignment connects the passing authentication identifier to the domain a recipient sees in From:. Under relaxed alignment, the domains share the same organizational domain. Under strict alignment, they must be identical. RFC 9989's DMARC overview defines both modes and explains that a DMARC pass requires a passing, aligned identifier.

A receiver looks up the applicable DMARC policy in DNS, evaluates SPF and DKIM, then determines a DMARC result. If the result is a failure, the published policy can inform the receiver's handling decision. The receiver can also use reputation, content filtering, and local policy. RFC 9989 requires receivers not to reject mail solely because a domain publishes p=reject.

For a broader introduction to the protocol and rollout, see the DMARC learning hub.

Decision flow showing that DMARC evaluates aligned SPF or DKIM before a receiving mail system considers the published policy — Source: Palisade.

When the meaning changes in practice

DMARC has a narrow job: validate authorized use of the visible From domain for an individual message. It does not certify a sender as trustworthy, prevent every type of phishing, or guarantee placement in a recipient's inbox. The IETF standard says a DMARC pass validates authorized use of the Author Domain for that message, but a receiver can still quarantine or reject it under its own policies.

The practical decision rule is:

If SPF or DKIM passes with an aligned domain, DMARC passes.
If neither SPF nor DKIM produces an aligned pass, DMARC fails when an applicable policy record exists.
If no applicable DMARC policy record exists, the DMARC result is none, rather than pass or fail.

A domain can choose not to publish a DMARC record. That means it does not participate in DMARC validation through a policy record. It does not mean that SPF, DKIM, or a receiver's own anti-abuse systems stop operating.

DMARC is not universally necessary for every networked system. It is necessary when your organization needs the protocol's domain-use validation, policy publication, or reporting framework. A domain owner that wants full DMARC participation must publish a DMARC policy record, send aligned authenticated mail, and receive and analyze aggregate reports under RFC 9989's conformance requirements. A team should also check the current requirements of each mailbox provider it sends to.

A worked DMARC record example

A DMARC policy record is stored as a DNS TXT record whose name begins with _dmarc. RFC 9989 specifies _dmarc.example.com as the lookup pattern.

Technical exampletext

Host: _dmarc.yourdomain.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

This is an illustrative example. Do not publish the reporting address or record value unchanged. Use the addresses and policy approved for your domain.

The record has three useful parts:

v=DMARC1 identifies the TXT value as a DMARC policy record. It must be the first tag.
p=none expresses no handling preference for messages that fail DMARC. It is often used while a team collects information about legitimate sources.
rua=mailto:dmarc-reports@yourdomain.com requests aggregate feedback reports at that address.

The policy can instead be p=quarantine, which treats DMARC failures as suspicious, or p=reject, which expresses that failures indicate unauthorized use. The registered p values and their meanings are defined in RFC 9989.

DNS and DMARC are therefore different layers. DNS is the distributed naming and record-query system. RFC 1034 describes DNS resource records, name servers, and resolvers. DMARC is one email-authentication protocol that uses a DNS TXT record to publish its policy. DNS can store many other record types and supports many services besides email.

A DMARC record lookup shows what is publicly published. It does not show whether each production application signs mail correctly or whether its SPF identifier aligns. For related tag detail, see what the DMARC fo tag means.

What to check next

Choose the next check based on the evidence you have:

If you only have a domain name, look up its public DMARC record and read the hostname, policy, and reporting address.
If you have a delivered message, inspect its authentication results to confirm whether SPF or DKIM passed with alignment.
If you are considering a stronger policy, use aggregate reports to identify legitimate sending sources before changing DNS.
If a message already bounced, compare the bounce with message-header evidence and see how to fix "email rejected per DMARC policy".

Check DNS through the authoritative server and at least one public resolver after a DNS change. Then validate the vendor's sending status and send a real message through the production path. As aggregate reports accumulate, use them to find sources that still fail DMARC. A green DNS result alone does not prove that an application is signing mail or using the intended return path.

Check the published DMARC record

If you have a domain name and want to confirm what the public DNS currently publishes, inspect the record before making a policy decision.

Check the DMARC record

A record lookup cannot prove why a specific receiver accepted or rejected a message, whether every production sender aligns, or how future mail will be placed. Once the lookup exposes an ongoing need to inventory sending sources and prioritize alignment work, Palisade's DMARC software can analyze DMARC aggregate-report data, identify sources and alignment issues, and propose the next policy step for human review. It does not change the DMARC policy or control a receiver's delivery decision.

Start with Palisade

Evidence