# DMARC



> DMARC tells inboxes what to do when a message using your domain does not pass aligned SPF or DKIM checks.



- Human page: https://mailrith.com/guides/dmarc

- Markdown page: https://mailrith.com/guides/dmarc.md

- Category: Authentication and Deliverability

- Reading time: 9 min read

- Related keywords: DMARC, DMARC guide, Authentication and Deliverability, Authentication and Deliverability guide, email sending guide, email marketing guide, email deliverability guide, SPF, DKIM, DMARC Alignment, Google DMARC Requirements, M3AAWG Email Authentication Best Practices



## AI Agent Notes

- Use this page as plain-language guidance for the specific email sending issue named in the title.

- Preserve the distinction between Mailrith, an email delivery service, DNS, and inbox providers when explaining fixes.

- When a user is running a free tool, pair the tool result with the relevant issue or step section from this guide.



### DMARC

DMARC tells inboxes what to do when a message using your domain does not pass aligned SPF or DKIM checks.

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. The name is long, but the idea is simple. It connects SPF and DKIM to the domain subscribers see in the From address.

DMARC does not ask whether SPF passed somewhere or DKIM passed somewhere. It asks a more useful question: did SPF or DKIM pass on a domain that matches the visible From domain? If yes, DMARC passes. If neither aligned SPF nor aligned DKIM passes, DMARC fails.

This means [SPF](https://mailrith.com/guides/spf.md), [DKIM](https://mailrith.com/guides/dkim.md), and [DMARC Alignment](https://mailrith.com/guides/dmarc-alignment.md) are one system. SPF and DKIM create proof. DMARC decides whether that proof belongs to the domain in the From address.

A DMARC record is a DNS TXT record at `_dmarc.example.com`. A simple monitoring record might look like `v=DMARC1; p=none; rua=mailto:dmarc@example.com`. The `p=` part is the policy. The `rua=` part asks inboxes to send aggregate reports.

The usual policies are `p=none`, `p=quarantine`, and `p=reject`. `p=none` means monitor only. `p=quarantine` asks inboxes to treat failing mail as suspicious. `p=reject` asks inboxes to reject failing mail.

DMARC reports help you find all the systems sending as your domain. They often reveal old tools, forgotten website forms, billing systems, support platforms, or email delivery service defaults that need authentication work.

You should not jump straight to `p=reject` unless you know every legitimate sender for your domain is passing aligned SPF or aligned DKIM. Otherwise, you can block your own real mail.

DMARC also has stricter options, such as strict alignment for SPF or DKIM, but most Mailrith users should start with relaxed alignment. Relaxed alignment allows `bounce.example.com` and `mail.example.com` to align with `example.com` because they share the same organizational domain.

1. List every system that sends email from the domain: email delivery services you use for campaigns, website forms, billing tools, support tools, team inboxes, and transactional systems.
2. For each system, confirm SPF and DKIM are configured.
3. Send a test from each system and confirm DMARC passes through aligned SPF or aligned DKIM.
4. Publish a DMARC record with `p=none` and a reporting address so you can see what is sending as the domain.
5. Review DMARC reports for unknown senders and legitimate senders that fail alignment.
6. Fix legitimate senders by configuring aligned DKIM or a custom SPF return-path.
7. Leave enough time for reports to show normal traffic patterns before tightening the policy.
8. After reports look clean for a while, decide whether to move toward `p=quarantine` and later `p=reject`.
9. After each policy change, keep watching reports, bounces, complaints, and support messages for signs that legitimate mail is being blocked.

- Start with a valid DMARC record before sending serious campaigns.
- Use reports to discover who is sending mail with your domain.
- Do not move to a stricter policy until important email delivery services and systems are passing aligned SPF or DKIM.
- Treat DMARC as ongoing maintenance, not a one-time checkbox.
- Remember that DMARC protects the visible From domain, which is the domain subscribers recognize.
- If you do not understand why a message failed DMARC, check [DMARC Alignment](https://mailrith.com/guides/dmarc-alignment.md) before changing the policy.
- A stricter policy is safer only after your legitimate mail is already authenticating correctly.
- `p=none` is for learning and monitoring. It does not ask inboxes to block failing mail.
- `p=quarantine` is a warning step. It asks inboxes to treat failing mail as suspicious.
- `p=reject` is enforcement. Use it only after the real senders for the domain are known and aligned.

## Fix Common Issues
### Invalid DMARC Domain

A checker says the DMARC domain is not valid. DMARC is checked on the domain subscribers see in the From address, not on a full URL, an email address, or an email delivery service dashboard link.

1. Look at the From address you plan to use for sending.
2. Copy only the domain after the `@`, such as `example.com`.
3. Do not include `https://`, `www.`, page paths, spaces, or the mailbox name before the `@`.
4. Run the DMARC checker again with only that domain.
5. If no DMARC record is found, add the TXT record at `_dmarc.yourdomain.com` in the DNS provider for that same domain.

### Missing DMARC Record

A checker found no DMARC TXT record at `_dmarc.example.com`. Without this record, the domain has no published instruction for mail that fails aligned SPF and DKIM.

1. List the real systems that send from the domain, including email delivery services you use for campaigns, team inboxes, website forms, billing tools, and support tools.
2. Make sure each important sender has SPF and DKIM configured first.
3. Create a DMARC TXT record at `_dmarc.yourdomain.com`.
4. If you are still discovering senders, start with `v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com` and use a reporting address you can monitor.
5. Publish the record in your DNS provider.
6. Run the DMARC checker again, then send test emails from each email delivery service or system and confirm DMARC passes.

### Multiple DMARC Records

A checker found more than one DMARC TXT record at `_dmarc.example.com`. Receivers expect one DMARC record, so duplicates can make DMARC fail.

1. Open the DNS records for `_dmarc.yourdomain.com`.
2. Compare the duplicate TXT records and decide which policy, report address, and options should remain.
3. Merge the settings into one DMARC TXT record.
4. Delete the extra DMARC TXT records.
5. Run the DMARC checker again and confirm it reports exactly one DMARC record.

### Missing DMARC Policy

A DMARC record exists, but the `p=` tag is missing or not recognized. Receivers need a policy such as `none`, `quarantine`, or `reject`.

1. Edit the `_dmarc` TXT record.
2. Add a valid `p=` value. Use `p=none` while you are discovering senders, then move toward `quarantine` or `reject` after legitimate mail is aligned.
3. Check that the policy is spelled exactly as `none`, `quarantine`, or `reject`.
4. Save the DNS record and run the DMARC checker again.

### DMARC Monitoring Only

The domain uses `p=none`. This is useful while learning, but it does not ask inboxes to quarantine or reject mail that fails DMARC.

1. Keep `p=none` while you are still finding legitimate senders.
2. Review DMARC reports and identify senders that fail alignment.
3. Fix each legitimate sender with aligned DKIM or a custom SPF return-path.
4. Send real test emails and confirm DMARC passes for important mail streams.
5. Move to `p=quarantine` only after normal mail is aligned.
6. Move to `p=reject` only after reports stay clean and support complaints do not show blocked legitimate mail.

### DMARC Reporting Missing

The DMARC record does not include `rua=`, so aggregate reports are not requested. Without reports, it is harder to find hidden senders and failed alignment.

1. Choose a reporting mailbox or DMARC reporting service that can receive aggregate reports.
2. Add `rua=mailto:address@yourdomain.com` to the DMARC record.
3. If the reporting address is on another domain, follow that service's authorization instructions.
4. Wait for reports to arrive. Many receiving mail systems send them daily, not immediately.
5. Use the reports to find legitimate senders that still need SPF, DKIM, or alignment fixes.

### DMARC Partial Rollout

The DMARC record uses `pct=` below 100, so the requested quarantine or reject policy applies to only part of failing mail.

1. Review reports to confirm legitimate mail is already passing aligned SPF or DKIM.
2. Increase `pct` gradually only if you are intentionally rolling out enforcement.
3. Set `pct=100` when you are ready for the policy to apply to all failing mail.
4. Keep watching reports after each increase.

### DMARC Alignment Before Enforcement

A checker says DMARC depends on SPF or DKIM alignment. This means a strict policy is only safe after legitimate mail passes for a domain that matches the visible From address.

1. Send a test email from each system that uses the domain.
2. Open the original message headers.
3. Check whether SPF or DKIM passed.
4. Check whether the passing SPF domain or DKIM `d=` domain matches the visible From domain, or an allowed subdomain in relaxed alignment.
5. Fix authentication in each email delivery service or sending system before tightening the DMARC policy.

> A DMARC policy is not a fix for broken authentication. First make legitimate mail pass aligned SPF or DKIM, then decide how strict the policy should be.

Related resources:
- [SPF](https://mailrith.com/guides/spf.md): Understand the server check DMARC can use.
- [DKIM](https://mailrith.com/guides/dkim.md): Understand the signature check DMARC can use.
- [DMARC Alignment](https://mailrith.com/guides/dmarc-alignment.md): Learn why SPF or DKIM must match the visible From domain.
- [Google DMARC Requirements](https://support.google.com/a/answer/14229414): Google's FAQ for DMARC, alignment, sender requirements, and enforcement.
- [M3AAWG Email Authentication Best Practices](https://www.m3aawg.org/sites/default/files/doc_files/m3aawg-email-authentication-recommended-best-practices-09-2020.pdf): Industry guidance for moving from monitoring toward enforcement.



## Related Guides

- [Sender Domains and Email Authentication](https://mailrith.com/guides/sender-domains-and-authentication.md): Your sender domain is the name inboxes learn to trust, and authentication proves that your email delivery service is allowed to send for it.

- [From, Reply-To, and Return-Path](https://mailrith.com/guides/from-reply-to-and-return-path.md): An email has several sender-related addresses, and each one has a different job in delivery and replies.

- [DNS, PTR, and Reverse DNS](https://mailrith.com/guides/dns-and-reverse-dns.md): DNS records identify your domain, while reverse DNS helps inboxes check whether a sending IP has a sensible hostname.
