# DMARC meaning in networking > 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. ## 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](https://datatracker.ietf.org/doc/html/rfc9989) 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](https://datatracker.ietf.org/doc/html/rfc9989#section-4.4) 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`](https://datatracker.ietf.org/doc/html/rfc9989#section-5.4). For a broader introduction to the protocol and rollout, see the [DMARC learning hub](/learning/dmarc). ![Decision flow showing that DMARC evaluates aligned SPF or DKIM before a receiving mail system considers the published policy](/images/editorial/dmarc-meaning-in-networking/dmarc-meaning-in-networking-decision-flow.webp "1200x676") *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](https://datatracker.ietf.org/doc/html/rfc9989#section-8). 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](https://datatracker.ietf.org/doc/html/rfc9989#section-4.5). ```text 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](https://datatracker.ietf.org/doc/html/rfc9989#section-4.7). 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](https://www.rfc-editor.org/rfc/rfc1034.html). 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](/learning/dmarc-fo-tag). ## 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"](/learning/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](/tools/dmarc) 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](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=dmarc_fundamentals&utm_content=dmarc-meaning-in-networking) ## Sources and further reading - [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://datatracker.ietf.org/doc/html/rfc9989) - [RFC 1034: Domain names, concepts and facilities](https://www.rfc-editor.org/rfc/rfc1034.html) - [Palisade DMARC checker](/tools/dmarc) ## Frequently asked questions ### 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.