DMARC Record Generator
Answer a few questions and copy a valid DMARC TXT record — policy, subdomain policy, alignment, reporting addresses, and rollout percentage included. Then publish it at _dmarc.yourdomain.com.
Your DMARC record
v=DMARC1; p=reject;
Publish it
Create a TXT record at _dmarc.yourdomain.com with the value above. Verify it afterwards with the DMARC record checker.
Building a safe DMARC record
Choose your enforcement policy, add a reporting address, and the generator assembles a valid DMARC TXT record with the correct tag syntax. Each option maps to a real tag: p sets the main policy, sp overrides it for subdomains, rua collects aggregate reports, pct rolls the policy out gradually, and aspf/adkim control alignment strictness.
The safe rollout path
Don't jump straight to p=reject on a domain that sends real mail. Publish p=none with a rua address first, read a couple of weeks of reports, fix any legitimate senders that fail SPF or DKIM alignment, then escalate to quarantine and finally reject. Confirm each step with the DMARC checker.
Choosing values for the DMARC record you generate
Every field you set in the generator maps to one tag in the final string, so the fastest way to create a DMARC record is to decide two things first: how strict you want enforcement to be, and where reports should go. For a domain you are just starting to monitor, generate a record like v=DMARC1; p=none; rua=mailto:[email protected]. Nothing is quarantined or rejected, but you begin receiving aggregate reports. For a domain whose senders are already verified, a fully enforcing record looks like v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:[email protected], which rejects unaligned mail on both the domain and its subdomains.
The sp tag only matters when subdomains send mail. If you leave it out, subdomains inherit the p value, which is usually fine. Set sp explicitly when you want a different posture for subdomains, for example p=reject on the root while a marketing subdomain still runs sp=none, or the reverse: locking down subdomains with sp=reject so attackers cannot spoof an unused name like invoices.yourdomain.com. Add pct only while you are ramping enforcement, since it tells receivers to apply the policy to a sample of failing mail rather than all of it; on a finished record you should not carry a pct value below 100, and it applies to quarantine and reject only, never to p=none. Validate whatever the generator produces with the DMARC checker, and confirm the underlying auth with the SPF checker and DKIM checker before you tighten anything.
For reporting, rua and ruf are different feeds. rua collects the daily aggregate XML summaries that show pass and fail counts per source IP, and it is the address you rely on to see who sends as your domain. ruf requests per-message forensic copies of individual failures, which are far more granular but can contain recipient data and are honored by only a minority of receivers. Almost every deployment lists rua and sends it to a mailbox or a report-processing service; most leave ruf off. If you point reports at a third-party domain, that provider must publish its own authorization record before it will receive your data.
A week-by-week schedule for a DMARC record example in production
The existing rollout notes above give the none to quarantine to reject sequence; this is the calendar version so you can plan the change without guessing. Week 1: publish the monitoring record v=DMARC1; p=none; rua=mailto:[email protected] and change nothing else. Just read the aggregate reports and build a list of every IP and service that sends mail as you, including help desks, invoicing platforms, and marketing tools that people forget about.
Weeks 2 to 4: fix each legitimate sender that fails alignment. That usually means adding the sender to your SPF record or enabling DKIM signing on that platform so the signing domain matches, then re-checking the source in the next report cycle. Do not advance until the reports show your real senders passing and only unknown or spoofed sources still failing.
Only then move to p=quarantine and ramp exposure with the pct tag in three steps, pct=25, then pct=50, then pct=100, pausing at each step to confirm no legitimate mail is being caught. Once quarantine at full coverage is clean, switch to p=reject. Never publish p=reject as the first change on a domain that sends real mail: without the monitoring window you cannot see which of your own senders you are about to block, and a single missed platform can silently drop customer email. Confirm the record at each stage with the DMARC checker.
Frequently asked questions
How do I publish a DMARC record?
Generate the record here, then add it as a TXT record in your DNS with the host/name set to _dmarc (so it resolves at _dmarc.yourdomain.com) and the value set to the generated string. DNS changes can take up to a few hours to propagate; verify with the DMARC record checker afterwards.
What policy should I start with?
Start at p=none with a reporting address (rua=) so you can see which sources send mail as your domain without affecting delivery. Once SPF and DKIM are aligned for all legitimate senders, move to p=quarantine, then p=reject for full protection.
Do I need a reporting address?
It's strongly recommended. The rua= aggregate-report address is how you learn which servers send mail using your domain, and it's essential for safely tightening the policy from none to reject without breaking legitimate mail.
What's the difference between relaxed and strict alignment?
Relaxed alignment (the default) allows subdomains to satisfy alignment — mail from sub.yourdomain.com aligns with yourdomain.com. Strict alignment requires an exact match. Most organizations use relaxed unless they have a specific reason to lock alignment down.
How long after publishing does a DMARC record take effect?
The record itself becomes active as soon as DNS propagates, which is usually minutes to a few hours depending on the TTL of the TXT record. Enforcement of your chosen policy applies from that point. The reporting side is slower: aggregate reports arrive roughly once per day from each receiver, so plan on two to seven days of data before you have a reliable picture of who sends mail as your domain, and longer if you send low volume or reach few large mailbox providers.
Should I turn on ruf forensic reports?
Usually no. Forensic reports (the ruf tag) send per-message samples of failures, which can include recipient addresses and message content, so they carry privacy and data-handling concerns and may conflict with regulations you are subject to. Support is also patchy: most large mailbox providers do not send forensic reports at all, so you get little coverage in exchange for the risk. Aggregate reports via rua give you what you need to roll out safely. Only add ruf if you have a specific investigation need and a mailbox prepared to handle sensitive data.
Do parked or non-sending domains need a DMARC record too?
Yes. Domains that never send mail are common spoofing targets precisely because people forget to protect them. For a parked or non-sending domain, publish a strict record straight away, p=reject with sp=reject, because there is no legitimate mail to break, so the gradual rollout does not apply here. Pair it with an SPF record of v=spf1 -all to say the domain sends no mail, and a null MX record (a single MX with a dot as the target and priority 0) to signal that it receives none either. Together these tell the world the domain is not a mail source.
Related free tools
DMARC closes the email door.
PhishEye closes the rest — lookalike domains, phishing sites, fake apps, and brand impersonation across every channel.