DMARC Record Generator

Our DMARC record generator turns a few simple choices into a correctly formatted DMARC policy for your domain. Pick a policy, add the address where aggregate reports should go, set alignment and, if you need them, forensic reporting options, and the TXT record updates as you go. It runs entirely in your browser, shows the host (_dmarc) and record type alongside the value, and warns you when a choice could block legitimate email or leave you without reports.

How to use the DMARC generator

1. 1 Choose a policySelect p=none to monitor, p=quarantine to send failing mail to spam, or p=reject to block it. Optionally set a different policy for subdomains.
2. 2 Add a report addressEnter one or more aggregate report (rua) addresses, separated by commas. The generator adds the mailto: prefix for you.
3. 3 Set alignmentLeave DKIM and SPF alignment on relaxed unless you have a specific reason to require an exact domain match.
4. 4 Use advanced options only if neededShow advanced options to add a forensic (ruf) address and a failure reporting option (fo).
5. 5 Copy, publish and verifyCopy the record into a TXT record with the host _dmarc, then run our DMARC checker to confirm it is live.

What a DMARC generator does for you

A DMARC record is a set of tag and value pairs separated by semicolons, published as a TXT record at _dmarc on your domain. RFC 7489 is strict about the format: the record must begin with v=DMARC1, the p tag is required, and report addresses must be written as mailto: URIs. A missing semicolon, a misspelt policy or a bare email address without mailto: can make receivers ignore the record entirely.

Our DMARC generator handles that formatting. It always starts with v=DMARC1 followed by your policy, adds mailto: to each report address and removes it if you typed it yourself, joins several addresses with commas, and only includes optional tags when they differ from the defaults. That keeps the record short and easy to read.

Every DMARC tag the generator can produce

The generator includes only the tags you need. Anything you leave at the default is omitted, because receivers apply the default automatically.

• v=DMARC1: the version tag, always first.
• p=: the policy for your domain, none, quarantine or reject.
• sp=: an optional, separate policy for subdomains. Left out when set to Same, so subdomains follow p.
• rua=: where daily aggregate reports are sent. Strongly recommended.
• adkim=s and aspf=s: strict DKIM and SPF alignment. Added only when you choose strict, as relaxed is the default.
• ruf=: where forensic, per-message failure reports are sent. Available under advanced options.
• fo=: when forensic reports should be generated. Added only alongside a ruf address and when set to something other than the default of 0.

Picking a DMARC policy and subdomain policy

If this is your first DMARC record, choose p=none. It changes nothing about how your mail is delivered, but receivers start sending reports showing every server that sends as your domain and whether it passes SPF and DKIM with alignment. The generator shows a warning whenever you pick quarantine or reject, as a reminder that these policies affect real mail.

The subdomain policy is useful in two situations. If your subdomains never send email, set sp=reject so attackers cannot spoof made-up addresses such as billing.example.co.uk while you are still monitoring the main domain. If a subdomain is used by a marketing platform that is not yet fully authenticated, you might keep sp=none for a while after tightening the main policy. If you leave it on Same, subdomains without their own DMARC record inherit p.

Report addresses, alignment and forensic reports

Aggregate reports are XML files, usually sent once a day by each mailbox provider that received mail using your domain. They do not contain message content, just counts by sending IP and the SPF, DKIM and DMARC results. A shared mailbox works, but the files are hard to read by eye, so many businesses send them to a DMARC reporting service that turns them into charts. If the rua address is on a different domain, that domain must publish an authorisation record, and the generator reminds you of this. Reporting services set it up for you.

Relaxed alignment means mail signed or sent from a subdomain such as mail.example.co.uk still aligns with a From address at example.co.uk. Strict alignment requires an exact match and is rarely worth the extra risk for a small business. Forensic reports contain details of individual failing messages; most large mailbox providers do not send them for privacy reasons, so the generator keeps them under advanced options.

How to publish the DMARC record you generated

Copy the record, then add a TXT record at your DNS host with the host or name set to _dmarc. In Cloudflare, go to DNS, Records, add a TXT record with the name _dmarc and paste the value as the content. In cPanel, use Zone Editor to add a TXT record named _dmarc.yourdomain with the value. If your DNS host asks for the full name, enter _dmarc.example.co.uk; if it appends the domain itself, enter only _dmarc.

Google Workspace and Microsoft 365 both expect you to publish DMARC yourself at your DNS host, and both recommend turning on DKIM signing for your custom domain first. Only one DMARC record is allowed, so if one already exists, edit it rather than adding a second. Then run our DMARC checker to confirm the live record and see whether the policy is graded as monitoring or enforced.

What to look for in your first DMARC reports

Once the record from the DMARC generator is live, aggregate reports usually start arriving within a day or two. Each report lists the IP addresses that sent mail using your domain, how many messages came from each, and whether SPF and DKIM passed and aligned. Your aim is to sort every source into one of three groups.

Treat this as a simple to-do list. When every legitimate source passes with alignment for a couple of weeks, you are ready to come back to the generator and choose p=quarantine.

• Legitimate and passing: your mailbox provider and properly configured platforms. Nothing to do.
• Legitimate but failing: a service you use that is missing from SPF or not signing with your domain's DKIM key. Fix these before tightening the policy.
• Unknown or unwanted: servers you do not recognise. These are often spoofing attempts, and an enforced policy is what stops them.
• Forwarded mail: messages relayed by mailing lists or forwarding services may fail SPF but still pass DKIM, which is expected and not a reason to delay.

DMARC rollout plan and sender requirements

Gmail and Yahoo require bulk senders to publish DMARC, with p=none accepted as the minimum, and Microsoft introduced a similar requirement for high-volume senders to Outlook.com in 2025. The UK National Cyber Security Centre recommends working towards p=reject. A realistic plan for a small business is to publish p=none with rua for two to four weeks, fix any legitimate sources that fail, move to p=quarantine, and then to p=reject once reports stay clean.

Come back to the DMARC record generator each time you tighten the policy so the format stays correct, and keep the same rua address throughout so your reports remain continuous.

Examples you can copy

v=DMARC1; p=none; rua=mailto:dmarc@example.co.uk,mailto:reports@example.co.uk

v=DMARC1; p=none; sp=reject; rua=mailto:dmarc@example.co.uk

v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=s

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; ruf=mailto:dmarc-forensic@example.com; fo=1

Common mistakes to avoid

Frequently asked questions