Email infrastructure / DNS record builder

DMARC Generator

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.

Read RFC 9989 at the RFC Editor ↗

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: TXT Host / Name: _dmarc TTL: 3600 (or your provider's default)