Skip to content
Email Delivery Platform
Talk to engineering

/ Free Tools — DMARC Checker & Generator

Check it, then build it right.

Read any domain's DMARC record tag by tag with the defaults a receiver applies, see every gap that leaves you spoofable, then generate a correct, RFC 9989-ready record — np, t, retired pct — and paste it into DNS. Runs in your browser, nothing sent.

Request infrastructure review What changed in RFC 9989

Reads _dmarc.<domain> over DNS-over-HTTPS, tag by tag, with the defaults a receiver applies. Nothing is sent or stored.

/ What this does

A DMARC record is one line of DNS that tells receivers what to do when a message fails authentication, and where to report it. This tool reads yours tag by tag — showing the default a receiver applies for every tag you left out — flags the gaps that keep you spoofable or blind, and then generates a correct record the RFC 9989 way, with np and t and without the retired pct. Checking and building belong together, because most broken records were built by hand.

The checker gives you a policy verdict — unprotected, monitoring-only, or enforced — plus the specific misconfigurations to fix: a missing reporting address, a policy stuck at none, alignment set too strict too early, or a duplicate record that receivers read unpredictably. The generator turns your answers into a ready-to-publish TXT record and warns you before you make the classic mistakes. Both run in your browser against public DNS.

  • Tag by tag

    Every tag broken out with the receiver default for the ones you omitted, so you read the record the way a mailbox provider actually does.

  • RFC 9989-ready

    Recognizes np, psd, and t, and treats pct, rf, and ri as retired — the May 2026 revision most tools still haven't caught up to.

  • Check + build

    Read an existing record and generate a new one in one place, with validation that catches the mistakes that break your own mail.

  • Browser-only

    The lookup is a read-only DNS-over-HTTPS query; the generator runs locally. Nothing is sent to us and your domain isn't logged.

/ Generate a record

Build an RFC 9989-ready DMARC record

/ Your record — publish as TXT at _dmarc.<domain>

v=DMARC1; p=none

/ How to read it

How do you read a DMARC record?

Read the tags in the order a receiver acts on them: the version, then what to do with failing mail, then where to send reports, then how strictly to match the sender to your domain. The version is always v=DMARC1, unchanged across the 2026 revision for backward compatibility. Then comes the part that decides whether the record protects anything.

p is the policy for your organizational domain: none monitors, quarantine sends failures to spam, reject blocks them. sp sets a different policy for subdomains, and if you omit it, subdomains inherit p. np, added in RFC 9989, sets a policy for subdomains that don't exist at all — the addresses a spoofer invents — which sp doesn't cover. Then rua is where daily aggregate reports go, and it's the tag that turns DMARC from a guess into visibility: without it you're enforcing blind. ruf is optional per-message failure reporting.

Finally, adkim and aspf control alignment strictness — relaxed by default, which is what you want during rollout — and t=y, also new in RFC 9989, tells receivers to apply the next-lower policy while you test a stricter one. Any tag you leave out gets a default the receiver supplies, which is why the checker shows those defaults: the record that protects your domain is the one the receiver reads, not the shorter one you typed.

/ RFC 9989

What changed in DMARC in 2026, and does it break my record?

In May 2026 the IETF published RFC 9989, the Standards-Track revision of DMARC often called DMARCbis, which obsoletes the original 2015 specification. The headline for anyone already running DMARC is reassuring: nothing breaks. Records still begin with v=DMARC1, and receivers must ignore tags they don't recognize, so every deployed record keeps working exactly as before. The change is about what you should build going forward.

Three tags were retired for new records. pct, the percentage sampler that applied your policy to a fraction of mail, is gone — it was applied inconsistently by receivers and never covered subdomains cleanly. rf and ri, the report format and interval tags, went with it. If your current record still has them it will keep working, but this generator leaves them out, and the checker flags them so you know they're legacy.

Three tags were added, and they're worth adopting. np sets a policy for non-existent subdomains — the invented addresses like accounts.yourdomain.com that a phisher might spoof — closing a gap that sp alone left open; setting np=reject is a strong, safe default. t replaces the old percentage-based rollout: t=y asks receivers to apply the next-lower policy while you validate a stricter one, a cleaner way to ramp than pct ever was. And psd flags public-suffix domains, which most senders never need. The practical takeaway: keep your working record, and when you next touch it, build it the RFC 9989 way.

/ The ramp

How do you move from p=none to p=reject safely?

Start at p=none with a working rua address, and change nothing else for a few weeks. This is the listening phase: receivers report every source sending under your domain without any mail being affected, and those reports almost always surface senders you'd forgotten — a marketing platform, a helpdesk, a payment processor — that aren't yet aligned. The point of none isn't protection, it's the inventory you need before you can enforce without collateral damage. Google, Yahoo, and Microsoft require at least this much of bulk senders, so it's also the compliance floor — and for some organizations a legal one, since CISA requires p=reject for US federal domains and PCI DSS v4.0 mandates DMARC for anyone processing card payments.

Once the reports show your legitimate sources authenticating and aligning, move to p=quarantine. Failing mail now goes to spam rather than the inbox, which contains spoofing while still being recoverable if you missed a source. Watch the reports here too — this is where a forgotten sender shows up as legitimate mail landing in spam, and you fix its alignment before it costs you. When quarantine runs clean, advance to p=reject, the end state, where spoofed mail is blocked outright. RFC 9989's t=y lets you test each step by having receivers apply the previous policy while you watch, a safer ramp than the retired pct sampling.

The whole ramp is gated by one thing: reading your reports. A record is a snapshot, but alignment drifts as you add senders, rotate keys, and change providers, so a domain that reached reject cleanly can start failing legitimate mail months later without anyone touching the record. Getting to reject is a project; staying there while your sending grows is continuous operation — which is the part we run, so the policy that protects you doesn't quietly start blocking you.

/ DMARC FAQ

What does the DMARC checker read?
It reads the TXT record at _dmarc.yourdomain.com over DNS-over-HTTPS, confirms it exists and parses cleanly, then breaks it down tag by tag: the policy (p), subdomain policy (sp), non-existent-subdomain policy (np), reporting addresses (rua/ruf), alignment modes (adkim/aspf), failure options (fo), and the test flag (t). For every tag you didn't set, it shows the default a receiver will apply, so you see the record the way a mailbox provider actually reads it, including every default you never set. Then it flags the gaps that leave you spoofable or blind.
What changed in DMARC with RFC 9989?
RFC 9989 — the IETF Standards-Track revision published in May 2026, often called DMARCbis — replaced the original RFC 7489. Records still start with v=DMARC1 and everything deployed keeps working, but three tags were retired for new records: pct, rf, and ri are now historic. Three were added: np sets a policy for non-existent subdomains (closing a typosquatting gap that sp alone doesn't cover), psd flags a public-suffix domain, and t=y is a test mode that asks receivers to apply the next-lower policy while you validate. This checker recognizes all of them and this generator builds records the new way — which many tools still don't.
Is p=none enough?
Not as a destination. p=none is monitoring mode: receivers take no action on mail that fails authentication, which is the right place to start so you can collect reports without risking legitimate mail, and it's the minimum Google, Yahoo, and Microsoft now require of bulk senders. But a domain sitting on p=none indefinitely is still spoofable and doesn't get the full deliverability or brand benefit. The goal is to move to p=quarantine and then p=reject once your reports confirm every legitimate source is aligned. BIMI needs at least p=quarantine before it does anything.
Why does my record exist but mail still fails DMARC?
A published record is only half the picture. DMARC passes when a message is authenticated by SPF or DKIM and that authenticated domain aligns with the visible From domain. A record can be perfectly valid while individual messages fail — because a sending source isn't in your SPF, isn't signing with an aligned DKIM key, or sends from a subdomain your alignment mode doesn't cover. The checker confirms the policy is sound; the aggregate (rua) reports confirm whether real mail passes it. That's why a reporting address isn't optional.
Should I use strict or relaxed alignment?
Start relaxed (adkim=r, aspf=r), which is also the default when you omit them. Relaxed lets a subdomain align with its organizational domain — sub.example.com counts as aligned with example.com — which keeps forwarded mail and most third-party senders passing while you roll out. Strict alignment (s) requires an exact domain match and is worth tightening to only once your reports show every legitimate sender aligning cleanly. Setting both to strict early is one of the most common ways to break your own mail.
Does the checker send or store anything?
No. The lookup runs entirely in your browser as a read-only DNS-over-HTTPS query against a public record anyone can look up. The generator builds the record locally from your inputs. Nothing is sent to our servers, no email is dispatched, and your domain isn't logged.

A correct record is the start. Reaching reject and staying there is the work.

Reading reports, aligning every sender, and ramping through quarantine to reject without blocking your own mail is continuous — and it's exactly what we operate. Check your record, generate the fix, then bring us the ramp.

Book infrastructure review

Related capabilities