# Domain-based Message Authentication, Reporting, and Conformance (DMARC)

> An alignment, policy, and reporting layer that connects SPF or DKIM to the visible From domain.

- **Category:** Authentication
- **Updated:** July 2026
- **Canonical page:** [https://emailbump.com/glossary/dmarc](https://emailbump.com/glossary/dmarc)

## Definition

DMARC evaluates the domain in the visible RFC 5322 From header against authenticated SPF and DKIM identities. The message passes when at least one mechanism passes and its domain aligns with the author domain.

A published DMARC record can request monitoring, quarantine, or rejection for failures and can direct aggregate reports to the domain owner. In 2026, RFC 9989 replaced RFC 7489; aggregate and failure reporting are specified separately in RFC 9990 and RFC 9991.

## Why it matters

DMARC makes direct spoofing of an exact domain harder and gives owners visibility into systems sending as their domain. It does not stop lookalike domains, display-name deception, compromised authorized accounts, or every form of phishing.

## How it works

1. The receiver extracts the visible From domain.
2. SPF and DKIM are evaluated normally.
3. The receiver checks whether a passing authenticated domain aligns with From.
4. For failures, the receiver considers the discovered DMARC policy alongside local filtering rules and produces reporting data.

## Example: A monitoring record

```text
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

v=DMARC1       protocol version
p=none         monitoring policy
rua=...        aggregate report destination
```

## Common mistakes

- Moving to rejection before identifying every legitimate sender.
- Assuming SPF and DKIM passes count when neither domain aligns with From.
- Publishing more than one DMARC record.
- Following older rollout advice built around the removed pct tag.

## Key takeaways

- One aligned SPF or DKIM pass produces a DMARC pass.
- Use reporting to inventory senders before enforcement.
- Treat DMARC as exact-domain protection, not a complete phishing defense.

## Related definitions

- [Email authentication](https://emailbump.com/glossary/email-authentication.md) — The DNS and cryptographic mechanisms receivers use to verify sending identities and domain authorization.
- [Sender Policy Framework](https://emailbump.com/glossary/spf.md) — A DNS policy that authorizes IP addresses to use a domain in the SMTP envelope.
- [DomainKeys Identified Mail](https://emailbump.com/glossary/dkim.md) — A cryptographic signature that lets a domain take responsibility for selected message content.
- [Sender name](https://emailbump.com/glossary/sender-name.md) — The display name shown beside an email address to identify the person, brand, or team sending.

## Related guides

- [Gmail reputation-based bounces: diagnose, contain, and recover](https://emailbump.com/blog/gmail-reputation-bounces.md) — An incident guide to Gmail 4.7.x and 5.7.x responses, sender-level classification, safe retries, Postmaster Tools, abuse containment, and reputation recovery.
- [How to check your email domain reputation—and improve it](https://emailbump.com/blog/check-email-domain-reputation.md) — A practical guide to authenticated sending domains, Google Postmaster Tools, reputation signals, investigation workflows, stream separation, and recovery.
- [Why Gmail shows “via”—and how to fix your sender identity](https://emailbump.com/blog/gmail-via-label-dkim-alignment.md) — A practical guide to the domains behind Gmail’s via label, aligned DKIM and SPF, third-party senders, forwarding, and the headers that reveal the real problem.
- [DMARC in 2026: how it fights phishing—and where it stops](https://emailbump.com/blog/dmarc-phishing-protection.md) — A practical guide to domain alignment, reporting, safe enforcement, and the phishing attacks DMARC cannot solve on its own.

## Primary sources

- [RFC 9989: DMARC](https://www.rfc-editor.org/rfc/rfc9989)
- [RFC 9990: DMARC aggregate reporting](https://www.rfc-editor.org/rfc/rfc9990)