DMARC Record Checker

Server assisted New DNS & Domains

Look up the TXT record at _dmarc. in front of the domain (for example _dmarc.example.com); when a subdomain has none, the checker walks up its parent domains to the organizational domain's record and shows whether its p= or sp= policy applies. Every tag RFC 9989 defines (p, sp, np, adkim, aspf, t, psd, rua, ruf, fo) is listed with its value or default, with the RFC 7489 tags pct, rf and ri when the record uses them, and errors and weak settings are explained. A pasted record is checked in your browser before you publish it.

Privacy: The name you look up is sent from the Mutqan server to the public DNS resolvers named in the results. Nothing is stored.

What is a DMARC record?

A DMARC record (RFC 9989, which replaced RFC 7489 in May 2026) is a TXT record at the name _dmarc in front of the domain (_dmarc.example.com) that tells receivers what to do with mail whose From domain is not authenticated by an aligned SPF or DKIM pass — nothing (p=none), quarantine or reject — and where to send reports. A subdomain without its own record falls under the organizational domain's record, through its sp= policy when present.

Security note: Without an enforced DMARC policy (quarantine or reject), receivers that apply DMARC are not asked to stop mail that puts your exact domain in the From address but fails SPF and DKIM alignment. Even p=reject does not cover look-alike domains or the display name shown next to the address.

How to use DMARC Record Checker

  1. Type the domain of the From address, or one of its subdomains; _dmarc.example.com or an e-mail address works too.
  2. Press Check DMARC. The Mutqan server reads _dmarc at that name and, if there is no record, at its parent domains.
  3. Read the policy that applies and where the record was found; for a subdomain, see whether sp= or p= decides.
  4. Go through the tag table, the report addresses, the errors and the warnings, and follow the next steps.
  5. To try a record before publishing it, paste it into the second field; it is parsed in your browser.

DMARC Record Checker features

  • The policy that actually applies to the name you enter: the domain's own record, or for a subdomain without one, the organizational domain's sp= or p=
  • The walk shown name by name: _dmarc at the domain, then at each parent domain until a record is found
  • Every tag of RFC 9989 listed with its meaning and value — np, psd and t included — with the default for each tag the record leaves out, and the RFC 7489 tags pct, rf and ri when the record still uses them
  • Report addresses in another organizational domain checked for the authorisation record that domain must publish before receivers send it reports
  • Weak settings explained: p=none, test mode (t=y), pct below 100, no rua= address, an sp= weaker than p=, two DMARC records at one name
  • A draft record pasted into the second field is checked in your browser before you publish it
  • Plain-language next steps, from the first p=none record to an enforced p=reject

Inputs and outputs

Inputs

  • Domain name — a domain or subdomain, typed as a name, an e-mail address or a _dmarc name such as _dmarc.example.com; internationalised names are accepted.
  • Pasted DMARC record (optional) — one record starting with v=DMARC1, plain or in quotes. When it is filled in, it is checked in your browser and nothing is looked up; the domain, if also given, only tells your own report addresses from external ones.

Outputs

  • Summary — the policy that applies, where the record was found, pct= when the record sets it, test mode when t=y, and the number of aggregate report addresses.
  • Record — the name checked, the record found, and for a subdomain the tag (sp= or p=) through which the policy applies.
  • Names checked — each _dmarc name the walk asked, with no record, several records (all discarded) or record found.
  • Tags of the record — every RFC 9989 tag with its meaning and value, defaults marked, and pct, rf and ri when the record uses them.
  • Report addresses — each rua= and ruf= address with whether an authorisation record is needed and found.
  • Errors, Warnings and What to do next — each finding in plain language, and the steps that follow from the result.

DMARC Record Checker example

A subdomain that inherits its policy (docs.github.com, October 2026)

Input:

docs.github.com

Output:

Policy that applies: reject (failing mail is refused) · Record found at: _dmarc.github.com (the organizational domain) · Percentage (pct): 100 · Aggregate report addresses: 1
Names checked: _dmarc.docs.github.com — no record · _dmarc.github.com — record found (organizational domain)
Record: v=DMARC1; p=quarantine; sp=reject; pct=100; rua=mailto:dmarc@github.com; ruf=mailto:dmarc@github.com; fo=1
Applies to this subdomain through: sp=reject

How to read the DMARC Record Checker results

reject: the enforcing policy — receivers that apply DMARC are asked to refuse mail that fails alignment for this exact domain. It does not cover look-alike domains or the display name shown next to the address.

quarantine: failing mail goes to spam or is held; forged mail is less visible but still delivered somewhere.

none: the policy only collects reports. Mail that fails DMARC is delivered as usual, so receivers are not yet asked to stop mail that forges the domain.

No DMARC record: neither the name nor its parent domains publish one; receivers make their own decision about failing mail.

Invalid record: receivers ignore it — most often a record that does not start with v=DMARC1, several DMARC records at one name with no usable record at a parent (all are discarded, RFC 9989 §4.10), or a missing or misspelled p= with no usable rua= address. With a usable rua=, a missing or misspelled p= (or an invalid sp= or np=) makes receivers treat the record as p=none instead (RFC 9989 §4.10.1).

When to use DMARC Record Checker

  • Starting a DMARC rollout and checking that the first p=none record with a rua= address is published correctly.
  • Moving from none to quarantine or reject and confirming the change is live.
  • Finding out which policy protects a subdomain that has no record of its own.
  • Making sure reports sent to a DMARC reporting service are authorised, so they actually arrive.

Troubleshooting

  • "No DMARC record" although you created one: the record must be a TXT record at _dmarc in front of the domain (_dmarc.example.com), not at the domain itself. Many DNS panels add the domain for you, so enter only _dmarc as the name.
  • "More than one DMARC record at this name": when two records start with v=DMARC1, receivers discard both and continue at the parent names (RFC 9989 §4.10), so the name falls back to a parent domain's policy or to none. Delete one, keeping the tags you need in the other.
  • A report address shows no authorisation record: the reporting service's domain must publish your-domain._report._dmarc.their-domain. Most DMARC reporting services do this when you add your domain to your account there.
  • No reports arrive although rua= is set: check the address for typos (it must start with mailto:), the authorisation for an external domain, and that the mailbox accepts compressed XML attachments.
  • The request-limit message: a DMARC check costs up to five DNS queries plus one per report domain checked, from a budget shared with the other DNS tools; wait the seconds shown.

Frequently asked questions about DMARC Record Checker

Which DMARC policy should I start with?

Start with p=none and a rua= address, read the aggregate reports for a few weeks until every service that sends mail for you passes SPF or DKIM with alignment, then move to p=quarantine and finally p=reject. Going straight to reject can bounce legitimate mail from a forgotten sender.

Does a subdomain need its own DMARC record?

No. When the subdomain has no record of its own (nothing at _dmarc.mail.example.com, say), receivers use the record of the organizational domain: its sp= policy if present, otherwise its p= policy. The checker walks up the same way and says which record and which tag apply. Give a subdomain its own record only when it needs a different policy.

What is the difference between rua and ruf?

rua= receives aggregate reports: daily XML summaries of which servers sent mail in your name and whether it passed. ruf= asks for failure reports about individual messages, which few large receivers send. A report address in another organizational domain only receives reports if that domain authorises it: reports for example.com sent to an address at reports.example.net need a record at example.com._report._dmarc.reports.example.net (RFC 9990 §4).

What do pct= and t= do?

pct= is an RFC 7489 tag: it applied the policy to that percentage of failing mail and treated the rest one level softer (quarantine became none, reject became quarantine). RFC 9989, which replaced RFC 7489 in May 2026, removed it and added t=y, a test mode in which receivers apply the policy one level softer to all failing mail. Receivers that follow RFC 9989 ignore pct=; when the rollout is done, remove both t=y and pct=.

Why is my DMARC record reported as invalid?

The usual causes are a record that does not start with v=DMARC1, a missing or misspelled p= tag in a record without a usable rua= address (with one, receivers treat the record as p=none), two TXT records starting with v=DMARC1 at the same name with no usable record at a parent (receivers discard both, RFC 9989 §4.10), or a record published at the domain itself instead of under _dmarc (for example at example.com instead of _dmarc.example.com).

Technical notes

DMARC (RFC 9989, which replaced RFC 7489 in May 2026) connects the From address a reader sees with SPF and DKIM: a message passes when SPF or DKIM passes for a domain that aligns with the From domain — the same domain under strict alignment (adkim=s, aspf=s), or one sharing its organizational domain under relaxed alignment, the default. The record at _dmarc in front of the domain (_dmarc.example.com) tells receivers what to do with mail that fails: p=none (only report), quarantine or reject, with t=y for a test phase (RFC 7489 used pct= for a gradual rollout) and rua=/ruf= for reports.

When a name has no record, receivers use the organizational domain's record: its sp= policy applies to subdomains when present, and np= to subdomains that do not exist. RFC 7489 found the organizational domain with the Public Suffix List; RFC 9989 replaces that with a DNS tree walk of at most eight queries that can reach the top-level domain, honours psd= flags and takes the record with the fewest labels. The Mutqan server approximates it: _dmarc at the name, then at each parent down to two labels, at most five names, and the first name with exactly one record is used (a name with several is skipped, as RFC 9989 §4.10 requires) — the same answer unless an intermediate name or a public suffix also publishes a record.

Reports to an address in another organizational domain are sent only if that domain publishes a TXT record v=DMARC1 under its own _report._dmarc name — reports for example.com sent to reports.example.net need it at example.com._report._dmarc.reports.example.net (RFC 9990 §4, as RFC 7489 §7.1 before it). Organizational domains are compared through the Public Suffix List, so an address at reports.example.com needs no such record for mail.example.com. For up to two external domains the checker looks the record up and reports whether it exists.

Limitations and methodology

The checker reads published records; it cannot see how a particular receiver applied the policy to a particular message — the aggregate reports show that.

The walk approximates the DNS tree walk of RFC 9989: it checks at most five names and stops at two labels, so it never queries a top-level domain or reads psd= flags, and it uses the first record found rather than the one with the fewest labels. The policy differs only when an intermediate name or a public suffix also publishes a record. Under public suffixes such as co.uk it may check a name like _dmarc.co.uk.

Records are read through Cloudflare's public resolver by the Mutqan server at the Cloudflare edge; a change may not be visible until cached answers expire.

Only two external report domains are checked for authorisation in one run.

Security and privacy

For a live check, the domain goes to the Mutqan server, which asks Cloudflare's public DNS over HTTPS for the _dmarc names of the domain and its parents and, for external report addresses, for the authorisation record in the report domain. A pasted record never leaves your browser. Nothing is stored.

References