DMARC Record Checker

A DMARC checker shows whether a domain publishes a DMARC policy and whether that policy actually stops anyone spoofing it. The short answer: a working DMARC record is a single TXT record at _dmarc.yourdomain that starts with v=DMARC1, sets a policy of p=none, p=quarantine or p=reject, and names an rua address for reports. It only blocks spoofing once the policy is quarantine or reject and your real mail passes SPF or DKIM with alignment. Our tool does a full DMARC record check: it looks up the record the way a receiving mail server does, falling back to the parent domain for subdomains, validates the syntax, explains every tag and its default, tests whether report addresses on other domains are authorized to receive reports, and rates how strong the policy is. If something is missing or weak, you get the next record to publish, built from your current one where possible.

How to use the DMARC checker

1. 1 Enter the domainType the domain used in your From address, for example example.com. Pasting an email address or website URL works too, and so does a subdomain such as mail.example.com.
2. 2 Run the DMARC lookupSign in with your free account and run the check. We query the live record at _dmarc.yourdomain (and the parent domain if a subdomain has none) and cache the result for about ten minutes.
3. 3 Read the policy and tag tableThe result shows the record, a policy strength meter from none to reject, every tag in plain English, and the status of each report address, with a pass, warning or fail on each finding.
4. 4 Publish the suggested recordCopy the suggested next record into a TXT record with the host _dmarc, then run the DMARC test again once the change has propagated.

What a DMARC record check tells you

DMARC (Domain-based Message Authentication, Reporting and Conformance), described in RFC 7489, builds on SPF and DKIM. It lets you publish a policy that tells receiving servers what to do when a message claims to come from your domain but fails authentication, and where to send reports about the mail they see. Without it, anyone can put your domain in the From line of a phishing email and the receiver has no instruction from you on how to handle it.

A DMARC record check is the quickest way to confirm the policy is published correctly. Our DMARC checker reads the same public DNS record that every mailbox provider reads, so if we can see it, they can too. If we cannot find it, neither can they.

How DMARC policy evaluation works

When a receiver gets a message, it takes the domain from the visible From header and looks for a TXT record at _dmarc on that domain. If there is none on a subdomain, it falls back to the organizational domain, so a policy on example.com can cover mail from shop.example.com. It then checks two things: did SPF pass for a domain that aligns with the From domain, and did DKIM pass with a signing domain (the d= value) that aligns with it?

If either SPF or DKIM passes with alignment, DMARC passes. If both fail, the receiver applies your policy. Alignment can be relaxed, where subdomains of the same organizational domain count as a match, or strict, where the domains must be identical. Relaxed is the default and suits almost every small business.

• p=none: deliver as normal and send reports. Monitoring only.
• p=quarantine: treat failing mail as suspicious, usually by placing it in spam or junk.
• p=reject: refuse failing mail during delivery so it never reaches the inbox.

Understanding your DMARC checker results

The first line is the headline verdict, and it is the only one that counts toward a score. A pass means a valid record with p=quarantine or p=reject applies to the domain you checked. A warning means the policy is p=none, which only monitors. A fail means receivers have no usable policy: the record is missing, there are two or more of them, or it is broken badly enough that receivers ignore it.

Below it, each finding gets its own row so you can see exactly what to change. The tag table lists every tag, including the ones you left out, with the default a receiver uses in their place. Report destinations show whether each rua or ruf address is on your own domain, or on another domain that has (or has not) authorized it. The suggested next record moves you one step along the path to p=reject rather than jumping straight there.

• Multiple DMARC records: receivers that find more than one v=DMARC1 record apply no policy at all.
• Syntax errors: v=DMARC1 is not first, p is missing, or p has a value other than none, quarantine or reject.
• Tag problems: unknown tags, duplicated tags, or invalid values such as pct=150 or adkim=x, which receivers replace with defaults.
• pct below 100 and a subdomain policy (sp) weaker than p, both of which leave part of your mail or domain less protected.
• No rua address: monitoring with no reports, so you cannot tell when it is safe to enforce.
• Inherited policy: the subdomain you checked has no record, so receivers use the parent domain's.

DMARC record lookup for subdomains

Receivers look for a DMARC record at _dmarc on the exact domain in the From address first. If nothing is there and the domain is a subdomain, they try the organizational domain, which is the registered name one level below the public suffix: example.com for news.example.com, or example.co.uk for shop.example.co.uk. Our DMARC lookup follows the same steps and labels the result "inherits from parent" when the policy comes from above.

When a policy is inherited, the sp tag decides what applies to subdomains, and if there is no sp the main p policy covers them too. RFC 9091 adds an experimental np tag for subdomains that do not exist at all, a common target for spoofing; not every receiver supports it yet. We work out the organizational domain from a built-in list of common public suffixes rather than the full Public Suffix List, so for unusual domain endings treat the parent we show as a close approximation. A subdomain that publishes its own record, even a broken one, does not fall back to the parent, so delete a stray subdomain record rather than leaving it in place.

DMARC test: what a DNS check can and cannot tell you

A DMARC test of the published record answers one question very reliably: what instruction every receiver gets when mail fails authentication. It reads the same public DNS that Gmail, Outlook and every other mailbox provider reads, so a policy we cannot find is a policy they cannot find either. It also tests the parts of DMARC that live in DNS on other domains, such as the authorization record a third-party reporting service must publish before receivers will send your reports there.

What a DNS check cannot show is whether your real mail passes. That depends on which servers send it and how each one signs it, which only shows up in the messages themselves. To test that, read your rua aggregate reports, which list every sending source and its SPF and DKIM alignment, or send a message to an address you control and open the Authentication-Results header with our email header analyzer. Together, a clean DMARC record check and clean reports are what tell you it is safe to move to quarantine and reject.

How to publish or fix a DMARC record

Before you publish anything stronger than p=none, make sure SPF and DKIM are set up for every service that sends as your domain. DMARC needs at least one of them to pass with alignment, and DKIM is the more reliable of the two because it survives forwarding.

In Google Workspace, Google does not create the DMARC record for you. Turn on DKIM in the Admin console under Apps, Google Workspace, Gmail, Authenticate email, then add the DMARC TXT record at your DNS host. In Microsoft 365, enable DKIM for your custom domain in the Microsoft Defender portal and publish the DMARC record at your DNS host; Microsoft does not add one for custom domains automatically. In cPanel, open Zone Editor, add a TXT record named _dmarc and paste the value. In Cloudflare, go to DNS, Records, add a TXT record with the name _dmarc and the record as content; Cloudflare also offers its own DMARC management screen if you prefer.

If a sending service fails, fix SPF or DKIM first: the SPF checker shows the record and its DNS lookup count, the SPF Record Generator builds a corrected one, and the DKIM checker confirms each selector is published. The DMARC Record Generator builds the policy itself. Wait for propagation, then run the DMARC lookup again to make sure the live record matches what you entered, with no stray quotes or spaces.

Moving from p=none to p=reject safely

The aim is enforcement, but rushing it is the most common way to lose legitimate email. Leave p=none in place for at least two to four weeks with an rua address, and read the aggregate reports. They show every source of mail using your domain and whether each one passes SPF and DKIM with alignment. Fix every legitimate source that fails, typically by adding a missing include or switching on custom DKIM signing in that platform.

Then move to p=quarantine. Optionally use the pct tag to apply it to a portion of failing mail first, for example pct=25, and raise it over a few weeks. Once reports show no legitimate mail failing, move to p=reject. Keep reading reports afterwards, because new tools added by colleagues are the usual cause of surprise failures.

Why a DMARC lookup might not find your record

If you are sure you published a record but the DMARC lookup reports it as missing, the cause is almost always one of a handful of DNS slips. Work through them in order before assuming the checker is wrong, because receiving servers will be failing to find the record in exactly the same way.

Remember that our results are cached for about ten minutes per domain, so a fix made a moment ago may not show straight away. Your DNS host may also take time to publish changes, and resolvers keep the old answer until its TTL expires.

• The host was entered as _dmarc.example.com in a panel that appends the domain, creating _dmarc.example.com.example.com.
• The record was added as a CNAME or another type instead of TXT, or it was added at the root domain rather than at _dmarc.
• The value starts with something other than v=DMARC1, for example a leading space or quotation marks that the panel stored as part of the text.
• The domain uses different nameservers from the panel you edited, which often happens after a move to Cloudflare or a new host.

DMARC requirements from Gmail, Yahoo and Microsoft

Gmail and Yahoo have required a DMARC record from bulk senders since February 2024, alongside SPF, DKIM and From alignment, and p=none satisfies that rule. Microsoft applied comparable requirements to high-volume senders to its consumer Outlook.com, Hotmail and Live addresses in 2025. In practice, mail from a domain with no DMARC record is increasingly likely to be filtered, whatever your volume.

Government guidance points the same way. In the United States, CISA's Binding Operational Directive 18-01 required federal civilian agencies to move to a DMARC policy of reject, and national cyber security agencies in other countries, such as the UK's National Cyber Security Centre, recommend working toward reject too. For a small business, a DMARC check is a simple way to show clients and insurers that your domain is protected against impersonation.

Examples you can copy

v=DMARC1; p=none; rua=mailto:dmarc@example.com

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com

example.com._report._dmarc.reports.example.net  TXT  "v=DMARC1"

Common mistakes to avoid

Frequently asked questions