Email authentication tool

DMARC Record Generator

Build a valid DMARC TXT record in 60 seconds. Pick your policy, set your reporting address, copy the result.

When to use this tool

Use the DMARC Record Generator when you need to create a fresh record for a net-new domain, rebuild a record after an authentication audit, or sanity-check the record a vendor recommended before you publish it. It is designed for the practical moment when you already know you need DMARC and want a clean TXT value without memorizing every tag.

For a new domain, the generator helps you start in monitoring mode instead of jumping straight to enforcement. That matters because DMARC is not just a switch; it is a policy plus a feedback loop. A record with p=none and a reporting address lets you learn which services send as your domain, whether those services align SPF or DKIM correctly, and whether unknown traffic is legitimate mail you forgot about or spoofing you should block later.

For an existing domain, this page is useful when old DNS records have accumulated tags nobody remembers. You can recreate the intended state from first principles: policy, reports, subdomain coverage, alignment, and failure reporting. The output is intentionally plain so you can compare it against what currently exists at _dmarc and decide what to change.

It is also useful for vendor recommendations. Email platforms often suggest DMARC snippets, but they may omit your preferred reporting mailbox, use a policy that is too aggressive for your current readiness, or ignore subdomain handling. Build the record here, compare it to the vendor snippet, then publish the version that matches your rollout plan.

The fields explained

p= policy. This is the core instruction for mail using your organizational domain. none monitors, quarantine asks receivers to treat failures suspiciously, and reject asks receivers to block failing mail.

sp= subdomain policy. This controls mail from subdomains such as mail.example.com. If omitted, subdomains inherit p=. Set it explicitly when subdomains should be more or less restrictive than the root domain.

np= non-existent subdomain policy. This tells receivers how to handle mail claiming to come from subdomains that do not exist. It is useful for making anti-spoofing coverage explicit across the long tail of random hostnames attackers may invent.

rua= aggregate reports. This is where mailbox providers send XML summary reports. Add a monitored reporting address so you can see sources, authentication results, and alignment before increasing enforcement.

ruf= forensic reports. This optional tag requests per-message failure reports. Many receivers do not send them, and they can contain sensitive data, so use a dedicated mailbox and only enable it when you understand the privacy implications.

adkim= DKIM alignment. Relaxed alignment allows an aligned organizational-domain match; strict alignment requires an exact domain match. Most organizations start with relaxed alignment unless they have a clear reason to tighten it.

aspf= SPF alignment. This works like DKIM alignment but for the SPF-authenticated return-path domain. Relaxed is the normal default; strict can break legitimate mail if senders use subdomains or third-party bounce domains.

fo= failure options. This controls which authentication failures may trigger forensic reports. The default 0 is conservative. Change it only if you are deliberately requesting more detailed failure signals.

Recommended starting record

For most domains, this is the safest first record because it activates DMARC reporting without asking receivers to quarantine or reject mail yet. Keep the policy at p=none until you have enough aggregate reports to identify every legitimate sender, fix SPF or DKIM alignment gaps, and confirm that high-volume systems are authenticating consistently. Once reporting shows that legitimate mail is aligned, move gradually toward p=quarantine and eventually p=reject.

Common mistakes

The biggest mistake is publishing p=reject before monitoring. Reject is the end state, not the first step for most live domains. If an invoicing platform, CRM, ticketing system, or marketing sender is not aligned yet, immediate reject can block real customer mail.

Another common mistake is missing rua=. A DMARC record without aggregate reporting can still express policy, but you lose the visibility that makes a safe rollout possible. Reports are how you discover forgotten SaaS senders, subdomain traffic, and authentication drift.

Subdomain mistakes are subtle. If sp= is omitted, subdomains inherit p=. That may be exactly what you want, but it can surprise teams that use subdomains for separate mail streams. Choose inheritance deliberately, and set sp= explicitly when the root and subdomains need different treatment.

Finally, watch the mailto: syntax. Reporting addresses should be valid email addresses or full mailto: URIs. A malformed address can prevent reports from reaching the system or mailbox you are relying on for rollout decisions.

How this differs from a DMARC checker

The generator builds a new DMARC TXT record from form inputs. A checker looks up and parses the record already published in DNS. After you copy the generated value and publish it, use the DMARC checker to confirm the public DNS result matches what you intended.

Next steps after generating

First, publish the value as a TXT record at _dmarc.yourdomain.com with your DNS provider. DNS interfaces vary, but the host/name is usually _dmarc and the value is the generated string beginning with v=DMARC1.

Second, validate the published record with the checker after DNS has propagated. Confirm there is only one DMARC TXT record, that the policy is correct, that the reporting address is present, and that subdomain coverage matches your intent.

Third, start reviewing aggregate reports. Use those reports to approve legitimate senders, fix SPF and DKIM alignment, and plan a measured move from monitoring to enforcement. DMARC works best as an operational process: generate, publish, validate, observe, fix, and then enforce.