DMARC Record Generator – Complete Guide to Creating a DMARC Policy

Spoofed invoices and fake password-reset mails that show your company's domain in the From: line are what DMARC exists to stop. But publish p=reject too early and your own newsletter, CRM or ticket system disappears into receivers' rejection logs. A good DMARC record is less about syntax than about rollout order: monitor first, fix your senders, then enforce.

The DMARC Record Generator builds the TXT record from a few choices: policy, report addresses, and optional subdomain policy, percentage, alignment and failure-reporting settings. It validates every address, warns when reports would go to a domain that has to authorize them, and explains the consequences of each policy. It runs entirely in your browser.

What is a DMARC record generator?

In simple terms

DMARC tells receiving mail servers what to do with mail that claims to come from your domain but fails authentication, and where to send reports about it. The generator is a form that writes this instruction in the exact v=DMARC1; p=… format, so you choose the policy and report address instead of memorizing tag names.

Technical background

DMARC is specified in RFC 7489. The record is a TXT record at _dmarc.<domain>; receivers that find none at a subdomain fall back to the organizational domain. A message passes DMARC when SPF or DKIM passes and the authenticated domain is aligned with the domain in the visible From: header:

• SPF alignment compares the envelope sender (Return-Path) domain with From:.
• DKIM alignment compares the d= domain of a valid DKIM signature with From:.
• Relaxed alignment (r, the default) accepts the same organizational domain, so bounce.example.com aligns with example.com. Strict (s) requires an exact match.

The tags the generator can produce:

When a report address is in a different domain than the one publishing the policy, RFC 7489 §7.1 requires the destination domain to publish <policy-domain>._report._dmarc.<destination-domain> with v=DMARC1. Otherwise receivers do not send reports there.

Why use a DMARC record generator?

• Correct syntax and tag order without typos such as p=reject;rua= missing mailto:.
• Validated report addresses. Each address is checked as a real mailbox format (local part and public domain); a mailto: prefix you paste is accepted and normalized.
• External report warnings. Any address outside your domain triggers a warning that names the exact authorization record the other domain must publish.
• Safe rollout guidance. The tool warns when you enforce without aggregate reports, notes that p=none only monitors, and reminds you to confirm all senders before p=reject.
• Lean records. Default values (pct=100, relaxed alignment, fo=0, sp equal to p) are left out so the record stays short and readable.

Who should use it?

• Domain owners and mail administrators publishing DMARC for the first time.
• Teams moving from p=none to enforcement who want a reviewed record for each step.
• Organizations preparing for mailbox-provider bulk-sender requirements, which include having a DMARC record.
• Agencies and MSPs producing DNS change requests for clients.

How the DMARC generator works

The form runs in JavaScript in your browser and rebuilds the record on every change. Nothing is sent to NetTools.tech and no DNS query is made.

1. The domain is validated as a public domain name; the host becomes _dmarc.<domain>.
2. The record starts with v=DMARC1; p=<policy>.
3. sp= is added only if you chose a subdomain policy different from p.
4. pct= is added only if it is not 100; values outside 0–100 or non-integers are errors.
5. Report addresses are de-duplicated, validated and written as rua=mailto:… and ruf=mailto:…, comma-separated when there are several.
6. adkim=s and aspf=s are added only for strict alignment.
7. fo= is added only when there is at least one ruf address and you chose something other than 0.

Then the guidance runs: missing rua is a warning with p=none and an error with an enforcing policy; external report domains produce a warning; p=reject, failure reports and strict alignment each come with a note. While an error is present or the domain is empty, the record is dimmed and Copy record is disabled.

How to use the NetTools.tech DMARC generator

1. Open the DMARC Record Generator.
2. Enter Your domain, for example example.com. The host to publish appears as _dmarc.example.com.
3. Choose the Policy for mail that fails DMARC: Monitor (p=none, selected by default), Quarantine (p=quarantine) or Reject (p=reject).
4. Enter one or more Aggregate report addresses (rua), one per line.
5. Open Advanced options if you need them: Subdomain policy (sp), Percentage (pct), DKIM alignment (adkim), SPF alignment (aspf), Failure report addresses (ruf) and Failure reporting options (fo).
6. Read the messages under the record, then press Copy record.
7. Publish it as a TXT record at the host shown, replacing any existing DMARC record.
8. Verify the published record with DMARC Lookup, which also checks external report authorization.

Understanding the results

Example: from monitoring to enforcement

Step 1, monitoring. For example.com with Monitor selected and [email protected] as rua, the generator shows host _dmarc.example.com and:

v=DMARC1; p=none; rua=mailto:[email protected]

with the note that p=none only monitors.

Step 2, partial enforcement with an external report service. After fixing the senders found in the reports, switch to Quarantine, set pct to 50 and add [email protected] (a reporting service in another domain):

v=DMARC1; p=quarantine; pct=50; rua=mailto:[email protected],mailto:[email protected]

The generator now warns that [email protected] is outside example.com and that example.net must publish example.com._report._dmarc.example.net with v=DMARC1. You can check both records from a shell:

dig +short TXT _dmarc.example.com
dig +short TXT example.com._report._dmarc.example.net

Step 3, full enforcement. Select Reject and reset pct to 100; the pct tag disappears and a warning reminds you to confirm all senders first.

Common use cases

• First DMARC record for a domain, published together with SPF and DKIM.
• Policy steps from p=none to quarantine and reject, each as a reviewed record.
• Subdomain control: p=reject for the main domain with sp=quarantine while subdomain senders are migrated, or the reverse.
• Adding a report processor: generate the rua list and get the exact authorization record the processor must publish.
• Parked domains: p=reject with a report address, alongside v=spf1 -all.

Troubleshooting

No aggregate reports arrive

Check the published record with DMARC Lookup. If the address is in another domain, that domain must publish the _report._dmarc authorization record. Also allow a day or more: receivers typically send aggregate reports once per day, and small domains with little traffic receive few.

Legitimate mail is quarantined after switching policy

Look at the aggregate reports for the failing source. Usually a service sends with its own Return-Path domain (so SPF is not aligned) and is not DKIM-signing with your domain. Configure DKIM for that service with your domain, or a custom bounce domain that aligns, then retry. Moving back to p=none temporarily is a valid emergency step.

The copy button stays disabled

Either the domain is empty or invalid, pct is outside 0–100, or a report address is malformed. The message list names the problem.

Two DMARC records exist

Receivers treat multiple DMARC records at _dmarc as an error and may ignore the policy. Delete the old record when you publish the new one.

Common mistakes

• Jumping straight to p=reject without reading reports first.
• Publishing the record on the domain itself instead of at _dmarc.
• Using an external report address without the destination's authorization record.
• Enabling ruf and expecting reports from every provider; many never send them.
• Setting strict alignment while a provider sends with a subdomain envelope sender.
• Assuming sp is needed: subdomains inherit p unless sp says otherwise.

Limitations

• The generator does not query DNS: it cannot see your current record, check SPF/DKIM for your senders or verify that an external authorization record exists.
• Report destinations are generated as mailto: URIs only.
• Only the tags listed above are produced; ri (report interval) and rf (report format) are not offered and use their defaults.
• The tool cannot tell you when it is safe to enforce. That depends on your aggregate reports, which you need to read in a report processor or by hand.

Security & privacy

The DMARC generator runs entirely in your browser; the domain and report addresses you type are not sent to or stored by NetTools.tech. Remember that the published record is public: anyone can read the report addresses, so use a dedicated mailbox rather than a personal one. Failure reports (ruf) can contain parts of real messages, including personal data of recipients and senders, which is a reason to enable them only deliberately. No passwords or DNS credentials are ever needed.

Related tools

• DMARC Lookup – read and validate the published record and external report authorization (guide).
• SPF Record Generator – build the SPF record DMARC relies on (guide).
• DKIM Record Generator – create a DKIM key for aligned signatures (guide).
• Email Header Analyzer – see SPF, DKIM and DMARC results of a real message (guide).
• Email Provider Compliance Check – check DMARC presence among bulk-sender requirements (guide).

Summary

A DMARC record tells receivers how to treat mail that fails aligned SPF and DKIM, and where to report it. The NetTools.tech DMARC Record Generator builds that record in your browser, validates report addresses, flags external destinations that need authorization and explains each policy step. Start with p=none and reports, verify with DMARC Lookup, and enforce only when the reports show all legitimate mail passing.