Free DMARC generator: create your record in 30 seconds

DMARC records look simple until you try to write one.

Is it p=reject or p=rejected? Does the semicolon go before or after the tag? What’s the difference between rua and ruf?

One wrong character and the entire record is invalid. Receiving servers ignore it. Your domain stays unprotected.

That’s why we built a free DMARC generator that handles the syntax for you. Pick your options, click generate, copy the result.

What is a DMARC record?

A DMARC record is a TXT record in your domain’s DNS that tells email receivers how to handle messages that fail authentication. It does three things: it defines what policy receivers should apply to failed messages, it tells receivers where to send authentication reports, and it sets how strict domain matching should be.

Here’s what a complete DMARC record looks like:

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

Each part has a specific meaning:

Tag	Meaning	Example
v=DMARC1	Version (required, must be first)	Always DMARC1
p=	Policy for the domain	none, quarantine, reject
rua=	Aggregate report address	mailto:[email protected]
ruf=	Forensic report address	mailto:[email protected]
adkim=	DKIM alignment mode	r (relaxed) or s (strict)
aspf=	SPF alignment mode	r (relaxed) or s (strict)
pct=	Percentage of messages to apply policy	1 to 100
sp=	Subdomain policy	none, quarantine, reject

Our generator builds this string for you with correct syntax and valid values.

How to use the DMARC generator

Creating your record takes four steps.

Step 1: open the generator

Go to dmarctrust.com/dmarc-generator-dns. No signup required.

Step 2: choose your policy

The most important decision is your DMARC policy. You have three options.

With p=none (monitoring only), receivers check authentication but don’t take action on failures. Failed emails still get delivered. You receive reports about what passed and failed. Choose this if you’re setting up DMARC for the first time, you’re not sure which services send email as your domain, or you want to audit before enforcing.

With p=quarantine (spam folder), receivers put failed emails in the recipient’s spam or junk folder. The email arrives, but not in the inbox. Choose this if you’ve monitored with p=none and fixed alignment issues, you want protection but aren’t ready to block entirely, or you’re testing enforcement on a subset of traffic.

With p=reject (block), receivers reject failed emails entirely. They never reach the recipient. This is maximum protection against spoofing. Choose this if you’ve tested with p=quarantine and seen no legitimate failures, you’re confident all your senders are properly authenticated, or you want to fully protect your domain from spoofing.

Start with p=none. Monitor for 2-4 weeks, fix any issues, then gradually move to p=quarantine and p=reject. Our enforcement playbook details this process.

Step 3: add reporting addresses

DMARC reports are how you see what’s happening. Without them, you’re flying blind.

Aggregate reports (rua) are daily summaries from receivers. They show which IP addresses sent email as your domain, how many messages passed or failed SPF and DKIM, and what policy was applied. These are essential for monitoring, so add an address in the rua field.

Forensic reports (ruf) are individual failure reports with message details. They’re more detailed, but not all receivers send them (Gmail doesn’t), they can contain sensitive information, and they generate high volume on busy domains. These are optional. Skip them initially if you’re unsure.

Where should reports go? You have two options. You can use your own mailbox, where reports arrive as email attachments in XML format. You’ll need to parse them yourself. In practice, this means they pile up unread and you have zero visibility. Or you can use DMARCTrust, where reports flow to our dashboard and get automatically parsed, visualized, and turned into something you can act on. You see who’s sending as your domain, what’s passing, what’s failing.

The second option is the only one that works. When you add your domain to DMARCTrust, you get a unique reporting address. Use that address in the rua field.

Step 4: configure advanced options

For most users, the defaults are fine. But here’s what the advanced options do.

Alignment mode (adkim, aspf) controls how strict domain matching is. In relaxed mode (r), subdomains can authenticate for the parent domain, so mail.example.com can pass DKIM for example.com. In strict mode (s), exact domain match is required, so mail.example.com cannot authenticate for example.com. Use relaxed (the default). Strict mode causes problems with legitimate email flows.

The percentage (pct) setting controls what portion of messages your policy applies to. If pct=10 and p=reject, only 10% of failing messages get rejected. The other 90% are treated as p=none (monitor only). This is useful for gradual rollout: start at pct=10 when moving from p=none to p=quarantine, then increase to pct=25, then pct=50, then pct=100. Monitor for problems at each stage.

The subdomain policy (sp) lets you set a different policy for subdomains. By default, your DMARC policy applies to all subdomains. For example, p=reject; sp=quarantine rejects failures on the main domain but only quarantines failures on subdomains. Most users don’t need this. Leave it unset unless you have specific subdomain requirements.

After generating: add the record to DNS

Once you click generate, you’ll see your complete DMARC record. It looks something like:

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

Now you need to add this to your DNS as a TXT record.

Where to add it

The record goes at _dmarc.yourdomain.com. In your DNS provider’s interface:

Field	Value
Type	TXT
Name / Host	_dmarc
Value	Your generated record
TTL	3600 (or default)

Note: Most DNS providers automatically append your domain to the name. So you enter _dmarc, and it becomes _dmarc.yourdomain.com.

Provider-specific guides

Different DNS providers have different interfaces:

• GoDaddy: How to add DMARC in GoDaddy
• Cloudflare: DNS → Add record → TXT → Name: _dmarc
• Namecheap: Advanced DNS → Add new record → TXT
• Google Domains: DNS → Custom records → Add
• AWS Route 53: Hosted zones → Create record → TXT

The process is similar everywhere: create a TXT record, set the name to _dmarc, paste your generated value.

Verify it works

After adding the record, wait 5-15 minutes for DNS propagation (sometimes up to 48 hours, but usually faster).

Then verify with our free DMARC checker:

1. Enter your domain
2. Look for the DMARC section
3. Confirm your record appears with correct values

If it’s not showing up, double-check the name is exactly _dmarc (with underscore), verify there’s only one DMARC record (not duplicates), wait longer for propagation, and check for typos in the value.

Common mistakes when creating DMARC records

The record name must be _dmarc with an underscore. Not dmarc, not _DMARC, not @._dmarc.

Every DMARC record must start with v=DMARC1;. Without this, receivers don’t recognize it as DMARC.

The policy must be exactly none, quarantine, or reject. Not rejected, not block, not monitor.

Reporting addresses need the mailto: prefix. Correct: rua=mailto:[email protected]. Wrong: [email protected].

You can only have one DMARC record per domain. If you already have one, edit it. Don’t add a second.

Our generator handles all these automatically. You just pick options; we handle the syntax.

Understanding DMARC policies in practice

Let’s see how each policy affects real-world email.

Scenario: legitimate email from your marketing platform

Your company sends newsletters through Mailchimp. The emails are from [email protected], but they’re sent through Mailchimp’s servers.

If SPF and DKIM are configured correctly, SPF passes (Mailchimp’s IPs are in your SPF record), DKIM passes (you’ve set up custom DKIM in Mailchimp), DMARC passes regardless of policy, and the email lands in inbox. See our article on ESP configuration and alignment for setup details.

If DKIM isn’t configured, SPF might pass (if you added Mailchimp to SPF), DKIM fails (no signature or wrong domain), and the DMARC result depends on alignment. With p=reject, the email might be blocked.

This is why monitoring (p=none) matters. You discover these issues before enforcement breaks things. Your sender inventory often reveals surprises.

Scenario: phishing attack spoofing your domain

An attacker sends fake invoices pretending to be from [email protected]. They’re not using your mail servers.

With p=none, SPF fails (attacker’s IP isn’t authorized), DKIM fails (no valid signature), DMARC fails but the policy is “none”, and the email gets delivered anyway (you get a report about it).

With p=reject, the same failures occur, but the DMARC policy says reject. The email gets blocked before reaching the recipient. Your domain is protected.

This is why enforcement matters. Monitoring tells you about attacks. Enforcement stops them.

The path from generator to protection

Generating a record is the beginning, not the end.

Week 1: create and deploy

Generate your DMARC record with p=none. Include a reporting address (ideally DMARCTrust). Add the record to your DNS and verify with our checker.

Weeks 2-4: monitor and fix

Wait for reports to arrive (24-48 hours after deployment). Review who’s sending as your domain. Identify legitimate senders that fail authentication. Fix their SPF and DKIM configuration.

Month 2: start enforcing

Change policy to p=quarantine; pct=10. Monitor for complaints or delivery issues. Gradually increase pct to 100.

Month 3+: full protection

Move to p=reject. Continue monitoring for new senders. Maintain your SPF record as services change.

Why you need monitoring

A DMARC record without monitoring is like a smoke detector without batteries. It exists, but it won’t help you.

With p=none, you get no protection, only reports. Those reports tell you every IP address sending email as your domain, which ones pass or fail authentication, and how receivers handled the messages.

But DMARC reports are XML files. They look like this:

<record>
  <row>
    <source_ip>203.0.113.1</source_ip>
    <count>1547</count>
    <policy_evaluated>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
</record>

Multiply that by dozens of reports daily from every major email provider. Gmail, Microsoft, Yahoo, Apple, corporate mail servers.

You’re not going to parse that manually. Nobody does.

DMARCTrust parses reports automatically. It aggregates data from all sources, identifies sending services by IP and hostname, shows pass/fail rates visually, and alerts you when things break.

The generator creates your record. Monitoring shows you what happens after.

Generate your DMARC record now

Here’s the right way to do this:

1. Sign up for DMARCTrust (free tier available)
2. Add your domain in the dashboard
3. Copy your unique reporting address
4. Go to our DMARC generator and paste that address in the rua field
5. Generate your record and add it to DNS

Why sign up first? Because a DMARC record without monitoring is useless. You’ll create a record, add it to DNS, and then nothing happens. Reports pile up in XML files nobody reads. You have no visibility. You can’t safely move to enforcement.

When you sign up for DMARCTrust first, your reports flow into our dashboard from day one. You see who’s sending as your domain. You identify what needs fixing. You have a clear path to p=reject.

Not sure if you already have DMARC? Check your domain first. If you’re starting fresh, start with DMARCTrust.