What is the best free DMARC record generator?

A DMARC generator is useful for the same reason any DNS record generator is useful: the syntax is picky, the common mistakes are consistent, and a template catches them before you publish. But DMARC has something SPF and DKIM do not: a policy choice with real operational consequences. A generator that produces p=reject on day one is actively dangerous. A generator that produces p=none with no reporting address is useless. This guide covers what a good DMARC generator needs to do, what pitfalls to avoid, and how to validate the output in 2026.

What a useful DMARC generator produces

At minimum a generator should give you three records for a staged rollout: one for monitoring, one for gradual enforcement, and one for full enforcement. The reason is that DMARC rollout is a process, not a single action. Publishing p=reject straight away on a domain with unaudited senders will bounce legitimate mail for weeks.

Monitoring record (day 1):

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

Gradual enforcement (week 5 after audit):

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

Full enforcement (week 10-12):

v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=s; aspf=s; fo=1

Any generator that skips the staged approach and outputs only p=reject is doing you a disservice.

The tags that matter and the ones that don't

DMARC has ten tags. You need to understand four. The rest are edge cases.

Required or near-required:

• v=DMARC1 — version, always present.
• p= — policy (none, quarantine, reject). The main decision.
• rua=mailto: — aggregate reports. Without this you are flying blind.

Important:

• sp= — subdomain policy. Defaults to p=. Override if subdomains should differ.
• pct= — percentage of failing mail to apply policy to. Use during rollout.
• adkim= / aspf= — alignment mode. Default relaxed, which is almost always right.

Rare:

• ruf=mailto: — forensic reports. Most receivers no longer send them due to privacy; setting this usually has no effect.
• fo= — forensic options. Only matters if ruf= is honoured.
• ri= — report interval. Default 86400 (daily) is what you want.

A generator that asks you to configure all ten tags is overwhelming you. You need version, policy, and rua.

Step-by-step using any generator

Step 1: Set up the report mailbox. Create dmarc@yourdomain and configure it to receive mail. Aggregate reports arrive as XML attachments, roughly 1-100KB each, one per receiver per day. For low volume a regular mailbox works. For higher volume you want a parser (OpenDMARC, several open-source options, or commercial dashboards).

Step 2: Generate the monitoring record.

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

Step 3: Publish. At your DNS provider, create a TXT record at host _dmarc (not @, not the apex). The full FQDN is _dmarc.example.com.

Step 4: Verify. Within a few minutes, scan with IntoDNS.ai. Confirm the record is found, syntactically valid, and rua= is correctly formatted.

Step 5: Wait and audit. Aggregate reports arrive daily within 24-48 hours. After 14 days, review. Identify:

• Every IP sending mail as your domain.
• Every service that fails alignment.
• Any unknown IPs (shadow IT or spoofing).

Step 6: Fix alignment failures. For each SaaS service that fails alignment, configure DKIM signing with d=yourdomain or set the envelope sender domain to a subdomain of yours. This is the real work of a DMARC rollout.

Step 7: Move to quarantine.

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

Watch reports for 7-14 days. Raise pct= to 50, then 100.

Step 8: Move to reject.

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

At this point any spoofed mail claiming to be from your domain is rejected by compliant receivers (Gmail, Microsoft, Yahoo, most commercial filters).

Where generators typically go wrong

Putting the record at the wrong host. DMARC must be at _dmarc.domain.tld, not the apex. Many generators assume the user knows this and just output the record text; many users paste it into the apex TXT record and it does nothing.

Using multiple rua= addresses incorrectly. Multiple addresses are allowed but must be comma-separated, not semicolon: rua=mailto:[email protected],mailto:[email protected].

Reporting to a domain you don't control. If rua=mailto:[email protected], and vendor.com is not your domain, vendor.com must publish an authorisation record: yourdomain._report._dmarc.vendor.com TXT "v=DMARC1". Without this, receivers will not send reports to that address.

Setting p=reject with pct=100 on day one. The single most damaging mistake. You will bounce legitimate mail from every service that fails alignment — and alignment failures are common on fresh rollouts.

Using adkim=s and aspf=s without need. Strict alignment requires exact domain match. Most domains can and should use relaxed (the default), which allows mg.example.com to align with example.com.

Ignoring the subdomain policy. If your apex has p=reject but subdomains send from misconfigured platforms, the subdomains will be rejected too because sp= defaults to p=. Either set sp=none during rollout or publish per-subdomain DMARC records.

Validating generator output

After publishing, use IntoDNS.ai to confirm:

• Record present at _dmarc.yourdomain.
• Record syntactically valid.
• rua= formatted correctly and domain controllable.
• Policy is none, quarantine, or reject (not any other value).
• Single record only (multiple DMARC records is an error).
• Alignment modes and pct= match your rollout phase.

IntoDNS.ai also confirms whether aggregate reports can actually be delivered to your rua= address, which is a common silent failure.

Troubleshooting

No aggregate reports after 48 hours. Check the rua= mailbox works, accepts attachments, is not on a blocklist, and authorises the reporting domain if it is not your domain.

Reports arrive but show 100% fail. Your alignment is broken for all senders. Audit your SPF/DKIM alignment and fix before moving past p=none.

Some legitimate mail being quarantined at p=quarantine. Expected on a fresh rollout. Identify which service, fix alignment, iterate.

Mail from forwarding addresses fails DMARC. SPF breaks on forwarding. DKIM usually survives. If DKIM passes, DMARC still passes. If your forwarding users are getting bounces, they likely have only SPF, not DKIM — fix DKIM.

DMARC record parses but receivers ignore it. Check for trailing whitespace, non-printable characters, or multiple TXT records on _dmarc. DNS-level problems cause receivers to skip the record silently.

When to use IntoDNS.ai

IntoDNS.ai is the validation step for any DMARC change. After each generator output, publish the record, scan, and confirm it parses as intended. Repeat for every rollout phase (p=none, p=quarantine, p=reject). This is the difference between a published record and a working DMARC policy.

Choosing an aggregate report destination

The single most consequential choice in your DMARC record is rua=. Options:

Option A: self-hosted mailbox. Send reports to dmarc@yourdomain and parse manually or with OpenDMARC. Free, private, works for low-to-medium volumes (under 10,000 messages/day aggregate). Gets overwhelming past that.

Option B: shared inbox with scripts. Several open-source parsers ingest the XML and produce readable dashboards. Suitable for medium-volume domains. Requires maintenance.

Option C: managed DMARC platform. A third-party service that aggregates, normalises and dashboards the reports. Good for high volume and multiple domains. Cost ranges from free tiers (limited) to several hundred euros per month. Make sure to publish the required authorisation record at the provider's domain.

For most small-to-medium domains, Option A or B is sufficient. The choice is not permanent — you can migrate later by updating rua=.

DMARC for subdomains

DMARC's subdomain policy behaviour surprises many operators. A record at _dmarc.example.com with p=reject applies to both example.com and every subdomain that does not have its own _dmarc record. If you have subdomains you do not want enforced (because they are managed by a team you do not control, or send from unauthenticated platforms), use sp=none:

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

Alternatively, publish per-subdomain DMARC records. _dmarc.marketing.example.com overrides the parent's sp= for that subdomain. This is the cleaner long-term approach for large domains.

A final sanity check

A common pattern that looks correct but is broken: the DMARC record at the apex is fine, but the subdomain that most mail comes from has its own SPF and DKIM that do not align with the apex. The subdomain inherits p=reject via sp= default, and mail from that subdomain fails DMARC. Fix by either publishing a subdomain-specific DMARC with p=none during rollout, or by ensuring the subdomain's DKIM signs with d=example.com (relaxed alignment) rather than d=sub.example.com (strict alignment).

Maintenance after rollout

Reaching p=reject is not the end. DMARC drifts. New SaaS tools get signed up for, DKIM keys rotate, ESPs change their infrastructure. A maintenance cadence worth following:

• Weekly. Scan the domain on IntoDNS.ai and review any regressions. Check the rua= inbox has reports from the past 7 days.
• Monthly. Parse aggregate reports for the month. Look for new source IPs, services with rising failure rates, and unexpected sending patterns. Alert on any unknown high-volume sender — that is usually either shadow IT or active spoofing.
• Quarterly. Audit SPF lookup count, DKIM key length and age, BIMI logo and certificate validity, MTA-STS policy file reachability.
• Annually. Rotate DKIM keys to fresh 2048-bit. Review every tag in your DMARC record. Reconfirm rua= address is monitored.

DMARC reporting privacy

Aggregate reports contain metadata about mail flows — source IPs, counts, pass/fail results — but never message content. Forensic reports (ruf=) historically contained redacted message samples, which is why most receivers stopped sending them. If your rua= is managed by a third party, the reports reveal your sending patterns to that third party. For most organisations this is acceptable; for highly regulated or sensitive mail flows it matters.

Self-hosting the rua= endpoint keeps reports entirely under your control. A minimal setup is a mailbox plus an XML parser. Open-source parsers render the reports into a readable dashboard without sharing data externally.

Common edge cases

ESP that cannot sign with your domain. Some smaller ESPs only sign with their own d=. That signature passes DKIM but does not align for DMARC. Either switch ESP or send that mail from a subdomain with its own DMARC at p=none.

Forwarding addresses on your domain. If users forward user@yourdomain to external addresses, DKIM must pass for DMARC to survive. Ensure DKIM is signing everything leaving your domain.

Mailing lists that modify messages. Lists that add footers or prefix subjects break DKIM. ARC can help but many receivers do not fully honour ARC yet. For internal lists, use a subdomain with p=none.