What's the difference between policies?

The 'none' policy means monitor but don't block — receivers send you reports but deliver mail normally. 'Quarantine' means deliver to the spam folder. 'Reject' means refuse delivery at the SMTP level. The recommended progression is to start at 'none', monitor reports for a few weeks to discover which legitimate sources are failing authentication, fix those issues, then move to quarantine, then to reject as confidence grows. Strict from day one tends to block your own mail.

Do I need SPF and DKIM first?

Yes, and they need to be working cleanly before you publish DMARC. DMARC enforces what SPF and DKIM verify — if those underlying mechanisms aren't configured correctly, legitimate mail fails authentication and your DMARC policy starts blocking it. The typical sequence is SPF first, then DKIM, then DMARC in monitoring mode for a few weeks, then DMARC in enforcement mode.

What are aggregate reports?

They're daily XML reports that receiving servers send back, showing how much mail from your domain authenticated, what failed, and which sources are sending in your name (legitimate and otherwise). The reports go to the address in the 'rua' tag of your DMARC record. They're essential for monitoring, troubleshooting, and detecting spoofing attempts. The XML is unfriendly to read manually, so most people use a service to parse and visualize the data.

What's alignment (aspf, adkim)?

Alignment controls whether the SPF or DKIM domain must match the From header exactly (strict, indicated by 's') or whether a subdomain is acceptable (relaxed, indicated by 'r'). Strict alignment is more secure because it prevents a sender from authenticating with a sister domain, but it's harder to satisfy when you have legitimate sub-organization sending. Relaxed is the default and works for most setups.

It's the percentage of failed mail that the policy applies to. With pct=100, all failures get the full treatment. With pct=50, half get the policy applied and half are treated as 'none' (monitored but not blocked). It's a tool for gradual rollout — start at pct=10 with quarantine, watch what happens, increase to 25, 50, 100 over time. Reduces the risk of accidentally blocking large volumes of legitimate mail in one shot.

How do I read DMARC reports?

Don't try to read them by hand. The raw XML format is verbose and hard to parse visually. Services like DMARC.com, Postmark, dmarcian, and EasyDMARC decode the reports, aggregate them across providers, and present the data as charts and tables a human can understand. Most have free tiers for smaller senders, which is plenty for getting started. For ongoing DMARC management this kind of tooling is essentially required.

What if I have multiple sending services?

Every legitimate sending service needs to authenticate properly via SPF and DKIM, and DMARC's aggregate reports show you which services pass, which fail, and how much volume each is sending. The reports are particularly useful here because they reveal configuration gaps you might not know about — a transactional service that someone set up two years ago and forgot, sending unauthenticated mail under your domain, surfaces immediately in the data.

DMARC Record Generator

Create valid DMARC DNS TXT records online to protect your domain from spoofing and phishing. Free step-by-step DMARC policy builder.

Email Tools Web & SEO Generators

Instant results

Domain

Domain Name

Policy Settings

Domain Policy (p=)

No action is taken on failing messages. Use this to collect reports and understand your email flow before enforcing.

Subdomain Policy (sp=)

Percentage (pct=): 100%

1%100%

Alignment Settings

DKIM Alignment (adkim=)

SPF Alignment (aspf=)

Reporting Settings

Aggregate Report Email (rua=)

Receives daily XML aggregate reports. Highly recommended for monitoring.

Forensic Report Email (ruf=)

Receives per-message failure reports. Not supported by all providers.

Reporting Interval (ri=) in seconds

Default: 86400 (24 hours). Common values: 3600 (1 hour), 43200 (12 hours), 86400 (24 hours).

Failure Reporting Options (fo=)

0 - All mechanisms fail
Generate a report if all underlying authentication mechanisms fail (default)1 - Any mechanism fails
Generate a report if any underlying authentication mechanism failsd - DKIM fails
Generate a report if DKIM signature evaluation fails, regardless of alignments - SPF fails
Generate a report if SPF evaluation fails, regardless of alignment

Monitoring Mode

Your DMARC policy is set to monitor only. No messages will be blocked or quarantined. This is the recommended starting point to collect data before enforcing stricter policies.

MonitorQuarantineReject

Generated DMARC Record

DNS Record Name (Host)

_dmarc.example.com

Record Type

TXT

TXT Record Value

v=DMARC1; p=none

Record Breakdown

v=DMARC1DMARC version

p=noneDomain policy

DNS Setup Instructions

Log in to your DNS provider or domain registrar (e.g., Cloudflare, GoDaddy, Namecheap, Route 53).
Navigate to the DNS management section for your domain.
Create a new TXT record with the following values:
- Host/Name: _dmarc.example.com
- Type: TXT
- Value: the generated record above
- TTL: 3600 (1 hour) or your provider's default
Save the record. DNS propagation typically takes a few minutes to 48 hours.
Verify your DMARC record using a DMARC lookup tool or by running: nslookup -type=txt _dmarc.example.com

Important: Before setting p=quarantine or p=reject, make sure you have:

Configured SPF records for all sending sources
Set up DKIM signing for your domain
Monitored DMARC reports with p=none first
Confirmed legitimate email sources pass authentication

Understanding DMARC Records

DMARC (Domain-based Message Authentication, Reporting & Conformance) is an email authentication protocol that builds on top of SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail). It allows domain owners to publish a policy in their DNS records that specifies how receiving mail servers should handle messages that fail authentication checks.

DMARC solves a critical problem in email security: even with SPF and DKIM in place, there was no standardized way for domain owners to tell receiving servers what to do when authentication failed, or to get feedback about messages claiming to be from their domain.

A DMARC record is published as a DNS TXT record at _dmarc.yourdomain.com and contains the policy along with optional reporting addresses and alignment settings.

How to Use DMARC Record Generator

Choose enforcement policy

Decide between p=none (monitor without blocking), p=quarantine (route to spam folder), or p=reject (refuse delivery). For a new DMARC deployment, start with 'none' so you can gather data without risking legitimate mail. Move to stricter policies only after the aggregate reports confirm your legitimate sources are all authenticating cleanly.

Configure reporting addresses

Add an 'rua=' address for aggregate reports — this is the daily summary of authentication results and you definitely want it. The 'ruf=' tag for forensic reports is optional, and on a busy domain those can flood the inbox, so leave it out unless you have specific tooling that consumes them. Use a dedicated mailbox or a DMARC analytics service rather than your personal email.

Generate DNS record

The tool produces the formatted record — name '_dmarc.yourdomain' with a value like 'v=DMARC1; p=policy; rua=mailto:reports@example.com'. Copy the value precisely; whitespace and line breaks accidentally introduced during copy-paste break the record without producing an obvious error message.

Publish and monitor

Add the TXT record in your DNS provider's control panel and wait 24 to 48 hours for propagation. Reports start showing up daily after that. Feed them into a DMARC analytics service (DMARC.com, Postmark, dmarcian, EasyDMARC) so the XML becomes readable. Use the data to spot configuration issues and tighten your policy gradually as confidence grows.

When to Use DMARC Record Generator

Email authentication policy

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the third leg of the modern email authentication stack. Where SPF and DKIM provide the verification mechanisms, DMARC is the policy layer that tells receiving servers what to do when a message fails those checks. Without it, receivers are guessing; with it, you can explicitly say 'reject anything that doesn't authenticate' and back it up with the reporting infrastructure to monitor what's happening.

Anti-spoofing protection

Without DMARC, attackers can send email pretending to be from your domain and there's no automated way to stop receivers from delivering it. DMARC plus SPF plus DKIM gives you strong protection — the spoofed messages fail authentication, and your DMARC policy tells receivers to reject or quarantine them. The tool generates records appropriate for whatever protection level you're ready to enforce.

Compliance and reputation

Since February 2024, Gmail, Yahoo, and Microsoft have all required DMARC for bulk senders, and other providers have followed. Without DMARC, your deliverability drops — sometimes dramatically — and there's no fixing it without publishing the record. The tool helps you generate a compliant record quickly so you don't lose inbox placement while you sort out the rest of your email infrastructure.

Reporting and visibility

DMARC's reporting feature is genuinely useful. Receiving mail providers send daily aggregate reports to whatever address you specify, telling you who's sending mail in your name (legitimate and otherwise), what's authenticating successfully, and where you have configuration gaps. Security teams use this to spot spoofing attempts, deliverability teams use it to debug authentication issues, and brand-protection teams use it to surface impersonation attempts.

DMARC Record Generator Examples

Strict policy

Input

Domain: example.com, Policy: reject, Reports to: dmarc@example.com

Output

_dmarc.example.com TXT v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com; aspf=s; adkim=s

Full strict enforcement — receivers should reject any mail that fails authentication, with strict alignment for both SPF and DKIM. Strongest protection available, but only safe to deploy after you've confirmed every legitimate sending source is authenticating properly. Most domains spend weeks or months in less-strict modes before reaching this point.

Monitor-only (initial)

Input

Policy: none, just monitor

Output

_dmarc.example.com TXT v=DMARC1; p=none; rua=mailto:dmarc@example.com

The recommended starting point. The 'none' policy means receivers don't block anything, but they do still send you reports. You use those reports to discover which legitimate sources are failing authentication so you can fix them before tightening the policy. Skipping this phase is the most common DMARC mistake.

Quarantine policy

Input

Policy: quarantine, 100% application

Output

_dmarc.example.com TXT v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@example.com

The middle ground between monitoring and full rejection. Unauthenticated mail goes to the spam folder rather than getting rejected outright, so the recipient still has the option to find it. The 'pct=100' applies the policy to all mail; you can dial it down to 25 or 50 during a gradual rollout if you want to limit blast radius while you're still finding configuration issues.

Tips & Best Practices for DMARC Record Generator

1.Start with p=none and stay there long enough to learn something. Aggregate reports take a few weeks to surface the full picture of who's sending in your name. Moving to enforcement before you've found and fixed every legitimate-source issue means blocking your own mail.
2.Always include the rua tag for aggregate reports — that's how you get the daily summary of authentication results. Without it, you're flying blind. The ruf tag for forensic reports is optional and can flood your inbox, so add it carefully.
3.Get SPF and DKIM working cleanly before publishing DMARC. DMARC enforces what SPF and DKIM verify; if those underlying checks aren't configured properly, legitimate mail starts failing the moment your DMARC policy moves past 'none'.
4.Read the reports regularly, not just when something goes wrong. Aggregate reports surface authentication results, spoofing attempts targeting your domain, and configuration drift in legitimate sending services. They're a security signal as much as an operational one.
5.Use a DMARC monitoring service rather than trying to read raw XML reports. DMARC.com, Postmark, dmarcian, and EasyDMARC all decode the XML and present it as something a human can actually read. Free tiers exist for low-volume domains.
6.Whenever you add a new sending service, walk through the full SPF/DKIM/DMARC checklist for it. Missed a step? Mail from that service starts failing authentication and getting blocked or spam-foldered, which is exactly the kind of subtle deliverability hit that takes weeks to diagnose.

Frequently Asked Questions

Domain-based Message Authentication, Reporting, and Conformance. It's the policy layer that tells receiving mail servers what to do when SPF or DKIM checks fail. Without DMARC, receivers have to guess — they might deliver spoofed messages, mark them as spam, or reject them depending on their own heuristics. With DMARC, you publish an explicit policy (none, quarantine, or reject) and receivers know exactly how to handle authentication failures from your domain.

DMARC Record Generator

Domain

Policy Settings

Alignment Settings

Reporting Settings

Generated DMARC Record

DNS Setup Instructions

Understanding DMARC Records

How to Use DMARC Record Generator

Choose enforcement policy

Configure reporting addresses

Generate DNS record

Publish and monitor

When to Use DMARC Record Generator

Email authentication policy

Anti-spoofing protection

Compliance and reputation

Reporting and visibility

DMARC Record Generator Examples

Strict policy

Monitor-only (initial)

Quarantine policy

Tips & Best Practices for DMARC Record Generator

Frequently Asked Questions

Related Tools

DKIM Record Generator

SPF Record Generator

Email Header Analyzer

MX Record Lookup

Email Spam Checker

Email Subject Line Tester