DMARC Record Generator Guide: Build a DMARC Record Step by Step

Building a DMARC record is a small task with outsized consequences, because the record is a single line of text that tells every receiving mail system in the world what to do with mail that fails authentication for your domain. A typo in that line can mean the difference between a protected domain and an unprotected one, or between a careful rollout and a sudden block on legitimate mail. The generator exists to remove the drafting risk: instead of assembling the tag syntax from memory, you supply the decisions, a domain, a policy, a reporting address, and the generator assembles the record in the correct order with the correct separators. The decisions themselves, however, remain yours, and this guide is about making them well.

The DMARC Record Generator tool lets you enter a domain, policy, and reporting address to generate a DMARC DNS record. It produces record text, not a published record: the output must be placed in DNS as a TXT record at the name _dmarc followed by your domain, and confirmed there, before it has any effect. That gap between generation and publication is where many DMARC projects stall, because generating feels like finishing, while the protective effect only begins at publication. Treat generation as drafting, publication as deployment, and live confirmation as the proof that deployment matches the draft.

The inputs deserve to be taken in order. The domain is the domain the policy protects, written without any prefix, such as example.com rather than www.example.com or mail.example.com, because DMARC policies are published at the organisational domain and apply from there. The policy is the p tag value, and the safe starting value is none, which means monitor and report without blocking. The reporting address is the rua value, written as a mailto address, such as mailto:reports@example.com, and it must be an address someone actually monitors, because aggregate reports are the evidence the rollout runs on. Optional inputs refine the record: the subdomain policy sp, the percentage pct for phased enforcement, and the alignment modes adkim and aspf. Each optional input should be added deliberately, with a reason, rather than accepted as a default nobody examined.

Tag order and syntax are the mechanical details the generator handles, but understanding them helps you check its output. The v tag, reading DMARC1, must come first, because receivers look for it in the first position to recognise the record as DMARC at all. Tags are separated by semicolons with a space after each, and each tag is a name, an equals sign, and a value with no spaces around the equals sign. The record as a whole is the value of a single TXT record, not multiple records, because multiple DMARC records for the same domain make the policy invalid in the eyes of receivers, who will disregard all of them. A generated record that is copied into DNS as two records, perhaps because a line break was mistaken for a record boundary, is a record that protects nothing while looking complete.

A worked example you can follow

Take a sample first rollout for example.com. Enter the domain example.com, the policy none, and the reporting address mailto:reports@example.com. The generator produces: v=DMARC1; p=none; rua=mailto:reports@example.com. Count the tags: 3. Read them in order: v first, which passes the position rule; p=none, which is the monitoring policy; rua present, which means reports will be sent. The record is complete for a first rollout, and its meaning is: watch all mail claiming to be from example.com, block none of it, and report the results to reports@example.com. Publish it at _dmarc.example.com as a single TXT record, and the monitoring phase begins.

Now advance the same domain to enforcement in steps, using pct to phase it. The second record reads: v=DMARC1; p=quarantine; rua=mailto:reports@example.com; pct=25. Count the tags: 4, one more than before, because pct is now present. If the domain receives 2,000 failing messages a day, then 2,000 multiplied by 25, divided by 100, is 500 messages quarantined per day, while 1,500 are delivered as before. After a week with no legitimate mail among the quarantined sample, raise pct to 50, which quarantines 2,000 multiplied by 50, divided by 100, or 1,000 messages per day, an increase of 500 per day over the previous stage. Then raise to 100, quarantining all 2,000, and finally change p to reject, which refuses failing mail outright instead of quarantining it. Each step changes one number, and each number's effect is countable before it is applied, which is what makes the rollout controlled rather than hopeful.

Take a third sample that shows a drafting error the generator prevents. A hand-written record reads: v=DMARC1; p=reject; rua=reports@example.com, missing the mailto: prefix on the reporting address. The tag count is 3, the same as the first sample, but the rua value is malformed, because reporting addresses must be mailto URIs. Reports addressed to a bare address may never arrive, leaving the rollout blind. The generator, given the address reports@example.com, formats it as mailto:reports@example.com, removing that error class entirely. After generation, re-read the output tag by tag and confirm 3 tags, v first, a policy you intended, and a mailto reporting address, before publishing, because even generated output deserves a read-through before it becomes a public instruction to the world's mail systems.

Mistakes to avoid

The first mistake is starting at p=reject, which blocks legitimate senders that were not yet aligned and turns a protection project into a mail outage. The second mistake is generating a record and never publishing it, then assuming the domain is protected because the generator output looked right. The third mistake is publishing two DMARC records for one domain, which invalidates both in receivers' eyes. The fourth mistake is setting a reporting address nobody monitors, which removes the evidence the rollout needs. A generated record is a draft; a published, confirmed, monitored record is a policy.

The DMARC Checker tool reads a generated record back and flags format faults, and the DKIM Checker tool covers the DKIM alignment the policy depends on. For background on checking all three email authentication methods together, see How to Check SPF, DKIM and DMARC.

Checking the result before you publish it

Treat a generated record as a draft to be read, published, and confirmed. Read it tag by tag against the decisions you made, publish it as a single TXT record at _dmarc plus your domain, and then check the live record to confirm it matches the generated text character for character. Set a calendar note for the next rollout stage, such as reviewing the first week's reports before raising pct, so the rollout advances on evidence rather than stalling. Keep the generated text, the publication date, and the stage notes together, because a DMARC rollout is a sequence, and the record of where you are in it is what keeps it moving. A record that is generated, read, published, confirmed live, and advanced on evidence is a domain moving, step by step, from monitoring to enforcement.