Free Dmarc Record Generator – Create DMARC DNS Records

Create a valid DMARC TXT record for your domain in seconds. Configure your policy, reporting addresses, and alignment options, then copy the DNS record directly to your registrar.

What is a DMARC record?

DMARC — Domain-based Message Authentication, Reporting, and Conformance — is a DNS-based email authentication protocol defined in RFC 7489. It builds on SPF and DKIM to let domain owners publish a policy that instructs receiving mail servers how to handle messages that fail authentication checks.

A DMARC record is a DNS TXT record published at _dmarc.yourdomain.com. When a receiving server processes an inbound message, it looks up this record to determine whether the sending domain passes alignment — and what to do with it if it doesn’t.

Why is DMARC Important?

Without DMARC, anyone can spoof your domain in the From: header and pass it through basic spam filters. DMARC closes that gap by requiring that the domain in the visible From: address aligns with a passing SPF or DKIM check. A p=reject policy at scale effectively eliminates direct-domain spoofing.

Since 2024, both Google and Yahoo require bulk senders to have a valid DMARC policy in place. Deployments without a record — or with p=none indefinitely — risk deliverability penalties for mail sent to Gmail and Yahoo accounts.

The Right DMARC Record Syntax

A DMARC record is a semicolon-delimited set of tag-value pairs. The only required tag is v=DMARC1 and p=. All other tags are optional.

Example minimal record:

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

Example strict record:

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

DMARC Record Tag reference

TagRequiredDescription
v=YesProtocol version. Must be DMARC1.
p=YesPolicy for the organizational domain. Values: nonequarantinereject.
sp=NoPolicy for subdomains. Overrides p= for mail from *.yourdomain.com. Defaults to inherit.
rua=NoComma-separated list of mailto: URIs to receive aggregate XML reports (sent daily).
ruf=NoComma-separated list of mailto: URIs to receive forensic (failure) reports. Support is inconsistent across providers.
adkim=NoDKIM alignment mode. r = relaxed (default), s = strict.
aspf=NoSPF alignment mode. r = relaxed (default), s = strict.
pct=NoPercentage of messages the policy is applied to. Integer 0–100. Defaults to 100.
fo=NoFailure reporting options. Controls when forensic reports are generated. Common values: 01ds.

Relaxed vs strict alignment

Alignment determines how strictly the From: domain must match the authenticated domain. In relaxed mode, organizational domain matching is used — so mail.example.com aligns with example.com. In strict mode, the domains must be identical. Relaxed is the correct default for most senders using ESPs or subdomain routing.

The Best DMARC Deployment approach

The standard deployment sequence is: (1) publish p=none with an rua= address to collect aggregate reports, (2) audit those reports to identify all legitimate sending sources, (3) confirm SPF and DKIM are passing for each source, then (4) move to p=quarantine at a low pct= and gradually increase, and finally (5) escalate to p=reject; pct=100.

Skipping the monitoring phase and deploying p=reject immediately is a common cause of legitimate mail being blocked.

How to publish your DMARC record

Log into your DNS provider and create a new TXT record with the host set to _dmarc (some registrars require the full _dmarc.yourdomain.com) and paste the generated value. TTL of 3600 is standard. Changes typically propagate within minutes but can take up to 48 hours.

After publishing, verify your record using a DNS lookup tool or by querying directly:

dig TXT _dmarc.yourdomain.com +short

Frequently asked questions about DMARC Records

1. Do I need SPF and DKIM before setting up DMARC?

Yes. DMARC requires at least one of SPF or DKIM to be passing and in alignment. DMARC on its own cannot block spoofing — it provides the policy layer on top of those two authentication mechanisms. Deploying DMARC before SPF or DKIM are correctly configured will result in legitimate mail failing.

2. What is a DMARC aggregate report?

Aggregate reports (RUA) are XML files sent daily by receiving mail servers to your specified rua= address. They detail which IP addresses sent mail purporting to be from your domain, and whether SPF and DKIM passed or failed. Most operators use a dedicated reporting inbox or a DMARC analytics platform to parse them.

3. What does pct= do?

The pct= tag limits the percentage of messages the policy is enforced on. For example, p=reject; pct=10 means 10% of failing messages are rejected and 90% are treated as if the policy were none. It is a useful rollout mechanism but not a substitute for a properly deployed policy.

4. Can I have multiple DMARC records?

No. RFC 7489 specifies that exactly one DMARC record must exist at _dmarc.yourdomain.com. If multiple TXT records are found at that name, receivers must treat the result as a DMARC failure and apply no policy.

5. Does DMARC affect subdomains?

By default, subdomains inherit the organizational domain policy unless an explicit sp= tag is set. You can also publish a separate DMARC record at _dmarc.subdomain.yourdomain.com to override the inherited policy for a specific subdomain.

6. My ESP sends mail on my behalf. Does that affect DMARC?

Yes. Your ESP must be authorized in your SPF record, and ideally should sign outgoing mail with DKIM using your domain (or a subdomain). Without that, messages from your ESP will fail DMARC alignment even if delivery works today. Check your ESP’s documentation for custom DKIM signing setup.

This is a staging environment