DMARC checker
DMARC tells receiving servers what to do with mail that fails SPF and DKIM alignment, and where to send reports. This reads the record at _dmarc on your domain and explains the policy, the reporting address, pct and alignment in plain words.
The policy, the reporting address, pct and alignment, read from _dmarc on your domain.
What this checks, and how.
- We look up the TXT record at _dmarc.yourdomain.com and read its tags.
- We show the policy (none, quarantine or reject), the subdomain policy, pct and the alignment modes, and the addresses reports go to.
- A missing record, a monitor-only policy that has been left in place, or a pct below 100 each appear as findings.
What a DMARC record does.
DMARC (Domain-based Message Authentication, Reporting and Conformance) sits on top of SPF and DKIM. It does two jobs. It tells a receiving server what to do with mail that claims to be from your domain but fails authentication, and it asks receivers to send you reports about the mail they see.
The check DMARC adds is alignment. SPF and DKIM can pass for any domain, so DMARC requires that the domain that passed matches the domain in the From address a person reads. A message passes DMARC when at least one of SPF or DKIM passes and aligns.
The record is a TXT record at _dmarc.yourdomain.com:
_dmarc.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com"
Google's sender guidelines, read on 24 October 2026, require DMARC from anyone sending more than 5,000 messages a day to personal Gmail accounts, and say the policy can be set to none. That is why many senders publish a record at p=none first: it satisfies a basic requirement and starts the reports flowing.
The tags the checker shows, and what they mean.
| Tag | Meaning | Default if missing |
|---|---|---|
v=DMARC1 | Version. Must come first | Required |
p= | Policy for the domain: none, quarantine or reject | Required |
sp= | Policy for subdomains | Same as p |
rua= | Where aggregate reports go, as mailto: addresses | No reports |
ruf= | Where failure (forensic) reports go. Many receivers do not send them | None |
pct= | Share of failing mail the policy applies to, 0 to 100 | 100 |
adkim=, aspf= | Alignment mode: r relaxed (a subdomain may match) or s strict (exact match) | Relaxed |
Policy: none, quarantine, reject
none is monitor-only: failing mail is delivered as normal and you get reports. quarantine asks receivers to treat failing mail as suspicious, which usually means the spam folder. reject asks them to refuse it during the SMTP conversation. A policy is a request, and receivers decide for themselves how much weight to give it.
pct: easing in
With pct=25 the policy applies to a quarter of failing mail and the rest is treated as if the policy were one step lower. The checker flags any value below 100 so you remember to finish the rollout. It is a stepping stone, not somewhere to stay.
The checker's findings
A missing record is the most serious finding: nothing tells receivers what to do and you will not receive reports. A p=none record that has been in place for months is the next most common, because a monitor-only policy gives no protection. A missing rua tag means you are collecting no evidence of who is sending as you.
A safe order for moving to enforcement.
- Make sure SPF and DKIM are set up for every service that sends as your domain. Use the SPF checker and DKIM checker.
- Publish
v=DMARC1; p=none; rua=mailto:...and wait. Reports are sent about once a day by each receiver. - Read the reports. They list the sending IP addresses and whether SPF and DKIM passed and aligned for each. Look for legitimate senders that fail, such as a billing tool or a forgotten newsletter service, and fix them at the sender.
- Move to
p=quarantine, withpctat a low value if you want to ease in, and watch the reports for any new failures. - Raise
pctto 100, then move top=rejectwhen the reports show only mail you do not recognise failing.
There is no fixed number of weeks for each step. It depends on how many services send for you and how often their mail shows up in the reports. A domain with one sending service can move quickly. A company with many tools should wait until every one of them appears as a pass in the data.
A worked example of reading one result
Say the checker shows v=DMARC1; p=none; pct=100 with no rua. Read it in three steps. The policy is monitor-only, so nothing you send is blocked, and nothing protects the domain from spoofing yet. There is no reporting address, so you have no evidence about who is sending as you. The fix is to add an rua address first, wait a week or two for reports to arrive, and only then decide which step to take. Changing the policy before reading any report is how a legitimate sender gets blocked by accident.
Where reports should go
Aggregate reports are compressed XML files and are hard to read by eye. Point rua at a mailbox you control or at a monitoring service. If the address is on a different domain from the one you protect, that other domain must publish a small authorising TXT record (RFC 7489, section 7.1), or receivers will not send the reports. Warmerly also offers DMARC report monitoring for domains you connect.
The usual faults, and the fix for each.
| Finding | Usual cause | Fix |
|---|---|---|
| No record found | Published on the wrong host, such as the root instead of _dmarc | Publish a TXT record at host _dmarc |
| Two DMARC records | A second record added by a new tool | Keep one. With two, receivers may ignore both |
Missing v=DMARC1 first | A typo, or a tag placed before the version | Put v=DMARC1 at the start, exactly as written |
p=none for a long time | Monitoring was never followed by a policy change | Read the reports, fix failing senders, then move up a step |
No rua address | The record was copied from a basic example | Add rua=mailto: pointing at a mailbox that can receive reports |
| Strict alignment breaks a sender | adkim=s or aspf=s with a service that signs from a subdomain | Use relaxed alignment, or have the service sign with your exact domain |
After any change, run the deliverability checker to see SPF, DKIM, DMARC and MX together. DMARC controls where your mail is judged. The mailbox you send from still needs warming before you send volume, which is what Warmerly's warmup does.
Quick answers.
What is the difference between none, quarantine and reject?
none only monitors: failing mail is delivered and you get reports. quarantine asks receivers to treat failing mail as suspicious, usually the spam folder. reject asks them to refuse it.
Should I start at reject?
Most people start at none to read the reports, fix any legitimate sender that fails, then move up. The DMARC record generator builds the record at any step.
Where do the reports go?
To the addresses in the rua tag. The checker shows them if you have set any.
Do I need DMARC if I send cold email?
Google's sender guidelines, read on 24 October 2026, require DMARC from anyone sending more than 5,000 messages a day to personal Gmail accounts, with the policy allowed to be none. Below that volume it is not required, but publishing a p=none record costs little and gives you reports on who is sending as your domain.
What is a good DMARC policy to start with?
Start at p=none with a rua address so you can read the reports before anything is blocked. Move to quarantine and then reject once the reports show every legitimate sender passing and aligning.
What does pct mean in a DMARC record?
pct is the percentage of failing mail the policy applies to, from 0 to 100, with 100 as the default. A lower value lets you ease into quarantine or reject. Raise it to 100 once the reports look clean.
Why am I not getting DMARC reports?
Common causes are a missing rua tag, a mistyped address, a reporting address on another domain that has not published the authorising record, or simply too little time. Receivers send aggregate reports about once a day and only for domains whose mail they have seen.
Fixed the records? Now warm the mailbox.
Free plan: one mailbox, capped sends. Every signup gets a free sandbox mailbox that's already warming.
- Free plan, no time limit
- 7-day trial on paid plans
- 30-day inbox guarantee, with conditions
- Customer data is hosted in the EU