---
title: "DMARC Email Auth Guide [2026]"
description: "Learn how DMARC protects your domain from email spoofing. Covers DMARC records, policies (none/quarantine/reject), alignment, reporting, and SPF/DKIM."
protocol: "DMARC"
category: "Email Authentication"
rfc: "RFC 9989"
faq:
- question: "What is DMARC?"
answer: "DMARC (Domain-based Message Authentication, Reporting & Conformance) is an email authentication protocol that tells email receivers how to handle messages that fail SPF or DKIM checks. It builds on SPF and DKIM by adding alignment requirements and reporting, helping domain owners protect their brand from spoofing and phishing attacks."
- question: "How does DMARC work?"
answer: "DMARC works by checking whether an incoming email passes SPF or DKIM authentication and whether the authenticated domain aligns with the domain in the From header. If the email fails these checks, the receiver follows the policy you set in your DMARC record (none, quarantine, or reject). Receivers also send you aggregate reports showing authentication results for messages claiming to be from your domain."
- question: "What is the difference between DMARC, SPF, and DKIM?"
answer: "SPF verifies that an email comes from an authorized IP address. DKIM verifies message integrity with a cryptographic signature. DMARC builds on both by requiring the authenticated domain to align with the visible From address, and it gives domain owners control over what happens when authentication fails. All three protocols work together to prevent email spoofing."
- question: "What happens when DMARC fails?"
answer: "When DMARC fails, the email receiver follows the policy in your DMARC record. With p=none, the message is delivered normally for monitoring. With p=quarantine, it goes to spam. With p=reject, it's blocked entirely. DMARC failures happen when both SPF and DKIM fail, or when neither passes alignment checks."
- question: "Do I need DMARC for my domain?"
answer: "Yes, especially if you send business email or want to protect your brand. DMARC prevents attackers from sending phishing emails that appear to come from your domain. Since February 2024, Google and Yahoo require DMARC for bulk senders (Google's threshold is 5,000+ messages/day to Gmail; Yahoo publishes no volume number), but all domains benefit from the visibility and protection DMARC provides."
- question: "What is a DMARC aggregate report (RUA)?"
answer: "DMARC aggregate reports are XML files sent daily by email receivers to the address in your rua tag. They show which IP addresses sent email claiming to be from your domain, whether those messages passed SPF and DKIM, and what policy was applied. These reports are critical for understanding your email ecosystem before enforcing DMARC."
- question: "How do I set up a DMARC record?"
answer: "To set up DMARC, add a DNS TXT record at _dmarc.yourdomain.com with a value like 'v=DMARC1; p=none; rua=mailto:reports@yourdomain.com'. Start with p=none to collect reports without affecting mail flow. Once you've identified all legitimate senders and verified they pass SPF or DKIM, you can move to p=quarantine or p=reject."
---
DMARC (Domain-based Message Authentication, Reporting & Conformance) tells
email receivers how to handle messages that fail SPF or DKIM, adding the
alignment check between the authenticated domain and the visible `From:`
header that neither protocol enforces alone. Receivers apply your published
policy — `p=none` (monitor), `p=quarantine` (spam), or `p=reject` (block) —
and send daily aggregate reports so you can see who is sending as your domain.
DMARC is Standards-Track under RFC 9989 (core), 9990 (aggregate reports), and
9991 (failure reports), published May 2026 to replace the 2015 Informational
RFC 7489. Only 30.4% of domains publish a record, and just 12.8% enforce it.
Check your own record with the [free DMARC checker](/tools/dmarc-checker/).
> **Update — May 2026: DMARC is now a Standards-Track protocol**
>
> DMARC has been published as a Proposed Standard. **RFC 7489 (2015,
> Informational) is replaced by RFC 9989, 9990, and 9991** — three new
> Standards-Track documents from the IETF DMARC Working Group. See our
> [day-one DMARCbis analysis](/blog/dmarc-rfc-9989-9990-9991/) for what
> changed and what to do this week. Existing `v=DMARC1` records remain
> valid; only the `pct`, `rf`, and `ri` tags are deprecated.
## What Is DMARC?
DMARC lets domain owners tell email receivers how to handle messages that fail
authentication checks. Without DMARC, anyone can send email that appears to come
from your domain, and receivers have no way to know whether to trust it.
Attackers exploit this to send phishing emails, business email compromise scams,
and brand impersonation attacks that damage your reputation and hurt your
customers. If you're already seeing DMARC failures in your reports or bounces,
the [DMARC Failure Diagnoser](/tools/dmarc-failure-diagnoser/) ranks the most
likely causes for your domain with the exact fix for each.
DMARC builds on two existing protocols — [SPF](/learn/spf/) and
[DKIM](/learn/dkim/) — and adds the critical missing piece: **alignment**. This
means the domain in the visible `From:` header must match the domain
authenticated by SPF or DKIM. It also provides reporting, so you can see exactly
who is sending email claiming to be from your domain.
Domain-based Message Authentication, Reporting & Conformance (DMARC) was
originally defined in RFC 7489 (2015) and was promoted to a Standards-Track
Internet protocol in May 2026 as RFC 9989, with aggregate reporting in RFC
9990 and failure reporting in RFC 9991. Our
[DMARC adoption statistics](/research/email-authentication/) show
adoption accelerating rapidly. Since 2024, Google and Yahoo require DMARC
enforcement for bulk senders, making it essential infrastructure for anyone
sending business email.
## How DMARC Works
DMARC authentication happens when an email receiver processes an incoming
message. Here's the step-by-step flow:
1. **The receiver checks SPF and DKIM**. It validates whether the message passes
SPF (by checking the sending IP against your SPF record) and DKIM (by
verifying the cryptographic signature against your DKIM public key).
2. **The receiver performs alignment checks**. DMARC requires that the domain
authenticated by SPF or DKIM matches the domain in the `From:` header. This
is what prevents spoofing — an attacker can't pass DMARC by authenticating a
different domain.
3. **The receiver applies your policy**. If the message fails both SPF and DKIM,
or if neither passes alignment, the receiver follows the policy you set in
your DMARC record: `none` (monitor only), `quarantine` (send to spam), or
`reject` (block delivery).
4. **The receiver sends you reports**. Email providers send daily aggregate
reports to the address in your `rua` tag, showing authentication results for
all messages claiming to be from your domain. Some providers also send
forensic reports (to your `ruf` address) with details about individual
failures.
## DMARC, SPF, and DKIM: How They Work Together
DMARC doesn't work in isolation. It relies on SPF and DKIM to do the actual
authentication work. Here's how the three protocols complement each other:
**[SPF](/learn/spf/)** (Sender Policy Framework) authorizes which IP addresses or
servers can send email for your domain. It prevents unauthorized servers from
sending on your behalf, but it only checks the envelope-from address (the
return-path used during SMTP), not the visible From header.
**[DKIM](/learn/dkim/)** (DomainKeys Identified Mail) adds a cryptographic
signature to the email headers. The receiving server verifies this signature
against a public key published in your DNS. DKIM proves the message hasn't been
tampered with and verifies the signing domain, but it doesn't require the
signing domain to match the From header.
**DMARC** ties them together by requiring that the domain in the `From:` header
aligns with the domain authenticated by SPF or DKIM. This prevents attackers
from passing SPF or DKIM for their own domains while spoofing your domain in the
visible From address.
All three protocols together create defense in depth. If one authentication
method fails, DMARC can still pass as long as the other succeeds and aligns.
This provides resilience against email forwarding scenarios that break SPF, or
mailing list modifications that invalidate DKIM signatures.
## The DMARC Record: Anatomy and Syntax
A DMARC record is a DNS TXT entry published at `_dmarc.yourdomain.com`. You can
use a [DMARC record generator](/tools/dmarc-generator/) to create one quickly, or
build it manually. Here's a typical example:
```
v=DMARC1; p=reject; rua=mailto:dmarc@reports.yourdomain.com; aspf=r; adkim=r; fo=1
```
Here's what each tag means:
| Tag | Meaning | Example | Notes |
| ------- | ----------------------------------------- | --------------------------------- | -------------------------------------------------------- |
| `v` | Protocol version | `DMARC1` (always) | Required, must be first tag |
| `p` | Policy for your domain | `none`, `quarantine`, or `reject` | Required |
| `rua` | Where to send aggregate reports | `mailto:reports@yourdomain.com` | Highly recommended |
| `ruf` | Where to send forensic reports | `mailto:forensics@yourdomain.com` | Optional, rarely sent by receivers |
| `pct` | Percentage of messages to apply policy to | `100` (default) | Historic in RFC 9989 (Appendix A.6 removes it); use `t=` |
| `sp` | Policy for subdomains | Same options as `p` | Defaults to `p` value if not specified |
| `adkim` | DKIM alignment mode | `r` (relaxed) or `s` (strict) | Defaults to `r` |
| `aspf` | SPF alignment mode | `r` (relaxed) or `s` (strict) | Defaults to `r` |
| `fo` | Forensic reporting options | `0`, `1`, `d`, `s` | Controls when forensic reports are sent |
| `np` | Policy for non-existent subdomains | `none`, `quarantine`, or `reject` | **New in RFC 9989** (May 2026). Defaults to `sp` value. |
| `psd` | Public Suffix Domain flag | `y`, `n`, or `u` (default `u`) | **New in RFC 9989**. For Public Suffix Operators only. |
| `t` | Testing mode | `y` or `n` (default `n`) | **New in RFC 9989**. Replaces deprecated `pct`. |
| `rf` | Forensic report format | `afrf` (default) | Historic in RFC 9989; uses [ARF](/learn/arf/) format |
| `ri` | Reporting interval | `86400` (seconds, default 1 day) | Historic in RFC 9989; receivers send daily regardless |
The only required tags are `v` and `p`. Everything else is optional, but you
should always include `rua` to receive aggregate reports.
## DMARC Policies: none, quarantine, reject
DMARC has three policy levels that control what happens to messages that fail
authentication:
**p=none** — Monitor only. Messages are delivered normally regardless of DMARC
results, but you receive reports showing authentication outcomes. This is where
every deployment should start. It lets you identify all legitimate senders and
verify they're passing SPF or DKIM before enforcing a stricter policy.
**p=quarantine** — Failed messages go to spam. Most receivers interpret this as
"deliver to the junk folder," but some may use other quarantine mechanisms. This
policy protects end users while still allowing them to recover false positives
from the spam folder.
**p=reject** — Failed messages are blocked at the SMTP level. The receiving
server refuses delivery during the initial connection, so the message never
reaches the inbox or spam folder. This is full DMARC enforcement and provides
the strongest protection against spoofing.
Most organizations follow a gradual path to enforcement:
1. Start with `p=none` and monitor reports for 2-4 weeks
2. Identify all legitimate senders and fix any SPF or DKIM issues
3. Move to `p=quarantine` and watch reports for newly flagged senders. Add `t=y` to signal a test deployment, so receivers apply the policy one level weaker
4. Once quarantine looks clean, move to `p=reject`, keeping `t=y` until you're confident
5. Drop `t=y` for full enforcement. The legacy `pct` tag (deprecated in RFC 9989, still honored by major receivers) can stage a percentage rollout if you need finer control
Jumping straight to `p=reject` without monitoring can block legitimate email
from third-party services like marketing platforms, ticketing systems, or CRM
tools that send on your behalf. Always monitor first. If you're already at
`p=none` and want a guided path, the
[p=none Escape Plan wizard](/tools/pnone-escape-plan/) walks the four-week
migration with the exact DNS record at every step.
## DMARC Alignment: Relaxed vs Strict
Alignment is what makes DMARC effective. It requires that the domain
authenticated by SPF or DKIM matches the domain in the visible `From:` header.
Without alignment, an attacker could pass SPF for their own domain while
spoofing your domain in the From address.
DMARC supports two alignment modes:
**Relaxed alignment** (default) — The organizational domains must match, but
subdomains are allowed. For example, if the From address is
`user@mail.example.com`, SPF can pass alignment by authenticating `example.com`
or any subdomain like `send.example.com`. This is controlled by the `aspf=r`
(SPF) and `adkim=r` (DKIM) tags.
**Strict alignment** — The exact domains must match. If the From address is
`user@mail.example.com`, SPF must authenticate `mail.example.com` exactly, not
`example.com` or `send.example.com`. Set this with `aspf=s` (SPF) and `adkim=s`
(DKIM).
Most deployments use relaxed alignment because it accommodates legitimate
sending scenarios where mail servers use different subdomains. Strict alignment
provides stronger security but requires precise configuration of all sending
sources.
For SPF alignment, the comparison is between the From domain and the
envelope-from domain (also called return-path or RFC5321.MailFrom). For DKIM
alignment, the comparison is between the From domain and the d= parameter in the
DKIM signature.
Here's a concrete example:
```
From: user@example.com
Return-Path: bounce@mail.example.com
DKIM-Signature: d=mail.example.com; ...
```
With **relaxed alignment**: This message passes SPF alignment (mail.example.com
and example.com share the organizational domain) and DKIM alignment (same
reason). DMARC passes.
With **strict alignment**: This message fails both SPF and DKIM alignment
because neither mail.example.com matches example.com exactly. DMARC fails.
## Understanding DMARC Aggregate Reports (RUA)
DMARC reporting is what sets it apart from SPF and DKIM. Aggregate reports give
you visibility into who is sending email claiming to be from your domain,
whether those messages are passing authentication, and what policy was applied.
Aggregate reports are XML files sent daily by email receivers to the address in
your `rua` tag. Each report covers a 24-hour window and includes:
- **Source IP addresses** that sent email claiming to be from your domain
- **Volume counts** for each source
- **SPF results** (pass, fail, none) and the domain checked
- **DKIM results** (pass, fail, none) and the domain checked
- **Alignment results** for both SPF and DKIM
- **Policy evaluation** (whether DMARC passed or failed, and what action was
taken)
- **Metadata** like the reporting organization, date range, and report ID
The reports are verbose and technical, which is why most organizations use a
DMARC reporting tool to parse and visualize them. To see what's inside one
right now, [paste a report into the free DMARC report analyzer](/tools/dmarc-report-analyzer/).
Without reports, you're flying blind — you won't know if legitimate senders are
failing DMARC until users complain about missing email.
Common insights from aggregate reports:
- **Unknown senders** appear in your reports, indicating possible spoofing
attempts or forgotten third-party services
- **Legitimate senders** that fail SPF or DKIM, often due to missing SPF
includes or incorrectly configured DKIM signing
- **Volume patterns** that reveal which mail streams are highest risk if you
move to enforcement
- **Subdomain gaps** where your main domain has `p=reject` but subdomains remain
unprotected
If you don't receive aggregate reports after publishing a DMARC record with an
`rua` tag, check that the email address is valid and can receive large XML
attachments. Some receivers also require you to verify ownership of the
reporting address if it's on a different domain.
## DMARC Forensic Reports (RUF) and ARF
Forensic reports (also called failure reports) provide message-level details
about individual DMARC failures. Unlike aggregate reports, which summarize
results for thousands of messages, forensic reports contain the headers and
sometimes the body of a single failed message.
Forensic reports are sent to the address in your `ruf` tag and use the
[ARF](/learn/arf/) (Abuse Reporting Format) structure. They include the full SMTP
headers, authentication results, and the DMARC policy evaluation.
**Why you might not receive forensic reports:**
Most major email receivers (Gmail, Yahoo, Outlook.com, etc.) do not send
forensic reports due to privacy concerns. The reports can contain sensitive
information from the message body or headers, creating legal and data protection
risks for the receiver. Even if you specify a `ruf` address, you'll likely only
receive forensic reports from smaller providers or enterprise mail gateways.
The `fo` tag controls when forensic reports are sent:
- `fo=0` — Send reports only if both SPF and DKIM fail (default)
- `fo=1` — Send reports if either SPF or DKIM fails
- `fo=d` — Send reports if DKIM fails
- `fo=s` — Send reports if SPF fails
Because forensic reports are rarely sent, most organizations rely entirely on
aggregate reports for DMARC monitoring. If you do receive forensic reports,
they're useful for diagnosing specific authentication failures, but they
shouldn't be the primary monitoring mechanism.
## Why DMARC Fails: Common Causes and Fixes
Understanding DMARC failure is critical before moving to enforcement. A DMARC
failure means the email failed both SPF and DKIM, or neither passed the
alignment check. Here are the most common causes:
**1. Email forwarding breaks SPF**
When a user forwards an email, the forwarding server sends it on behalf of the
original sender. This breaks SPF because the forwarding server's IP isn't in the
original domain's SPF record. DKIM usually survives forwarding, so the message
can still pass DMARC if DKIM alignment succeeds. [ARC](/learn/arc/) helps
receivers recognize legitimate forwarding.
**2. Mailing lists modify content and break DKIM**
Mailing lists often add footers or modify subject lines, invalidating the DKIM
signature. If the list doesn't re-sign with DKIM and SPF breaks due to the new
sending source, DMARC fails. Well-configured mailing lists use DKIM signing or
ARC to preserve authentication.
**3. Third-party services send without proper authentication**
Marketing platforms, CRM systems, and support ticketing tools often send email
on your behalf. If they're not included in your SPF record or not configured to
sign with DKIM using your domain, they'll fail DMARC. Always configure these
services to authenticate correctly before enforcing DMARC.
**4. Subdomain gaps**
If you set `p=reject` on your main domain but don't specify `sp=reject` for
subdomains, attackers can still spoof `subdomain.yourdomain.com`. Always set a
subdomain policy — see
[sp= and np= subdomain policies explained](/blog/dmarc-subdomain-policy/) for
how inheritance actually resolves.
**5. Alignment mode mismatch**
If you're using strict alignment (`aspf=s` or `adkim=s`) but your mail servers
use different subdomains for the envelope-from or DKIM signature, you'll fail
alignment even if SPF and DKIM pass. Switch to relaxed alignment unless you have
a specific reason for strict mode.
**6. Missing or invalid SPF/DKIM records**
If your SPF record has syntax errors, exceeds the 10 DNS lookup limit, or your
DKIM keys aren't published correctly, both SPF and DKIM will fail, causing DMARC
to fail. Validate your SPF and DKIM configurations before relying on DMARC.
To diagnose DMARC failures, check your aggregate reports for patterns. Look at
which sources are failing, whether they're failing SPF, DKIM, or both, and
whether alignment is the issue. For a step-by-step walkthrough, see
[DMARC Failed: How to Fix It](/blog/dmarc-failed-how-to-fix/). Fix the underlying
SPF or DKIM problems before enforcing DMARC.
## DMARC vs DKIM vs SPF
These three protocols work together but serve different purposes:
| Protocol | What It Does | What It Protects Against | Limitation Without DMARC |
| --------- | ----------------------------------------------------------------------------------------------- | --------------------------------------------- | ----------------------------------------------------------- |
| **SPF** | Authorizes IP addresses that can send for your domain | Prevents unauthorized servers from sending | Only checks envelope-from, not the visible From header |
| **DKIM** | Signs message headers and body with a cryptographic key | Proves the message hasn't been tampered with | Doesn't require the signing domain to match the From domain |
| **DMARC** | Requires SPF or DKIM to align with the From domain, gives you control over policy and reporting | Prevents spoofing of the visible From address | Relies on SPF and DKIM working correctly |
**When to use each:**
- Use **SPF** if you control the servers that send email for your domain and
want to authorize specific IPs
- Use **DKIM** if you want to prove message integrity and verify the signing
domain, especially for messages that pass through forwarders or mailing lists
- Use **DMARC** always, because it's the only protocol that ties authentication
to the From address and gives you visibility into your email ecosystem
You need all three for complete protection. SPF alone doesn't prevent From
header spoofing. DKIM alone doesn't prevent an attacker from signing with their
own domain. DMARC alone doesn't authenticate anything — it just enforces
alignment of the underlying SPF and DKIM results.
## DMARC Monitoring
DMARC monitoring means actively reviewing aggregate and forensic reports to
understand authentication results for your domain. Without monitoring, you won't
know:
- Who is sending email claiming to be from your domain
- Whether legitimate senders are failing DMARC
- Whether attackers are attempting to spoof your domain
- What impact enforcing DMARC would have on mail delivery
Manual monitoring is impractical because aggregate reports are verbose XML
files, and high-volume domains receive hundreds of reports per day. Most
organizations use a DMARC monitoring tool to parse reports, aggregate results,
and visualize trends — if you're choosing one, you can
[compare DMARC monitoring platforms](/compare/) side by side.
Key metrics to monitor:
**DMARC pass rate** — The percentage of messages that pass DMARC. You should aim
for 95%+ before moving to enforcement.
**Unauthenticated sources** — IP addresses or domains sending email claiming to
be from your domain that fail both SPF and DKIM. These could be attackers or
misconfigured legitimate senders.
**Volume by source** — How much mail each authenticated source sends. This helps
you prioritize which senders to fix first.
**Policy override rate** — How often receivers apply a different policy than
your DMARC record specifies. This happens when the receiver has local policies
(like allowlisting or mailing list detection) that override DMARC.
**Subdomain coverage** — Whether subdomains have DMARC records or inherit your
main domain's policy.
Monitoring should continue even after you move to enforcement. New third-party
services may start sending on your behalf, attackers may try new spoofing
techniques, and infrastructure changes can break authentication.
## DMARC Best Practices
**1. Start with p=none and monitor for at least 2 weeks**
Don't jump straight to enforcement. Collect reports to understand your email
ecosystem first.
**2. Fix SPF and DKIM issues before enforcing DMARC**
DMARC only works if SPF or DKIM pass. Validate your SPF record syntax, ensure
all legitimate senders are included, and verify DKIM signing for all outbound
mail streams.
**3. Set a subdomain policy**
Use `sp=quarantine` or `sp=reject` to protect subdomains. Otherwise attackers
can spoof `anything.yourdomain.com` even if your main domain is protected.
**4. Stage enforcement with `t=y` (test mode)**
When moving from `none` to `quarantine` or `reject`, add `t=y` so receivers
apply the policy one level weaker while you confirm legitimate mail still
passes, then drop it for full enforcement. The older `pct` tag is deprecated in
RFC 9989 but still honored by major receivers if you need a percentage rollout.
**5. Monitor continuously**
DMARC isn't set-and-forget. New senders, infrastructure changes, and attack
patterns evolve. Review reports regularly.
**6. Publish DMARC on all domains you own**
Even domains that don't send email should have a DMARC record with `p=reject` to
prevent attackers from using them for spoofing.
**7. Consider BIMI once you have p=quarantine or p=reject**
[BIMI](/learn/bimi/) lets you display your brand logo in email clients, but it
requires DMARC enforcement. It's a tangible reward for achieving strong email
authentication.
**8. Use ARC-aware infrastructure**
If you operate a mailing list or forwarding service, implement [ARC](/learn/arc/)
to preserve authentication results. This prevents DMARC failures for forwarded
messages.
**9. Validate your DMARC record syntax**
Use a [DMARC record checker](/tools/dmarc-checker/) to validate syntax and flag
common errors like missing required tags or invalid values.
**10. Document all legitimate senders**
Keep an inventory of all third-party services that send email on your behalf.
When onboarding a new service, ensure it's configured for SPF or DKIM before it
goes live.
## DMARC for Cybersecurity
DMARC has become a cornerstone of email security and is increasingly required by
compliance frameworks and industry standards:
**Business email compromise (BEC) prevention** — DMARC blocks exact-domain
spoofing, which is used in CEO fraud and vendor payment scams. Attackers can't
send email from your domain if you have `p=reject` enforced.
**Brand protection** — Phishing emails that appear to come from your domain
damage customer trust. DMARC ensures only authorized senders can use your domain
in the From address.
**Compliance requirements** — DMARC enforcement is required or recommended by
frameworks like FedRAMP, NIST, DISA STIG,
[PCI DSS v4.0.1 email requirements](/learn/pci-dss/), and the EU's NIS2 directive.
**Google and Yahoo sender requirements** — As of February 2024, bulk senders
to Gmail or Yahoo ([Google's threshold](https://support.google.com/mail/answer/81126) is 5,000+ messages/day; [Yahoo](https://senders.yahooinc.com/best-practices/) publishes no volume number) must have DMARC enforcement
(`p=quarantine` or `p=reject`). While not all organizations send bulk mail, this
signals that DMARC is becoming baseline infrastructure. Domains on Google
Workspace can follow the
[Google Workspace DMARC setup guide](/blog/dmarc-google-workspace-setup/)
to meet the requirement.
DMARC complements other email security controls like spam filters, malware
scanners, and security awareness training. It doesn't replace them, but it's the
only protocol that gives domain owners control over their namespace and
visibility into who is using it.
## Frequently Asked Questions
### What is DMARC?
DMARC (Domain-based Message Authentication, Reporting & Conformance) is an email
authentication protocol that tells email receivers how to handle messages that
fail SPF or DKIM checks. It builds on SPF and DKIM by adding alignment
requirements and reporting, helping domain owners protect their brand from
spoofing and phishing attacks.
### How does DMARC work?
DMARC works by checking whether an incoming email passes SPF or DKIM
authentication and whether the authenticated domain aligns with the domain in
the From header. If the email fails these checks, the receiver follows the
policy you set in your DMARC record (none, quarantine, or reject). Receivers
also send you aggregate reports showing authentication results for messages
claiming to be from your domain.
### What is the difference between DMARC, SPF, and DKIM?
SPF verifies that an email comes from an authorized IP address. DKIM verifies
message integrity with a cryptographic signature. DMARC builds on both by
requiring the authenticated domain to align with the visible From address, and
it gives domain owners control over what happens when authentication fails. All
three protocols work together to prevent email spoofing.
### What happens when DMARC fails?
When DMARC fails, the email receiver follows the policy in your DMARC record.
With p=none, the message is delivered normally for monitoring. With
p=quarantine, it goes to spam. With p=reject, it's blocked entirely. DMARC
failures happen when both SPF and DKIM fail, or when neither passes alignment
checks.
### Do I need DMARC for my domain?
Yes, especially if you send business email or want to protect your brand. DMARC
prevents attackers from sending phishing emails that appear to come from your
domain. Since February 2024, Google and Yahoo require DMARC for bulk senders
(Google's threshold is 5,000+ messages/day to Gmail; Yahoo publishes
no volume number), but all domains benefit from the visibility and protection
DMARC provides.
### What is a DMARC aggregate report (RUA)?
DMARC aggregate reports are XML files sent daily by email receivers to the
address in your rua tag. They show which IP addresses sent email claiming to be
from your domain, whether those messages passed SPF and DKIM, and what policy
was applied. These reports are critical for understanding your email ecosystem
before enforcing DMARC.
### How do I set up a DMARC record?
To set up DMARC, add a DNS TXT record at \_dmarc.yourdomain.com with a value
like 'v=DMARC1; p=none; rua=mailto:reports@yourdomain.com'. Start with p=none to
collect reports without affecting mail flow. Once you've identified all
legitimate senders and verified they pass SPF or DKIM, you can move to
p=quarantine or p=reject.
## Related Protocols
- [SPF](/learn/spf/) — Authorizes which servers can send email for your domain
- [DKIM](/learn/dkim/) — Adds a cryptographic signature to verify message
integrity
- [ARF](/learn/arf/) — The format used for DMARC forensic reports
- [ARC](/learn/arc/) — Preserves authentication results through forwarding chains
- [BIMI](/learn/bimi/) — Displays your brand logo in inboxes (requires DMARC
enforcement)