DMARC checker

Check the DMARC record of a domain: whether its policy stops forged mail, where its reports go and whether those addresses accept them, and how strictly SPF and DKIM must match the From address.

The DNS lookups go straight from your browser to public resolvers (Cloudflare, Google): we see nothing.

What the DMARC checker verifies

Where the record is: DMARC lives at _dmarc.<domain>. A subdomain without its own record inherits the one of its organisational domain, with sp= instead of p=: the checker follows the same rule as receivers.
The policy (p): none only watches, quarantine sends failing mail to spam, reject refuses it. Only quarantine and reject protect the domain.
Subdomains (sp) and pct: sp=none leaves every subdomain open even when the domain is at reject. pct is obsolete since RFC 9989 (May 2026), still read by some receivers, those on RFC 7489, which then apply the policy to part of the mail only; t=y is the test mode that replaces it.
Reports (rua and ruf): rua= receives the daily aggregate reports, ruf= the failure reports. Each address must start with mailto:. Without rua, you cannot see who sends mail in your name.
External report authorisation: When reports go to another domain (a DMARC service, your agency), that domain must publish <your domain>._report._dmarc.<its domain>. The checker looks it up for every such address.
Alignment and syntax: adkim and aspf set how closely the SPF and DKIM domains must match From: r (relaxed) accepts a subdomain, s (strict) only the exact domain. Invalid values and duplicate records are reported.

How to read the result

Green: enforced: p=quarantine or p=reject on all the mail, with reports that arrive. Mail forged in your name goes to spam or is refused.
Amber: watching: p=none, pct below 100, sp=none, or reports that will not be delivered. Nothing is broken, but forged mail is still delivered.
Red: missing or invalid: No record, two records, an invalid policy or report address: receivers apply no DMARC, or lose part of it.
The table of settings: Every tag of the record with what it means. A tag that is not in the record takes its default value: adkim=r, aspf=r, t=n, and sp the same as p (pct=100 for receivers still on RFC 7489).

Common DMARC errors and how to fix them

These are the messages that other checkers, bounce messages and the Authentication-Results header show when DMARC is missing, too weak or failing, with what to change.

`DMARC policy not enabled`

Why. The record exists, but its policy is p=none: receivers send reports and still deliver forged mail.

Fix. Read the aggregate reports for two to four weeks, make every legitimate sender pass SPF or DKIM with your domain, then move to p=quarantine and, a few weeks later, to p=reject.

`No DMARC record found`

Why. Nothing is published at _dmarc.<domain>. The record was put on the domain itself, or the DNS panel added the zone twice (_dmarc.example.com.example.com).

Fix. Create a TXT record named _dmarc (the panel adds the domain) with v=DMARC1; p=none; rua=mailto:dmarc@your-domain to start. The DMARC generator writes it for you.

`550 5.7.26 Unauthenticated email from example.com is not accepted due to domain's DMARC policy`

Why. Gmail refused a message that failed DMARC on a domain at p=reject (or sent it to spam at quarantine). If it was your own mail, one of your senders is not aligned, such as a newsletter tool that signs with its own domain.

Fix. Set up DKIM for that service with your own domain (the CNAME records it gives you), or a custom return path so that SPF aligns. The DMARC report reader shows which sources fail.

`550 5.7.509 Access denied, sending domain does not pass DMARC verification and has a DMARC policy of reject`

Why. The same refusal at Outlook.com and Microsoft 365: the message failed DMARC and the domain asks for reject.

Fix. Align the sender that failed, as above. Forwarded mail and mailing lists are the usual exception: keep DKIM signing so that the signature survives forwarding.

`External domains in your DMARC are not giving permission for your reports to be sent to them`

Why. rua or ruf points to an address on another domain that has not published the authorisation record, so receivers send nothing there.

Fix. Ask the report service to publish <your domain>._report._dmarc.<its domain> with v=DMARC1 (most services do it for their customers), or use an address on your own domain.

`Multiple DMARC records found`

Why. Two TXT records at _dmarc start with v=DMARC1. Receivers then apply no DMARC policy at all, as if the domain had none.

Fix. Keep a single record, starting with v=DMARC1; then p=, with tags separated by semicolons.

`DMARC record does not start with v=DMARC1`

Why. A TXT record at _dmarc that does not begin with v=DMARC1 (text before it, a typo, a quotation mark left inside) is not a DMARC record: receivers skip it. If it is the only one, the domain has no DMARC.

Fix. Make v=DMARC1; the very first characters of the value, then p=. The checker reads only the records that start this way.

Questions

Which DMARC policy should I use?

Start with p=none and a rua address to see who sends in your name. Once every legitimate source passes, move to quarantine, then to reject. Gmail and Yahoo require at least p=none from bulk senders since 2024; reject is what actually stops spoofing.

What is DMARC alignment?

DMARC passes when SPF or DKIM passes for a domain that matches the From address. Relaxed alignment (r, the default) accepts the same organisational domain, so mail.example.com aligns with example.com; strict (s) requires the exact name.

Why do my DMARC reports not arrive?

Usually one of three reasons: no rua tag, an address without mailto:, or an address on another domain that has not published the authorisation record. Reports come once a day, and only from the larger receivers.

Do subdomains need their own DMARC record?

No. A subdomain without a record follows the organisational domain’s, with sp= as its policy. Leave sp out (it then follows p) or set sp=reject, unless a subdomain needs its own rollout.

Is pct still worth using?

pct applied the policy to a share of the mail during a rollout. RFC 9989 (May 2026), which replaces RFC 7489, removes it in favour of a test flag, t=y. With t=y the policy is not suspended: it is applied one step lower, reject as quarantine and quarantine as none (RFC 9989, section 4.7). Receivers still on RFC 7489 ignore t= and apply the full policy, and some of them still read pct. For a trial, add t=y, then remove it once the reports are clean.