🍱 Lunchbox Hands

DMARC Record Checker & Generator

Look up any domain's DMARC record, grade the policy, explain every tag, verify external report authorisation, and generate a correct record step by step.

DMARC is the record that turns SPF and DKIM into an actual instruction: when a message claiming to be from your domain fails authentication, quarantine it, reject it, or just report it. This tool fetches the record at _dmarc.yourdomain from public DNS, grades how much protection it gives, validates each tag against RFC 9989 (the May 2026 standard that replaced RFC 7489), and checks the detail most tools skip: whether an outside report address has authorised your domain to send it reports. The Generate tab writes a correct record for you; Validate checks text before you publish it.

DMARC only passes when SPF or DKIM passes and aligns with the From domain, so check your SPF record first. To see the raw TXT answer, use the DNS Lookup.

DMARC tag reference
v
Version. Must be DMARC1 and must be the first tag.
p
Policy for mail that fails DMARC: none (monitor only), quarantine (spam folder), reject (bounce).
sp
Policy for existing subdomains. Defaults to the p value when absent.
np
Policy for subdomains that do not exist in DNS (a favorite for spoofers). Defaults to sp, then p.
rua
Where aggregate (daily summary) reports are sent. Comma-separated mailto: URIs.
ruf
Where failure (per-message) reports are sent, now defined in RFC 9991. Many receivers never send these.
adkim
DKIM alignment: r (relaxed, organizational domain match) or s (strict, exact match). Default r.
aspf
SPF alignment: r (relaxed) or s (strict). Default r.
t
Testing mode: y asks receivers to apply one level below your policy (reject acts as quarantine, quarantine as none). Default n. Replaces pct=0.
psd
Public suffix flag: y for public suffix operators, n to mark this domain as an organizational domain, u (default) to let the DNS tree walk decide.
pct
Historic (removed in RFC 9989, kept by some receivers). Percentage of failing messages the policy applies to, 0 to 100. Default 100. Use t=y instead.
fo
Failure reporting options for ruf: 0 (both fail), 1 (either fails), d (DKIM fail), s (SPF fail). Default 0.
rf
Historic (removed in RFC 9989). Failure report format; only afrf was ever defined.
ri
Historic (removed in RFC 9989). Requested interval between aggregate reports, in seconds. Default 86400 (daily).

Why SPF and DKIM are not enough

SPF checks the envelope sender and DKIM checks a signature, but neither says anything about the From address a person actually sees. A forger can pass SPF for their own domain while writing yours in the From header. DMARC closes that gap with alignment: the domain that SPF or DKIM validated must match the From domain (exactly, or as a subdomain in relaxed mode). Then it adds a policy telling receivers what to do with failures and reporting so you can see who is sending as you, legitimate or not.

The three-step rollout

  1. p=none with rua. Nothing changes for delivery. Reports arrive daily as XML from Google, Microsoft, Yahoo and others, listing sending IPs and pass/fail counts.
  2. Fix legitimate failures. Every SaaS tool that sends as your domain needs to be in SPF or signing with DKIM, and aligned. Marketing platforms, CRMs, ticketing systems and the office printer are the usual surprises.
  3. p=quarantine, then p=reject. RFC 9989 suggests at least a month at p=none and about as long at p=quarantine before reject. Add t=y (testing mode) if you are nervous; it replaces the old pct ramp. If your users post to mailing lists, think twice about reject: RFC 9989 §7.4 advises those domains not to publish it. Mailbox providers such as Google and Yahoo have required at least p=none from bulk senders since 2024, and many business partners now check for enforcement.

What the checker validates

  • The record starts with v=DMARC1 and has a valid p; without those receivers ignore it.
  • Only one DMARC record exists at the name. Two means no DMARC at all (RFC 9989 §4.10).
  • Every tag value is legal: policies (p, sp, np), t and psd flags, r/s alignment, fo options, mailto: report URIs, and the historic pct (0 to 100).
  • External report domains have published the _report._dmarc authorisation record.
  • Policy gaps: p=none, testing mode, pct below 100, sp=none under p=reject, missing rua.
  • Subdomain fallback to the organizational domain, shown explicitly when it happens.

Related tools

Frequently asked questions

What is a DMARC record?

A TXT record at _dmarc.yourdomain.com that tells receiving mail servers what to do with messages that claim to be from your domain but fail authentication, and where to send reports about them. It is defined in RFC 9989 (May 2026, formerly RFC 7489), with reports covered by RFC 9990 (aggregate) and RFC 9991 (failure). The policy (p=) is none, quarantine or reject. DMARC builds on SPF and DKIM: a message passes DMARC when at least one of those passes and the domain it validated "aligns" with the domain in the visible From header. That alignment check is what SPF and DKIM on their own cannot do.

What should my first DMARC record be?

v=DMARC1; p=none; rua=mailto:[email protected]. That publishes a monitoring policy: nothing changes for your mail, but receivers start sending you daily aggregate reports listing every server that sent mail as your domain and whether it passed. Read them for at least a month, fix any legitimate sender that fails (usually by adding it to SPF or turning on DKIM in the provider's settings), then move to p=quarantine for about as long and finally p=reject. RFC 9989 §7.4 adds a caution: if people at your domain post to mailing lists, p=reject can get their list mail rejected, and it advises such domains not to publish p=reject at all. Going straight to reject without reports is how companies lose their own invoices and password resets.

Why does the tool say my report address needs authorisation?

If your rua or ruf address is in a different domain than the one publishing the policy (for example [email protected] for example.com), receivers will not send reports there unless that other domain agrees to receive them. RFC 9990 §4 (formerly RFC 7489 §7.1) requires a TXT record at example.com._report._dmarc.dmarc-service.com containing v=DMARC1. Report services normally publish this for every customer automatically, but if yours has not, you get no reports and no error. The checker looks the record up so you can tell.

What do t, pct, sp, np, adkim and aspf do?

t=y is testing mode, new in RFC 9989: receivers are asked to apply one level below your policy, so reject acts as quarantine and quarantine acts as none, while you watch the reports. pct is the older rollout tag; RFC 9989 marks it historic because only pct=0 and pct=100 worked reliably, and t=y replaces pct=0. Some receivers still honor pct, so the checker still reads it. sp sets a separate policy for existing subdomains and np one for subdomains that do not exist in DNS; without them they inherit p. adkim and aspf choose relaxed (r, the default) or strict (s) alignment: relaxed lets mail.example.com align with example.com, strict requires an exact match. Most domains should leave alignment relaxed; strict mostly breaks legitimate mail from subdomains.

Does DMARC work for subdomains?

Yes. If a subdomain has no _dmarc record of its own, receivers use the organizational domain's record and apply its sp value (or p when sp is absent). So p=reject at example.com also covers anything.example.com unless you publish sp=none, which leaves every subdomain open to spoofing. The checker shows when it had to fall back to the parent domain. RFC 9989 replaced the old Public Suffix List lookup with a DNS tree walk that checks every parent name. This checker approximates that by looking only at the domain and its likely organizational domain (stripping labels and knowing common two-part suffixes like co.uk), so a record published at an intermediate name, or a psd tag, can lead a receiver to a different answer.

Is anything sent to your server?

The Check tab queries public DNS-over-HTTPS resolvers (Cloudflare, falling back to Google) straight from your browser. Generate and Validate run entirely in the page and make no requests. We log only that the tool was used.

Get weekly dev tools and tips