DMARC Record Generator
Build a DMARC TXT record with the right policy for where you actually are in the rollout, starting in monitoring mode is not optional, it's how you avoid blocking your own legitimate email.
Stop email fraud that impersonates your domain.
Email that impersonates your business, invoices, wire instructions, or phishing links that appear to come from your own domain, is one of the more damaging things a small business can run into, and it doesn't require breaking into anything. DMARC is the DNS record that tells other mail servers what to do with messages that fail to authenticate as genuinely from you, and, just as importantly, sends you reports showing who is actually sending mail using your domain before you block anything.
This generator builds that DMARC record for you, matched to whatever stage of rollout you're actually at. Paste an existing record to get it checked for common mistakes, or start from scratch by choosing a policy, monitoring only, quarantining suspicious mail, or rejecting it outright, along with where reports should be sent and how strictly SPF and DKIM need to align.
DMARC depends on SPF and DKIM already being set up correctly, it enforces them rather than replacing them. If neither is in place yet, start there first. Once you have a record, publish it exactly as generated at the DNS host name shown below the output, not at your domain's root.
Paste what's in your _dmarc DNS entry today. We'll flag the common problems and tell you the recommended next step for your rollout stage.
Recommended path: start at none for 1-2 weeks to see reports, move to quarantine once senders look clean, then reject for full protection. Don't skip straight to reject.
Generated record
Copy the record below exactly as shown into a single TXT entry, don't split it across multiple DMARC records.
DMARC, in plain English.
DMARC ties SPF and DKIM together and tells receiving mail servers what to do when a message fails both checks, and, critically, sends you reports so you can see who's sending email as your domain before you start blocking anything. It requires SPF and/or DKIM to already be set up correctly; DMARC doesn't replace them, it enforces them.
Common mistakes
Jumping straight to p=reject. This is the single most common DMARC mistake. Going straight to enforcement without first monitoring in p=none mode means any sending source you forgot about, a CRM, an invoicing tool, a marketing platform, gets silently blocked with no warning. Ramp up in order: none → quarantine → reject, watching the reports at each stage.
Skipping the rua reporting address. Without an aggregate reporting address, you're flying blind, you'll have no visibility into what's passing, what's failing, or who's sending mail as your domain. Always set this, even in monitor mode.
Publishing the record in the wrong place. DMARC must be published as a TXT record at _dmarc.yourdomain.com, not at the domain root, where SPF lives. This is the most common reason a correctly-built record "doesn't work."
Forgetting subdomains. If you don't set sp, subdomains inherit the main policy, which is usually fine, but worth being deliberate about if a subdomain sends mail differently (or shouldn't send mail at all).
Setting strict alignment without checking first. Strict alignment (s) requires an exact domain match between the visible "from" address and the authenticated domain. Many legitimate sending setups use a subdomain and will fail strict alignment, relaxed alignment (r) is the safer default unless you've specifically verified strict works for every sender.