# DMARC > DMARC tells inboxes how to handle a message that uses your domain but 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 Mailrith free tool, pair that specific free-tool result with the relevant issue or step section from this guide. ### DMARC DMARC tells inboxes how to handle a message that uses your domain but does not pass aligned SPF or DKIM checks. DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. The name is long, but the purpose is simple: DMARC connects SPF and DKIM results to the domain subscribers see in the From address. DMARC does not only check whether SPF passed on any domain or DKIM passed on any domain. DMARC checks whether SPF or DKIM passed on a domain that matches the visible From domain. If aligned SPF or aligned DKIM passes, 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) work as 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=` tag sets the policy. The `rua=` tag asks inboxes to send aggregate reports. The usual DMARC 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 every system that sends mail as your domain. These reports often reveal old tools, forgotten website forms, billing systems, support platforms, or email delivery service defaults that need authentication work. Do not move straight to `p=reject` unless every legitimate sender for your domain passes aligned SPF or aligned DKIM. If legitimate senders are not aligned, a strict policy can block your real mail. DMARC also supports 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 your domain, including email delivery services you use for campaigns, website forms, billing tools, support tools, team inboxes, and transactional systems. 2. For each system, confirm that SPF and DKIM are configured. 3. Send a test email from each system. Confirm that DMARC passes through aligned SPF or aligned DKIM. 4. Publish a DMARC record with `p=none` and a reporting address so you can see which systems send mail as your domain. 5. Review DMARC reports. Look for unknown senders and legitimate senders that fail alignment. 6. Fix each legitimate sender that fails alignment by configuring aligned DKIM or a custom SPF return-path. 7. Wait long enough for DMARC reports to show normal traffic patterns before you tighten the policy. 8. After reports stay clean for a while, decide whether to move to `p=quarantine` and later to `p=reject`. 9. After each policy change, keep watching DMARC reports, bounces, complaints, and support messages for signs that legitimate mail is being blocked. - Start with a valid DMARC record before you send serious campaigns. - Use DMARC reports to find every system that sends mail with your domain. - Do not move to a stricter policy until important email delivery services and systems pass 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 you change the policy. - A stricter policy is safer only after your legitimate mail already authenticates 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 you know the real senders for your domain and those senders are aligned. ## Fix Common Issues ### Invalid DMARC Domain A DMARC 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 your domain from 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 your domain. 5. If the DMARC checker does not find a DMARC record, add the TXT record at `_dmarc.yourdomain.com` in the DNS provider for that same domain. ### Missing DMARC Record A DMARC checker found no DMARC TXT record at `_dmarc.example.com`. Without this record, your domain has no published instruction for mail that fails aligned SPF and DKIM. 1. List the real systems that send from your domain, including email delivery services you use for campaigns, team inboxes, website forms, billing tools, and support tools. 2. Before you publish a strict DMARC policy, make sure each important sender has SPF and DKIM configured. 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 DMARC TXT record in your DNS provider. 6. Run the DMARC checker again. Then send test emails from each email delivery service or system and confirm that DMARC passes. ### Multiple DMARC Records A DMARC checker found more than one DMARC TXT record at `_dmarc.example.com`. Receivers expect one DMARC record, so duplicate records can make DMARC fail. 1. Open the DNS records for `_dmarc.yourdomain.com`. 2. Compare the duplicate TXT records. Choose the policy, report address, and options that should remain. 3. Merge the chosen settings into one DMARC TXT record. 4. After the single DMARC TXT record contains the settings you want to keep, delete the extra DMARC TXT records. 5. Run the DMARC checker again and confirm that the DMARC result 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. After legitimate mail is aligned, move toward `quarantine` or `reject`. 3. Check that the policy is spelled exactly as `none`, `quarantine`, or `reject`. 4. Save the DNS record, then run the DMARC checker again. ### DMARC Monitoring Only Your domain uses `p=none`. This policy is useful while you are learning which systems send mail, 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 that 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 that legitimate mail is being blocked. ### DMARC Reporting Missing The DMARC record does not include `rua=`, so aggregate reports are not requested. Without aggregate 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 aggregate reports 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 the mail that fails DMARC. 1. Review DMARC reports and confirm that legitimate mail already passes 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 mail that fails DMARC. 4. After each increase, keep watching DMARC reports. ### DMARC Alignment Before Enforcement A DMARC checker says DMARC depends on SPF or DKIM alignment. This means a strict policy is safe only after legitimate mail passes authentication for a domain that matches the visible From address. 1. Send a test email from each system that uses your 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 matches an allowed subdomain in relaxed alignment. 5. Fix authentication in each email delivery service or sending system before you tighten the DMARC policy. > A DMARC policy does not fix 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 that DMARC can use. - [DKIM](https://mailrith.com/guides/dkim.md): Understand the signature check that 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 what inbox providers learn to trust. Authentication proves that your email delivery service is allowed to send email for your domain. - [From, Reply-To, and Return-Path](https://mailrith.com/guides/from-reply-to-and-return-path.md): An email can include several sender-related addresses. Each address has a separate role for delivery, authentication, or replies. - [DNS, PTR, and Reverse DNS](https://mailrith.com/guides/dns-and-reverse-dns.md): DNS records identify your domain. Reverse DNS helps inbox providers check that a sending IP address has a valid hostname.