DMARC Generator

Build and publish a DMARC DNS TXT record

Use this DMARC generator to assemble a valid record value from policy, reporting, subdomain, alignment, rollout, and failure-reporting choices. Start with a monitoring, quarantine, rejection, or gradual-rollout template, or work through the wizard from scratch. The result includes a tag-by-tag explanation, validation feedback, copy and text-download controls, and a deployment roadmap.

The record is generated and validated in your browser. The tool does not upload your configuration, change your DNS, send test messages, or collect the reports addressed by rua or ruf. You must publish the generated value with the DNS provider that hosts your domain's authoritative nameservers, then inspect the reports separately.

How to generate the record

• Choose p=none if you are still discovering legitimate mail sources. Choose p=quarantine or p=reject only after those sources produce an aligned SPF or DKIM pass.
• Add a dedicated aggregate-report mailbox such as dmarc-reports@example.com. The generator adds the required mailto: prefix and supports more than one destination.
• Enable forensic reports only if you understand their privacy and mailbox-volume implications. These reports can contain message headers or content, and not every receiver sends them.
• Decide whether subdomains inherit the main policy or receive a separate sp policy. Then choose relaxed or strict alignment independently for SPF and DKIM.
• Review the advanced settings for sampling, failure triggers, report format, and report interval. Defaults are omitted from the generated value when the tag is unnecessary.
• On the results step, fix validation errors before copying the record. The displayed grade is a configuration aid, not a DNS lookup or delivery test.

What each DMARC tag controls

Worked DMARC record examples

A practical monitoring record is v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com. It requests aggregate reports without asking receivers to quarantine or reject DMARC failures. Replace the example mailbox with a real address that can accept compressed XML attachments.

A staged quarantine value produced by the generator might be v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; pct=25. Here, pct=25 is a legacy sampling request rather than a delivery guarantee. A simpler full-enforcement value is v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com. Because no sp, adkim, or aspf tags appear, subdomains inherit rejection and both alignment modes use their relaxed defaults.

If a controlled environment truly requires exact matches and failure reports, the tool can generate a value such as v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-failures@example.com; adkim=s; aspf=s; fo=1. Test every sending platform before using this configuration: strict alignment commonly exposes vendor return paths, vendor DKIM domains, aliases, and subdomain differences.

Publish the TXT record at _dmarc.example.com

For the domain example.com, the complete DNS owner name is exactly _dmarc.example.com. The record type is TXT, and the value is the generated string beginning with v=DMARC1. Most hosted DNS forms automatically append the zone name, so their Host or Name field should contain only _dmarc. Do not use @, which means the zone root, and do not enter _dmarc.example.com if the form would turn it into _dmarc.example.com.example.com.

• Cloudflare: open the domain's DNS Records page, select Add record, choose TXT, enter _dmarc as Name, paste the generated record into Content, leave TTL on Automatic unless you have a reason to change it, and save. Cloudflare adds TXT quoting when needed.
• GoDaddy: open Domain Portfolio, select the domain, open DNS, choose Add New Record, and select TXT. Set Name to _dmarc, Value to the generated string, choose the TTL, and save.
• Namecheap: open Domain List, choose Manage, then Advanced DNS and Add New Record. Select TXT Record, set Host to _dmarc, paste the value, choose the TTL, and save all changes. This path applies when Namecheap hosts the authoritative DNS; otherwise, edit records at the nameserver provider.

If a DMARC record already exists, edit it instead of adding another. Multiple DMARC TXT records at the same owner name can make policy discovery fail. After saving, query the authoritative result with dig +short TXT _dmarc.example.com or an equivalent DNS lookup. Confirm that the response contains one logical record, starts with v=DMARC1, and does not contain duplicated hostnames, smart quotes, or a pasted label such as Value:.

How to read a DMARC aggregate report

Aggregate reports usually arrive as compressed XML attachments. Begin with report_metadata to identify the reporting organization and reporting window, then confirm that policy_published matches the record you intended to deploy. A cached older policy can appear during a DNS change, so do not diagnose sender authentication from the policy block alone.

Each record groups a sending source and outcome. Read row/source_ip and row/count first, then map that IP to your mail platform, application, support system, marketing provider, or an unknown source. Under policy_evaluated, dkim and spf show the DMARC alignment results, while disposition shows how the receiver handled that group. A reason can explain why local policy, forwarding, or another override produced a different disposition.

Next compare identifiers/header_from, the domain visible to the recipient, with identifiers/envelope_from, the MAIL FROM domain evaluated by SPF. Finally inspect auth_results for the raw SPF domain and DKIM signing domain. A raw SPF result can pass while policy_evaluated/spf fails because the vendor's return-path domain does not align with the visible From domain. The same is true when DKIM validates with a vendor-owned d= domain that does not align. DMARC passes when at least one mechanism both authenticates and aligns; it does not require both.

Investigate known sources with no aligned pass before increasing enforcement. For an approved service, configure a custom aligned return path, aligned DKIM signing, or both. Treat an unfamiliar source with repeated failures as either unauthorized use or a forgotten sender until ownership is verified. Do not authorize an IP merely because it appears often; identify the application and responsible owner first.

Move from monitoring to quarantine to reject

• Publish p=none with rua. Inventory every legitimate source in the aggregate data, including transactional applications, help desks, invoices, marketing systems, scanners, and delegated subdomains.
• Fix each legitimate stream so SPF or DKIM produces an aligned pass. Prefer having both available, because forwarding often breaks SPF while message modification can break DKIM.
• Change to p=quarantine when known sources are aligned. If you use the generator's pct control for a staged request, remember that receiver support is not guaranteed. Keep reading aggregate reports and investigate legitimate mail that receives a quarantine disposition.
• Change to p=reject only when failures from legitimate sources have been resolved. Continue collecting rua reports after enforcement so new vendors, configuration drift, and expired DKIM setup are visible.

Common DMARC failure modes

• SPF passes but DMARC fails: SPF authenticated the envelope sender, but that domain did not align with the visible From domain. Adding a vendor's IP to SPF does not fix alignment; configure the vendor's custom return-path domain or use aligned DKIM.
• Forwarding breaks SPF: the forwarder's IP is normally absent from the original sender's SPF authorization. If the forwarder rewrites MAIL FROM, SPF may pass for the forwarder's domain but still be unaligned. An intact, aligned DKIM signature can preserve the DMARC pass.
• A mailing list or gateway breaks DKIM: subject tags, footers, disclaimers, or body transformations can invalidate the original signature. Review override reasons and Authentication-Results headers rather than weakening the domain policy blindly.
• Subdomain policy is misunderstood: without a subdomain's own record, the organizational-domain record applies and sp overrides p for subdomains. A specific record at _dmarc.mail.example.com takes precedence for mail using mail.example.com.
• Reports never arrive: verify that the mailbox exists and can receive attachments. When rua or ruf points outside the policy domain, the destination domain normally must publish authorization for external DMARC reports.
• The record is ignored: look for more than one DMARC record, a record at the zone root instead of _dmarc, a duplicated domain suffix, a missing first v=DMARC1 tag, or an invalid policy value.
• Strict alignment blocks a legitimate vendor: adkim=s and aspf=s require exact domains. Relaxed alignment is usually the safer starting point when approved senders use subdomains.
• Failure reporting is overconfigured: fo has no effect without ruf, 0 and 1 should not be combined, and receivers may decline to send message-specific reports.

When this generator is not enough

Use a DNS lookup tool after publishing because this generator does not read your live zone. Use a message-header analyzer or a controlled delivery test when you need to inspect actual SPF, DKIM, and DMARC results. Use a DMARC report-processing service when compressed XML volume makes manual grouping and source ownership impractical. Those tools complement the record generator: they verify deployment and mail behavior, while this page builds and validates the policy value you intend to publish.