Back to Tools

DMARC Record Generator

Create a DMARC policy record to protect your domain from email spoofing and phishing. Configure policy, reporting, alignment, and gradual rollout with our free generator.

DMARC Record Generator

Create a DMARC policy to protect your domain from email spoofing

Monitor only - no action taken on failing emails. Best for initial setup.

Policy for emails from subdomains. Leave empty to inherit from main policy.

100%

All failing emails will have the policy applied.

Receive daily summary reports of DMARC results

Receive detailed reports for individual failures

Like this tool? Try Sequenzy for free

AI-powered email marketing with Stripe integration, automations, and built-in analytics.

v=DMARC1; p=none

Add this as a TXT record with host _dmarc in your DNS settings

Add reporting emails

Without aggregate reports (rua), you won't know who is sending email as your domain. Add a reporting email to monitor your DMARC results.

Implementation path

  1. Start with p=none and add reporting
  2. Monitor reports for 2-4 weeks to identify all senders
  3. Ensure all legitimate senders pass SPF and DKIM
  4. Move to p=quarantine with pct=10
  5. Gradually increase percentage to 100%
  6. Finally move to p=reject for full protection

About this tool

Around 3.4 billion phishing emails are sent every single day, and without DMARC, your domain could be one of the ones being spoofed. DMARC builds on SPF and DKIM to give you explicit control over what happens when someone sends an email that fails authentication checks for your domain. It's the policy layer that turns passive authentication into active protection.

How DMARC Records Work

A DMARC record is a DNS TXT record published at _dmarc.yourdomain.com. Here's what a full record looks like: v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; ruf=mailto:forensic@yourdomain.com; adkim=s; aspf=s; pct=100. The key fields are: p (policy: none, quarantine, or reject), rua (where aggregate reports go), ruf (where forensic reports go), adkim/aspf (alignment mode: strict or relaxed), and pct (percentage of emails the policy applies to). This generator walks you through each option so you don't have to memorize the syntax.

The p=none to p=reject Progression

Jumping straight to p=reject is the fastest way to break your own email. The correct progression is: start with p=none and enable reporting so you can see every service sending email as your domain. After 2-4 weeks of reviewing aggregate reports, move to p=quarantine; pct=10 to quarantine 10% of failing emails. Gradually increase pct to 100, then switch to p=reject with the same gradual rollout. The entire process typically takes 6-12 weeks for a domain with multiple sending services. Rushing it means legitimate emails from your CRM, helpdesk, or transactional system get quarantined or rejected.

Common Mistakes That Break Email

The biggest mistake is not including all your sending services in SPF/DKIM before tightening your DMARC policy. If your marketing team uses Mailchimp, support uses Zendesk, and engineering sends transactional emails through SendGrid, all three need proper authentication before you move past p=none. Another common error is ignoring the aggregate reports—they're the whole point of the monitoring phase. Use a service like Postmark's DMARC monitoring or dmarcian to parse the XML into readable dashboards.

Fit It Into Your Authentication Workflow

DMARC doesn't work in isolation. First, generate your SPF record covering all sending services, then set up DKIM signing for each service. Once both are passing, use this generator to create your DMARC record. Verify everything is live with the DMARC checker and DNS propagation checker. Run a full deliverability audit quarterly to make sure nothing's drifted.

Frequently Asked Questions