# What is DMARC in cyber security?

> DMARC in cyber security is a DNS-published protocol that authenticates a domain's email, sets a policy for failures, and reports abuse back to the owner.

DMARC (Domain-based Message Authentication, Reporting Conformance) is an email authentication, policy, and reporting protocol that a domain owner publishes in DNS. It builds on SPF and DKIM, ties their results to the visible From: domain, tells receiving mail systems how to handle messages that fail that check, and sends reports back to the domain owner. In cyber security terms, DMARC is the control that stops attackers from sending mail that appears to come from a domain they don't own.

## Quick takeaways

- DMARC stands for Domain-based Message Authentication, Reporting Conformance, per [dmarc.org's own definition](https://dmarc.org/).
- It doesn't replace SPF or DKIM. It adds a policy layer and a reporting layer on top of them.
- The policy is published as a DNS TXT record, so any domain owner can implement it at no licensing cost.
- DMARC became an IETF Standards Track protocol in May 2026, formalized across three RFCs that obsolete the original 2015 specification.
- A domain's DMARC record tells receivers what to do with a message that fails authentication and alignment: nothing, quarantine, or reject.
- DMARC is a domain-level control. It authenticates the sending domain, not the message content or the sender's intent.

## How DMARC works as a cyber security control

Email spoofing works because SMTP was never designed to verify who actually sent a message. The From: address a recipient sees can be set to anything, and until authentication protocols existed, a receiving mail server had no reliable way to check it. SPF and DKIM each solve part of that problem separately: SPF checks whether the sending server is authorized for the domain, and DKIM checks whether the message carries a valid cryptographic signature from the domain. Neither one, on its own, requires that the domain it validates match the domain the recipient actually sees in their inbox.

That's the gap DMARC closes. Per dmarc.org's definition, DMARC "builds on the widely deployed SPF and DKIM protocols, adding linkage to the author (From:) domain name, published policies for recipient handling of authentication failures, and reporting from receivers to senders, to improve and monitor protection of the domain from fraudulent email." A message only passes DMARC when SPF or DKIM passes **and** the domain that passed is aligned with the visible From: domain. A message can pass SPF and still fail DMARC if the SPF-authenticated domain doesn't match what the recipient sees.

That alignment check is why DMARC sits in the cyber security conversation rather than just the deliverability one. It closes the specific spoofing path that phishing and business email compromise campaigns rely on: sending mail that looks like it came from a trusted domain because the visible From: address says so, even though nothing about the message was actually verified against that domain.

The full mechanics of what counts as a DMARC pass and how alignment is evaluated are set out in [what DMARC is](/learning/dmarc), which covers the protocol in more depth than the definition alone.

## When DMARC's protection changes: the policy tag

DMARC's practical effect depends entirely on the policy a domain owner chooses to publish, expressed with the `p` tag in the DNS record, as defined in [RFC 9989](https://datatracker.ietf.org/doc/html/rfc9989), the current IETF Standards Track document for DMARC:

- `p=none` requests no handling change from receivers. The domain can still collect aggregate reports and use them to inventory legitimate senders before requesting stronger action.
- `p=quarantine` asks receivers to treat DMARC failures as suspicious, commonly by routing them to spam or a review queue.
- `p=reject` asks receivers not to accept messages that fail DMARC under the domain's published policy.

A receiver can weigh that request against its own local policy, so a published `p=reject` record is a strong signal, not a guarantee that every receiver rejects every failing message. Monitoring under `p=none` is what gives a domain owner the evidence to move toward `p=reject` without breaking mail that legitimate services still send on the domain's behalf, a tradeoff covered in [how DMARC affects cyber insurance underwriting](/learning/how-does-dmarc-affect-cyber-insurance) for teams evaluating DMARC as part of a broader risk posture, not just a technical control.

## A worked DMARC record

The record below is illustrative only, built to show the tag structure RFC 9989 defines. It is not a value to publish as-is; the reporting address and domain must be your own.

```text
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; adkim=r; aspf=r
```

Reading it tag by tag:

- `v=DMARC1` identifies the record as a DMARC policy.
- `p=quarantine` requests suspicious handling for messages that fail DMARC.
- `rua` names where aggregate reports should be sent, giving the domain owner visibility into which sources are sending mail as the domain and whether they're authenticating correctly.
- `adkim` and `aspf` set DKIM and SPF alignment mode. `r` (relaxed) allows a subdomain match; `s` (strict) requires an exact match.

The record answers a narrow set of questions: what policy is requested, where reports go, and how strict alignment must be. It doesn't identify which specific messages passed or failed, and it doesn't prove a receiver actually applied the requested handling. That evidence comes from the aggregate reports the `rua` address collects, not from the record itself.

![Flow diagram showing how DMARC evaluates a message: authentication and alignment check, then the policy action a domain's DMARC record requests](/images/editorial/dmarc-cyber-security/dmarc-cyber-security-flow.webp "1200x920")

*Source: Palisade.*

## The practical next step: check what your domain publishes

Because DMARC is a free, DNS-published standard with no licensing restriction, any domain owner can check what their organization currently has published, and any domain owner can implement it, per [dmarc.org's overview of who can use DMARC](https://dmarc.org/). The first diagnostic step is a lookup: does the domain have a DMARC record at all, and if it does, what policy does it request.

[Check the DMARC record](/tools/dmarc) for your sending domain to see the currently published policy, its reporting addresses, and its alignment settings. If no record exists, DMARC is providing no protection for that domain regardless of what SPF or DKIM alone are doing. If a record exists at `p=none`, the domain is likely still in the reporting and inventory phase rather than actively blocking spoofed mail.

A single lookup shows what's published in DNS at the moment you check it. It doesn't show which senders are currently failing alignment, whether legitimate mail would break under a stricter policy, or how the record has changed over time. Reading and acting on aggregate reports, covered in [are DMARC failure reports worth the trouble](/learning/are-dmarc-failure-reports-worth-the-trouble-for-your-email-security), is the layer that turns a published policy into an actively managed control.

## Move from a published record to a managed one

Publishing `p=none` and collecting reports is the easy part. Reading those reports well enough to know which sources are legitimate, which need fixing, and when it's safe to move to `p=quarantine` or `p=reject` is the ongoing work that a one-time record check can't do for you. Palisade's DMARC Agent analyzes aggregate report data, identifies sending sources with authentication or alignment problems, creates prioritized remediation tickets, and flags when a domain looks ready for the next policy stage, with a human reviewing the evidence before any change is applied.

[Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=dmarc_troubleshooting&utm_content=dmarc-cyber-security)

A record check confirms what's published today. It doesn't identify every source sending as your domain, and moving to a stricter policy without that inventory can block legitimate mail rather than just spoofed mail.

## Sources and further reading

- [dmarc.org: What is DMARC?](https://dmarc.org/)
- [dmarc.org: Status of DMARC](https://dmarc.org/)
- [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://datatracker.ietf.org/doc/html/rfc9989)
- [What is DMARC](/learning/dmarc)
- [How DMARC affects cyber insurance](/learning/how-does-dmarc-affect-cyber-insurance)

## Frequently asked questions

### What is the difference between DMARC and DKIM?

DMARC is not a replacement for DKIM. It's built on top of it. DKIM is a cryptographic signature check that confirms a message wasn't altered in transit and came from an authorized domain. DMARC takes that result (along with SPF's result), checks whether the authenticated domain lines up with the domain the recipient sees in the From: field, and applies a published policy and reporting layer on top. Per dmarc.org, DMARC "builds on the widely deployed SPF and DKIM protocols, adding linkage to the author (From:) domain name, published policies for recipient handling of authentication failures, and reporting." DKIM alone can pass without the signing domain matching the visible From: domain; DMARC is the layer that closes that gap.

### What is an example of a DMARC?

A DMARC record is a DNS TXT record published at `_dmarc.yourdomain.com`, structured with tags defined in RFC 9989. An illustrative example is `v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; adkim=r; aspf=r`, which requests quarantine handling for failing messages, sends aggregate reports to the listed address, and sets relaxed alignment for both DKIM and SPF. This is a structural example, not a value to publish directly; the domain and reporting address must be your own.

### Is DMARC really necessary?

Yes, for any domain that sends or could be spoofed for email. DMARC's stated purpose, per dmarc.org, is "to improve and monitor protection of the domain from fraudulent email," and it's free to implement with no licensing restriction. A domain with no DMARC record has no policy telling receivers what to do with mail that fails SPF or DKIM alignment, which leaves attackers free to send convincing spoofed mail using that domain's name with no mechanism in place to request that receivers reject or flag it.

### What is DMARC for dummies?

DMARC is a free email standard that checks whether a message actually came from the domain it claims to be from, and tells receiving mail servers what to do if it didn't: let it through, treat it as suspicious, or reject it. The domain owner publishes this as a DNS record, and receiving mail servers send reports back showing which senders are using the domain and whether they're passing or failing the check. It's the mechanism that lets a domain owner ask mailbox providers not to deliver mail that's pretending to be from them.