DMARC has moved beyond being a DNS record that you publish once and forget. **RFC 9989**, published
by the IETF in 2026, updates the DMARC specification and replaces the earlier RFC 7489 and RFC 9091 documents. At
the same time, major mailbox providers continue to enforce stricter email authentication requirements for
bulk
senders.
A properly configured DMARC record helps receiving mail systems determine what to do with messages that
fail
DMARC evaluation and gives domain owners visibility into how their domain is being used. But simply checking
whether DMARC is enabled is not enough.
A proper DMARC check should also examine the published DMARC policy, reporting destinations,
subdomain
policy, SPF and DKIM alignment, percentage controls, and potential configuration issues or outdated
elements.
Understanding these settings is essential for improving email deliverability, protecting your domain from
email spoofing, and maintaining a reliable email authentication setup.
That is why I built the DMARC Record Analyzer — a live, read-only DMARC checker and DNS analysis
tool that reads your published DMARC record and turns the raw DNS configuration into structured findings and
DNS
evidence instead of simply telling you “DMARC found.”
Source of Truth
DMARC behavior and syntax should ultimately be evaluated against the applicable **IETF specification**, rather
than
simplified third-party summaries. This **DMARC record analyzer** is designed to surface your published DNS
configuration and provide deterministic findings based on what is actually present in DNS.
It does not replace the underlying standard or a complete **email authentication assessment**, including a broader
SPF, DKIM, DMARC, and email deliverability review.
Your Domain Doesn't Send Email? You May Still Need DMARC.
A domain does not need to send legitimate email to be impersonated. If your domain is not intended to send
email, an appropriate DMARC policy can still help receiving systems reject or otherwise handle
messages that
falsely claim to come from your domain.
This matters because domain spoofing and email impersonation are not theoretical risks. Security
researchers
and
incident reports continue to document attackers abusing weak or missing email authentication to make fraudulent
messages appear to come from trusted organizations.
[Example: 2026 spoofing incident involving a law firm's domain
↗](https://www.sentrian.com.au/blog/email-spoofing-attempt-blocked-from-targeting-local-law-firm)
Builds a DMARC record against RFC 9989/9990/9991 (DMARCbis, published May 2026), the current
replacement for the 2015 RFC 7489 spec. Pulls your live record from Cloudflare's 1.1.1.1 resolver first, so you
can see what's actually published before changing anything.
How to use the DMARC Generator
Step 1 — Enter your domain:
Enter the domain you want to check and configure, such as example.com.
Step 2 — Check your live DMARC record:
The generator queries Cloudflare's 1.1.1.1 resolver to find the DMARC record currently published in
DNS, so you can review your existing configuration before making changes.
Step 3 — Configure your DMARC policy:
Review the detected record and choose the DMARC policy, reporting, and other available options that match your
email-sending setup.
Step 4 — Generate the DMARC record:
The generator builds the corresponding DMARC TXT record based on your selected configuration, ready to publish at
_dmarc.yourdomain.com.
Step 5 — Publish and verify:
Add the generated TXT record to your DNS provider, wait for DNS propagation, then check the domain again to confirm
that the intended DMARC configuration is publicly visible.
01
Check what's currently published
Enter the domain people receive email from (not a subdomain like mail., unless that's what you send from). This queries _dmarc.yourdomain.com and the root domain's SPF, live, via Cloudflare's
public DNS — nothing is sent to any server but 1.1.1.1.
02
Set your policy
Each control below maps to one DMARC tag. Leaving a field at its default omits that tag from
the record — DMARC assumes sensible defaults, and a shorter record is easier to audit.
What it does: tells receiving servers what to do with mail claiming to be from you
that fails SPF/DKIM alignment. Start at none if you've never run DMARC — it only reports, it doesn't
block anything. Move to quarantine, then reject, once your reports show all legitimate senders are passing.
What it does: overrides p
specifically for real subdomains (e.g. newsletter.example.com).
Only set this if a subdomain needs a different policy than the main domain — otherwise leave it inherited.
What it does: under the old spec, a subdomain that doesn't exist (like xyz123.example.com) had no explicit policy — a common spoofing gap.
np=reject closes it. If your main policy is already reject, this is inherited automatically and adding it changes
nothing.
What it does: RFC 9989 retires the old pct tag (percentage rollout), which mail providers implemented
inconsistently. t=y replaces it: a reject policy is treated as quarantine, quarantine
as none. Use it while you stage toward a stricter policy, then
remove it.
What it does: relaxed allows the DKIM signing domain to be any subdomain of your
organizational domain. Strict requires an exact match. Relaxed is fine for most setups, including ones using
a third-party sender (Mailchimp, Brevo, SendGrid).
What it does: same idea as adkim, but for the SPF domain match. Keep this relaxed
unless you specifically need the From address and the SPF-checked domain to match exactly.
What it does: daily XML summaries of who is sending mail as your domain, and whether
it passed. This is how you actually find every system sending on your behalf before you enforce anything.
Without this tag you're publishing DMARC blind. Comma-separate multiple addresses.
What it does: per-message reports for individual failures, sent in near real time.
Most receivers throttle or ignore this now due to privacy concerns, and it can leak message metadata. Leave
blank unless you have a specific reason to want it — rua covers
almost every real use case.
▸ Advanced tags (fo, psd) — most domains don't need these
Only takes effect if ruf is set above. Most
setups leave this at the default (0).
What it does: a public suffix domain is something like .com or a registrar-style domain where unrelated third parties get
their own subdomains. If you're a normal business publishing DMARC for your own company domain, leave this
unset.
03
Your DNS record
Publish this as a TXT record. Updates live as you change
settings above.
v=DMARC1; p=none
Type: TXTHost / Name:_dmarcTTL: 3600 (or your provider's default)