DMARC Record Generator

Build a correct DMARC record in seconds — pick your policy, add your reporting address, and copy the exact TXT record to publish in DNS. Free, no signup.

Used to show the exact host name to publish — the record itself doesn't contain it.

Start at none to observe, then tighten once reports look clean.

Where daily XML summaries are sent. Comma-separate multiple addresses.

Advanced options (sp, alignment, pct, ruf)

Subdomains inherit p unless you set this. Attackers love unused subdomains — reject is a strong choice once you're at enforcement.

Relaxed allows subdomain matches (mail.yourdomain.com signs for yourdomain.com). Strict requires an exact match — most domains should stay relaxed.

Same idea for the SPF (Return-Path) domain.

Applies quarantine/reject to a percentage of failing mail during rollout. Retired in DMARCbis — use briefly if at all.

Per-message failure samples. Rarely sent by large providers; contains message data.

Your DMARC record

Publish this as a TXT record in your DNS.

Host / Name

_dmarc.yourdomain.com

Value (TXT)

v=DMARC1; p=none;

Record type: TXT · TTL: your provider's default (e.g. 3600) is fine.

No rua address set — you'll get no aggregate reports, which means no visibility into who is sending as your domain. Add one before publishing.
p=none is monitoring mode: receivers report but deliver everything, including spoofed mail. It's the right starting point — plan to move to quarantine, then reject, once your reports show all legitimate senders passing.

After you publish

  1. Add the TXT record at your DNS host and allow up to an hour for propagation.
  2. Verify it with the free DMARC checker.
  3. Watch your aggregate reports, fix SPF and DKIM for every legitimate sender, then step up to quarantine and reject.

What is a DMARC record generator?

A DMARC record is a single TXT entry in your DNS that tells receiving mail servers what to do with messages that fail SPF and DKIM alignment — and where to send reports about them. The syntax is simple but unforgiving: a misplaced tag or a missing mailto: prefix and receivers ignore the record entirely. This generator assembles the record from plain-language choices, flags the mistakes we see most often (no reporting address, sampling at p=none, strict alignment breaking subdomain senders), and gives you the exact host and value to paste into your DNS provider. Once it's live, verify it with the DMARC checker and read the full guide to creating a DMARC record.

Email authentication knowledge base

Three decisions produce a valid record. First, choose the policy (p): start with none so receivers report on your mail without blocking anything. Second, set a rua address — the mailbox that receives daily aggregate reports showing who sends as your domain. Third, publish the generated value as a TXT record at the host _dmarc.yourdomain.com in your DNS. The generator above assembles the exact string, so the only real work is choosing the policy and the reporting address.

In your domain's DNS, wherever you manage it — Cloudflare, GoDaddy, Route 53, your registrar, or your MSP's DNS console. Create a new TXT record, set the host or name field to _dmarc (some providers want the full _dmarc.yourdomain.com), paste the generated value, and save. Propagation is usually minutes but can take up to an hour. Then confirm it resolves with a DMARC checker.

Start with p=none unless you already know every service that sends for your domain and have verified their SPF and DKIM alignment. None is monitoring mode: nothing is blocked, but you receive reports that reveal every sender using your domain — including tools someone in marketing signed up for years ago. Once reports show all legitimate mail passing, move to quarantine (failing mail goes to spam), then reject (failing mail is refused). Jumping straight to reject without monitoring is how companies block their own invoices.

rua is where receivers send aggregate reports — daily XML summaries of which IPs sent mail claiming to be your domain and whether it passed SPF, DKIM, and alignment. Use a dedicated mailbox (dmarc-reports@yourdomain.com) or, more practically, a DMARC monitoring service's address, since raw XML across dozens of receivers is painful to read by hand. That's the part Palisade automates: it collects the reports, translates them into named senders, and tells you what to fix.

Usually not. ruf requests per-message failure samples, but most large mailbox providers — including Gmail — don't send them, for privacy reasons, so coverage is thin. The samples can also contain message content, which raises handling questions. Aggregate (rua) reports are what you actually work from; add ruf only if you have a specific investigative need and a mailbox prepared for sensitive data.

They control how closely the SPF and DKIM domains must match your From domain. Relaxed (the default) accepts subdomain matches — mail.yourdomain.com aligns with yourdomain.com. Strict requires an exact match. Nearly every domain should stay relaxed: legitimate services routinely send from subdomains, and strict alignment breaks them for little security gain. Consider strict only for tightly controlled domains where you know exactly one sender exists.

pct applies your quarantine or reject policy to only a percentage of failing mail, as a way to ease into enforcement. In practice it caused confusion (receivers implemented it inconsistently) and DMARCbis — the updated DMARC standard published as RFC 9989 — retires it entirely. If you want a gradual rollout, the modern path is none → quarantine → reject, watching reports at each step, rather than percentage sampling.

The generator builds the record you should publish; the checker reads what your domain currently has and evaluates it. Typical flow: generate a record here, publish it in DNS, then run the checker to confirm it resolves and parses correctly. If you're auditing a domain you manage — or a client's — start with the checker to see what exists before deciding what to change.