DMARC tells receivers what to do with mail that shows your domain in the From address but fails authentication, whether it is forged or your own mail sent through a service you have not set up. A message passes DMARC when SPF or DKIM passes for a domain that matches the From domain; this match is called alignment. Your instructions for mail that fails sit in one TXT record at _dmarc. plus your domain. The current standard is RFC 9989, published in May 2026, which replaced RFC 7489.

A DMARC lookup that fetches only _dmarc.example.com can miss the record that really applies. When a name has no record of its own, receivers walk up the DNS tree: _dmarc.mail.example.com, then _dmarc.example.com, then _dmarc.com, with at most 8 queries (RFC 9989 §4.10). This DMARC check makes the same queries in the same order, lists every name it asked and what came back, and says which record governs the name you entered.

What the check covers:

• The record itself: that there is exactly one, that it starts with v=DMARC1, and that receivers can read every tag in it.
• The policy for the domain (p=), for its existing subdomains (sp=) and for subdomains that do not exist (np=), including testing mode (t=y).
• Alignment modes (adkim= and aspf=): how closely the domains that SPF and DKIM authenticate must match your From domain.
• Report addresses in rua= and ruf=: correct mailto: syntax, a domain that could receive mail at all (not a reserved name or an IP address), and, for an address at another domain, the DNS record in which that domain agrees to receive your reports (RFC 9990 §4).
• Older receivers: not every mail server has moved to RFC 9989. Servers on the older rules find the policy with the Public Suffix List and still apply pct=. We work out what they would do and warn when it differs.

What a record check cannot tell you is whether your own messages pass DMARC. That is decided for each message from its SPF and DKIM results; see how to check if DMARC is working. We send no email: the whole check is DNS lookups through a recursive resolver, and every answer is in the Raw evidence panel under the result.

The panel at the top of the result is the verdict: a colored icon and a short label. Beside it, a short reading such as p=reject · rua 1 address names the policy that applies to your domain and how many of its report addresses can receive reports. Below come the record as published, the names receivers query, the tags in plain words, the policy for each kind of name, and where reports go. Each finding links to its explanation on this page.

Pass: the policy is enforced

Receivers are asked to quarantine or reject mail that fails DMARC, and nothing else in the record needs your attention. A passing result can still list notes, such as the alignment modes or a tag the current standard no longer uses; they are marked Pass because they change nothing.

Warning: DMARC is set up, but protects less than it could

The most common reasons, each explained in its section below:

• p=none: receivers only report and do nothing about mail that fakes your domain;
• no rua address, so no reports reach you;
• testing mode (t=y) or pct below 100, so the policy is applied only partly;
• sp= or np= weaker than p=, typos in tag names, or a value receivers replace with the default;
• a report address at another domain that has not agreed to receive your reports.

Fail: receivers apply no DMARC policy, or cannot rely on it

There is no DMARC record at all; there is more than one; the record is broken so receivers ignore it; p=, sp= or np= has a value that is not valid, or p= is missing and no report address is valid; a tag is repeated; tag names in capitals weaken the policy for strict receivers; or none of the report addresses is valid. In most of these cases receivers apply no DMARC policy at all, or at best treat the record as p=none. When the only problem is that no rua address is valid, the policy itself still works, but no report can reach you.

Could not check

A DNS lookup the verdict depends on did not get a usable answer: it timed out, the server reported a failure (SERVFAIL) or refused, or the answer could not be read. We stop a check after 20 seconds and report it the same way. This says nothing about whether your record exists or is correct. We never turn a missing answer into a pass or a fail. Try again in a minute; if it stays, your DNS servers may be unreachable or your DNSSEC may be broken.

Two more cases end the same way: DNS cannot settle whether a subdomain exists while sp= and np= differ (see the policy), and a record lists more report hosts or addresses than we check (see report addresses).

Could not check: a fault on our side

Rarely, the result says the check could not be completed because of an internal error. That is a fault in our software, not a finding about your domain and not a network problem, so trying again will most likely give the same result. Please write to support@mxverdict.com with the address of the result page, and we will fix it.

The DMARC record: found, missing or more than one

Receivers query a TXT record at _dmarc. plus the domain in the From address and keep only texts that start with v=DMARC1. When no record applies anywhere along the way, RFC 9989 says receivers must not apply DMARC to your mail at all: the result is Fail, because anyone can then send mail that claims to be from your domain and receivers have no instruction to stop it. The fix on the result page gives you a record to start with; see how to publish it.

More than one DMARC record at the same name is also Fail: receivers discard all of them (RFC 9989 §4.10), not just the extra one. It happens when a second record is added for a new service instead of editing the first. Keep one and merge what you need into it.

If the lookup of _dmarc. plus your domain gets no usable answer, the result is Could not check. If what you entered is not a domain name, nothing is looked up.

Record syntax: the parts receivers ignore

A DMARC record is a list of tag=value pairs separated by semicolons, and v=DMARC1 must come first, with DMARC1 in capitals. A record that only looks like DMARC is ignored completely and the result is Fail. Typical mistakes:

• a missing semicolon, as in v=DMARC1 p=reject, or the version in lower case, v=dmarc1;
• a tag written twice, such as p=reject; p=none: the tag syntax DMARC borrows from DKIM makes the whole list invalid (RFC 6376 §3.2), so receivers may ignore the record or use either value (this check reads the first one);
• tag names in capitals, P=reject: tag names are case-sensitive, so strict receivers ignore the tag. If that removes or weakens your policy the result is Fail, otherwise Warning.

Smaller problems are a Warning: an unknown tag (often a typo, receivers skip it), a part between semicolons that cannot be read, a broken DMARC-looking text next to a valid record, or a value that is not allowed for adkim, aspf, t, psd or fo, in which case receivers use the default. The fix shows the record rewritten cleanly.

The policy: p, sp and np

p= is what you ask receivers to do with mail from your domain that fails DMARC. p=none asks for nothing: it is monitoring mode, useful at the start, and a Warning because it stops no spoofing. p=quarantine asks receivers to treat such mail as suspicious, for example by putting it in the spam folder, and p=reject asks them to refuse it; both are a Pass. Even p=reject is a request: RFC 9989 §7.4 tells receivers not to reject on the policy alone and to weigh other knowledge about the mail. It also says that a domain with p=reject must sign all its mail with DKIM, because forwarding breaks SPF, and that domains whose users post to mailing lists should not use p=reject.

sp= sets the policy for existing subdomains and np= for subdomains that do not exist in DNS. Without them, np falls back to sp and sp to p. A subdomain policy weaker than p is a Warning: an attacker can put a subdomain in the From address instead of your main domain and get the weaker treatment.

A missing or invalid p=, or an invalid sp= or np=, disables the policy you wrote: receivers treat the record as p=none if it has a valid report address and ignore it otherwise (RFC 9989 §4.10.1). An invalid value is Fail. A missing p= is a Warning when the record has a valid rua and Fail when it has none.

When sp= and np= differ, the policy for a subdomain depends on whether it exists. A name that does not exist gets NXDOMAIN; but DNS servers that sign their zones with compact answers reply “no records” for names that do not exist too (RFC 9824). If that is all we get, we cannot tell which policy applies and say Could not check rather than guess. Giving sp and np the same value, or publishing a record for that subdomain, removes the doubt.

Testing mode: t=y

t=y asks receivers to apply one level less than your policy while you test: quarantine instead of reject, nothing instead of quarantine (RFC 9989 §4.7). It has no effect on p=none. The result is a Warning, because the policy you published is not what receivers apply.

Receivers on the older rules do not know t and ignore it, so they apply your full policy; for them the testing signal is pct=0. A record with both, such as v=DMARC1; p=reject; t=y; pct=0; rua=mailto:dmarc-reports@example.com, gets a note that both generations test the same way (by the text of both standards; we have not measured it on live receivers). Remove t=y and pct=0 together when you leave testing mode.

Inherited records and the organizational domain

A subdomain without a record of its own is covered by the record of its organizational domain, usually the domain you registered, with that record's sp= or np= policy. The result says Pass for that part and shows the parent's record as “Inherited record”. If the parent's record is itself ignored by receivers, nothing covers the subdomain and the result is Fail.

RFC 9989 finds the organizational domain by walking up the DNS tree: the name with the fewest labels that has a DMARC record, unless a record says otherwise with psd=n (this domain is an organizational domain) or psd=y (this name is a public suffix, like .com). The result shows which rule decided it. These cases are a Warning:

• only the record of a public suffix covers your domain: you do not control it, and it sends you no reports;
• the domain has more than eight labels and no record of its own, so receivers skip some of its parent names;
• sp= or np= in a record below the organizational domain, where they have no effect;
• psd=y on a domain that is not a public suffix, which moves your organizational domain.

If a lookup on the way up fails, we cannot tell which record applies, or whether the sp= and np= of your own record count, and the result is Could not check.

Alignment: adkim and aspf

DMARC passes only when the domain that SPF or DKIM authenticated matches the From domain. With relaxed alignment, the default (r), any name under the same organizational domain counts: a DKIM signature for mail.example.com aligns with a From address at example.com. With strict alignment (s) only the identical name counts (RFC 9989 §3.2.10). The result states both modes as a note marked Pass. Strict SPF alignment breaks mail from services that use a subdomain of yours as the envelope sender, as Amazon SES does with a custom MAIL FROM domain; Yahoo says relaxed alignment is acceptable.

Report addresses: rua and ruf

rua= lists where receivers send aggregate reports: daily summaries of which servers sent mail in your name and whether it passed. Without rua receivers must not send you any (RFC 9989 §4.7), so you cannot see what a stricter policy would break; that is a Warning. Each address is a URI: rua=mailto:dmarc-reports@example.com, and several are separated by commas. A common mistake is leaving out mailto:. If no address in rua is valid, the result is Fail; if only some are, a Warning.

Also a Warning: an address with a scheme other than mailto: (receivers only have to support email), and an address that cannot receive mail, such as one at a reserved name (example.test), an IP address in brackets, or a domain with an underscore.

ruf= asks for failure reports about single messages. Because they can contain private data, receivers concerned about privacy heavily redact them or do not send them at all (RFC 9989 §5.3.9), and Microsoft 365 says it does not send them. The fo= tag only shapes those reports and has no effect without ruf. We examine the first 20 entries of each tag and the first 10 recipients of each entry; anything beyond that is checked for syntax only, and a valid address we did not examine makes that part Could not check.

To read the reports themselves, open them in the DMARC report analyzer; the file stays in your browser.

Reports sent to another domain

When a report address belongs to a different organizational domain than yours, for example a DMARC report service, receivers first check that the other domain wants your reports. They look up a TXT record at the domain that published the DMARC record, plus ._report._dmarc., plus the report host, and it must start with v=DMARC1 (RFC 9990 §4). For rua=mailto:reports@dmarc.example.net on example.com that name is:

example.com._report._dmarc.dmarc.example.net   TXT   "v=DMARC1;"

The record belongs in the DNS of the report host, so the service publishes it; one wildcard record, *._report._dmarc. plus its domain, can cover every domain it serves. Receivers compare domains, not owners: reports sent to your own second domain need the record too. The result table says for each host whether no permission is needed (same organizational domain), whether it is authorized, or whether it is not (a Warning: receivers send nothing there). An authorization record may also redirect the reports to another address at the same host; one that points to a different host means no reports at all (Warning). A failed lookup is Could not check. We verify at most 10 report hosts per record; more hosts than that are listed as not checked, also Could not check.

Older receivers (RFC 7489) and removed tags

RFC 9989 changed how the policy is found. Receivers that still follow RFC 7489 pick the organizational domain from the Public Suffix List instead of walking the DNS tree, stop at a name with several records instead of moving on, do not know np, t or psd, and still apply pct. Which large mailbox providers have moved to RFC 9989 we have not verified. Microsoft's guide for Microsoft 365, updated in July 2026, still refers to RFC 7489, and its list of header results includes action=pct.quarantine for failing mail picked by pct. We work out what an older receiver would do: the same treatment is a note marked Pass, a different record, organizational domain or policy is a Warning that says what differs, and a failed lookup that this view needs is Could not check. Strict alignment and an explicit record for every domain you send from remove the difference (RFC 9989 Appendix C.3).

pct is one such difference. It applied the policy to only a percentage of failing mail; RFC 9989 removed it because receivers usually did not apply values other than 0 and 100 accurately. Receivers on the current standard ignore it and apply your policy to all failing mail, older ones still apply it to the percentage you set. So pct=50 is a Warning that states both behaviors, and its fix says first what removing pct changes: older receivers would then enforce on all failing mail too. pct=100, rf and ri change nothing any more and can be removed, and so can a size limit after a report address, such as the !10m in mailto:dmarc-reports@example.com!10m (RFC 9989 Appendix C.4); those notes are marked Pass.

Most problems the checker finds come with a fix, usually the exact record to publish; the others link to the section of this page that explains them. The same rules hold at every DNS provider:

1. Publish at your DNS host, the provider your domain's NS records point to, which is not always the company that sold you the domain.
2. Type TXT, name _dmarc. At Cloudflare, GoDaddy and Namecheap the name is entered without your domain, so for a subdomain such as mail.example.com it is _dmarc.mail. A host that asks for the full name gets _dmarc.example.com.
3. Start in monitoring mode with an address that can receive the reports:

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

   The DMARC generator builds the record for each stage.
4. Keep one record. To change the policy or add an address, edit the existing record. With two records receivers ignore both.
5. Check again here. A result is reused for 60 seconds, so wait a minute after publishing. If it still shows no record, the line under Own record says how long the resolver we asked may keep its earlier answer.

From p=none to p=reject

RFC 9989 describes the path (§5.1): publish p=none with rua, read the reports, fix every legitimate sender whose mail fails (a newsletter tool, a CRM, a billing system that sends in your name), and only then move to enforcement. It warns that this can take many months. Its advice for domains whose users post to mailing lists is concrete: p=none for at least a month, then p=quarantine for as long again, comparing the reports (§7.4). The three stages:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com

Move to p=reject only when all your mail is signed with DKIM for your domain. Google's and Microsoft's help pages still describe raising pct in steps; that tag is gone from RFC 9989 and is read differently by old and new receivers (see older receivers). To try a stricter policy first, use testing mode.

A domain that sends no email at all can go straight to the strictest record, as Microsoft recommends for parked domains: v=DMARC1; p=reject;.

Cloudflare, GoDaddy and Namecheap

At all three you enter the name without your domain: _dmarc, or _dmarc.mail for mail.example.com. The record goes into Content at Cloudflare and into Value at GoDaddy and Namecheap; at Namecheap the name field is called Host and the button is Save all changes. The screens step by step are in the TXT record guide. Cloudflare also offers DMARC Management on all plans (Email > DMARC Management): for an apex domain with a record it adds a Cloudflare rua address so it can process the reports for you.

Google Workspace, Microsoft 365 and sending services

None of the providers below publishes your DMARC record for you; you add it at your DNS host as above. What they need first is DKIM signing with your own domain, so that their mail aligns with your From address. The steps for Google Workspace, Microsoft 365 and other services are in how to fix sources that fail DMARC. Points that matter for the DMARC record itself:

• Microsoft 365: a signature for contoso.onmicrosoft.com does not align with a From address at contoso.com, so turn on DKIM with your own domain before you tighten the policy. Microsoft 365 sends no failure reports, whatever ruf says. For the onmicrosoft.com domain itself, add the record in the Microsoft 365 admin center (Settings > Domains, DNS records tab).
• Google Workspace: Google's example record uses strict alignment (adkim=s; aspf=s); keep the relaxed default if any service sends for you from a subdomain.
• SendGrid lists a starting record, v=DMARC1; p=none;, among the records to add. If you already have a DMARC record, edit it instead of adding a second one.
• Amazon SES uses a subdomain of amazonses.com as the envelope sender by default, which never aligns. For SPF to align, set a custom MAIL FROM subdomain such as bounce.example.com and keep aspf relaxed: Amazon says SPF alignment with SES does not work with aspf=s.
• Zoho Mail builds the record for you (Admin Console > Domains > your domain > Email Configuration > DMARC > Generate) and asks you to set up SPF and DKIM first.
• Mailgun signs with keys under your sending domain (pdk1._domainkey, pdk2._domainkey), so DKIM aligns with a From address at that domain, or at its parent under relaxed alignment.

For bulk senders, yes. Gmail and Yahoo ask every sender for SPF or DKIM, and larger senders also for a DMARC record. Microsoft sets rules for Outlook.com only for senders of 5,000 or more messages, and they need SPF and DKIM to both pass as well as DMARC. What their pages said when we read them on September 26, 2026:

Google says mail that misses its requirements “might not be delivered as expected, or might be marked as spam”. Note what all three accept: as a policy, p=none meets the rule (your mail must still pass DMARC), but it protects nothing. Meeting the requirement and stopping spoofing are two different steps; the second one is the move to quarantine and reject. For the rest of the list (SPF, DKIM, reverse DNS) run the email domain check.

The record is an ordinary TXT record, so any DNS tool can fetch it. With dig on macOS or Linux:

dig TXT _dmarc.example.com +short
dig @1.1.1.1 TXT _dmarc.example.com +short

On September 26, 2026 these returned, for Google's two domains:

$ dig TXT _dmarc.google.com +short
"v=DMARC1; p=reject; rua=mailto:mailauth-reports@google.com"
$ dig @1.1.1.1 TXT _dmarc.gmail.com +short
"v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com"

On Windows use nslookup (it also works on macOS and Linux), or PowerShell, as in Microsoft's own DMARC guide:

nslookup -type=TXT _dmarc.example.com 1.1.1.1
Resolve-DnsName -Name _dmarc.example.com -Type TXT

A command-line lookup asks one name only. An empty answer for _dmarc.mail.google.com (it returned nothing on September 26, 2026) does not mean mail.google.com is unprotected: receivers go on to _dmarc.google.com, and so does this checker. The permission record for a report address can be checked the same way; Google's for the reports of gmail.com:

$ dig TXT gmail.com._report._dmarc.google.com +short
"v=DMARC1"

To see any TXT record by name, with every string of a long record, use the TXT record lookup.