DMARC checker

What the DMARC checker shows

Enter a domain and the checker finds its DMARC record, reads the policy and tells you in plain words how well the domain is protected against forged mail. It lists every tag, shows where reports are sent and flags mistakes that make receivers ignore the record.

DMARC (Domain-based Message Authentication, Reporting and Conformance) is a DNS record that tells receiving mail servers what to do with a message that claims to come from your domain but fails authentication. It also says where to send reports about those messages. A message passes when SPF or DKIM passes and the domain that passed matches the domain in the visible From address. That match is called alignment.

The record lives at _dmarc.<domain>. A subdomain without a record of its own uses the one at its organizational domain, which is the domain you registered. For mail.example.com that is example.com. The result tells you when a policy is inherited this way.

How to check a domain

1. Enter the domainUse the domain in your From address, such as example.com. If you paste an email address, a web address or the record name _dmarc.example.com, LookupOwl reduces it to the domain.
2. Read the answerThe top tile gives the verdict, from no record at all to enforced. Beside it you see the policy, the share of failing mail it applies to, where reports go and what subdomains do.
3. Work through the notesNotes come with errors first, then warnings, then hints. Fix the errors first, because they can make receivers ignore the record.

The DMARC tags and what they mean

The checker also reads psd (new in DMARCbis, for public suffix domains) and the old ri and rf tags. DMARCbis dropped pct, ri and rf, so those three show up as hints, not errors.

The result gives the policy a plain label. None means no usable policy: there is no record, it is invalid or there are two. Monitoring means p=none. Partial means quarantine or reject for only part of the mail because of pct. Enforcing means quarantine or reject for all of it. For a subdomain that inherits its parent's record, the label follows the parent's sp tag when it has one.

Alignment trips up many senders. If your newsletter service sends as [email protected] but signs with its own domain, SPF and DKIM can pass for the service while DMARC fails for you. The fix is to have the service sign with a DKIM key for your own domain, or to use your domain as its bounce address (the return path, which is what SPF checks).

Problems the checker flags

• No DMARC record. Receivers have no policy to apply, and Gmail, Yahoo and Microsoft expect DMARC from bulk senders. Start with v=DMARC1; p=none; rua=mailto:[email protected].
• Stuck on p=none. Monitoring is useful for a few weeks, but it does not stop spoofing. Move to quarantine and then reject once your real senders pass.
• No report address. p=none without rua is a warning, because you would be monitoring with nothing to read. With quarantine or reject it is a hint.
• Two DMARC records. Receivers discard both, so the name has no working policy. Keep exactly one TXT record at _dmarc.
• Invalid syntax. Tags are separated by semicolons. A missing ;, a report address without mailto:, quotes around the address or a value such as p=block make the record invalid. The checker names the tag.
• Subdomain policy weaker than p. If sp or np is softer than p, forged mail from subdomains is treated more gently, and attackers look for exactly that gap.
• Report address not authorised. If rua or ruf points to a mailbox on a different domain, that domain must publish a TXT record at example.com._report._dmarc.otherdomain with the value v=DMARC1. Without it, receivers do not send the reports. The checker looks for it, for up to five outside domains, and warns when it is missing. Reporting services normally publish it for you.

The checker reads DNS, not your mail, so it cannot tell whether your real messages pass. Two things catch people out. Services that sign only with their own domain fail alignment for you. And forwarding often breaks SPF, because the message arrives from the forwarder's address, while mailing lists can break DKIM by changing the message. Read your aggregate reports for both before you enforce.

How the check works

LookupOwl asks DNS for the TXT records at _dmarc.<domain> and keeps those that start with v=DMARC1. If there are none and the name is a subdomain, it asks once more at the organizational domain, which it works out from the Public Suffix List. That is the method of RFC 7489. DMARCbis (RFC 9989) replaces it with a DNS tree walk that climbs the name one label at a time. In most cases both end at the same record, but they can differ when a domain publishes records at several levels.

A temporary DNS failure is reported as one, not as a missing record, and the checker does not fall back to a weaker parent policy. Results are kept for up to five minutes, so use Check again after you change the record. To read the record yourself:

dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.com

Standards

• RFC 9989: DMARCbis, published in May 2026. It replaces RFC 7489 and RFC 9091, adds np, psd and t and the DNS tree walk, and drops pct, rf and ri. The record still begins v=DMARC1.
• RFC 9990 and RFC 9991: the formats of aggregate reports and failure reports.
• RFC 7489: the 2015 specification that DMARCbis replaces. Many receivers still follow it, which is why the checker uses its way of finding the policy and still understands its tags.
• RFC 7208: SPF. RFC 6376: DKIM.

Background reading: SPF, DKIM and DMARC explained.