How to Generate a DMARC Policy Record

Generating a DMARC policy record is the single most effective way to secure your domain against email spoofing, executive impersonation, and phishing attacks. By publishing a specific DNS TXT record, you gain full visibility into who is sending email on your behalf and enforce strict delivery rules for unauthorized senders. This guide walks you through the exact mechanics of DMARC, how to construct a valid record, and how to deploy it safely.

Implementing DMARC requires an existing understanding of SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail). DMARC acts as the overarching governance framework, relying on SPF and DKIM authentication results to decide whether an incoming email should be delivered, quarantined, or rejected. Without a proper DMARC policy, malicious actors can easily forge your domain name in the "From" header, damaging your brand reputation and degrading email deliverability.

Understanding the Core Components of a DMARC Record

A DMARC record is a standard DNS TXT record placed at a specific subdomain (_dmarc.yourdomain.com). It consists of a series of "tags" separated by semicolons. Each tag defines a specific instruction for receiving mail servers.

Required and Optional Tags

• v=DMARC1: The protocol version. This must always be the first tag and is strictly required.
• p=none|quarantine|reject: The policy applied to emails that fail DMARC authentication. "None" is purely for monitoring, "quarantine" sends failing emails to the spam folder, and "reject" blocks them entirely.
• rua=mailto:...: The URI where aggregate reports (XML format containing traffic metrics) are sent.
• ruf=mailto:...: The URI where forensic reports (individual failure details) are sent. Note that many mail providers have deprecated or limited these due to privacy concerns.
• pct=100: The percentage of messages to which the policy is applied. Useful for gradually rolling out quarantine or reject policies.
• aspf=r|s: Alignment mode for SPF. "r" means relaxed (subdomains allowed), while "s" means strict (exact match required).
• adkim=r|s: Alignment mode for DKIM. Similar to SPF, relaxed or strict.

Step-by-Step Guide to Generating Your DMARC Record

Creating a secure DMARC record manually can lead to syntax errors. To streamline the process, you can use the DMARC Generator to build and validate your syntax instantly. Whether you use an automated tool or build it by hand, follow these structured steps to ensure your policy is robust.

Step 1: Audit Your Current Email Infrastructure

Before you publish any DMARC policy, you must identify every legitimate service that sends email on behalf of your domain. This includes your primary email provider (such as Google Workspace or Microsoft 365), marketing automation platforms (like Mailchimp or HubSpot), customer support tools (like Zendesk), and transactional email services (like SendGrid or AWS SES).

Ensure that all of these services are properly configured with their respective SPF mechanisms and DKIM signing keys. If you enforce DMARC before fixing your underlying SPF and DKIM setups, your own legitimate emails will fail authentication.

Step 2: Start with a Monitoring Policy (p=none)

Never start your DMARC journey with a strict policy like p=reject. Always begin with a monitoring policy. This allows you to collect data without impacting email delivery.

Your initial record syntax for example.com will look like this:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; sp=none;

In this example:

• v=DMARC1 establishes the protocol.
• p=none tells receiving servers to take no action on failing emails, only to send reports.
• rua=mailto:dmarc-reports@example.com is the inbox where daily XML reports will arrive.
• sp=none applies the monitoring policy to all subdomains.

Step 3: Publish the DNS Record

Log in to your DNS hosting provider (such as Cloudflare, Route 53, GoDaddy, or Namecheap). Create a new TXT record with the following parameters:

• Type: TXT
• Name / Host: _dmarc (or _dmarc.example.com depending on your provider's interface)
• Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com;
• TTL: 3600 seconds (or default)

Save the record and wait for DNS propagation, which typically takes anywhere from a few minutes to a few hours.

Step 4: Analyze Your DMARC Reports

Once your monitoring record is live, receiving mail servers will send daily XML reports to your specified rua email address. These reports contain detailed information about your IP traffic, SPF alignment, DKIM alignment, and pass/fail statistics.

Because raw XML files are difficult to read, you should use a log parser or email intelligence tool to visualize the data. Look for legitimate services that are failing authentication. Fix their SPF or DKIM configurations immediately.

Step 5: Progress to Quarantine, Then Reject

After monitoring your traffic for at least two to four weeks—and confirming that all legitimate mail sources are passing authentication—you can upgrade your policy.

First, move to quarantine:

v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@example.com;

Notice the pct=10 tag. This applies the quarantine policy to only 10% of failing emails. This is a safe way to test the waters. Gradually increase the percentage over a few weeks (pct=50, then pct=100).

Once you are confident that no legitimate mail is being sent to the spam folder, update your policy to full rejection:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com;

Pre-Deployment Checklist

Before you push your DMARC policy live into a strict enforcement mode, run through this concise checklist to avoid self-inflicted email outages:

• SPF record is published and correctly lists all sending IP addresses and third-party vendors.
• DKIM is enabled and actively signing outgoing emails for your domain and third-party senders.
• A dedicated email address or mailbox (dmarc-reports@example.com) is set up to receive high-volume XML reports.
• You have run your domain through a DMARC generator and syntax validator.
• You have monitored p=none reports for a minimum of 14 days to catch infrequent or quarterly newsletter senders.
• You plan to step up from p=none to p=quarantine before finally settling on p=reject.