How to Create a DMARC Record

If you send email from your own domain, you need a DMARC record. Without one, mailbox providers like Gmail and Yahoo have no way to know what to do when someone spoofs your address. Creating a DMARC record is straightforward once you understand the structure, and it takes less than ten minutes to add one to your DNS.

This guide walks you through every part of a DMARC record, shows you real examples for different situations, and helps you avoid the mistakes that trip up most people.

What a DMARC Record Looks Like

A DMARC record is a TXT record that you add to your domain's DNS at a specific subdomain: _dmarc.yourdomain.com. When a receiving mail server gets a message claiming to be from your domain, it looks up this record to find out how you want authentication failures handled.

Here is a basic DMARC record:

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

Every DMARC record is a single line of text made up of tags separated by semicolons. Each tag is a key-value pair. Some tags are required, and others are optional. Let's break them all down.

Required and Optional DMARC Tags

Required Tags

v=DMARC1 — This is the version tag and it must be the very first tag in your record. It tells the receiving server that this TXT record is a DMARC policy. The value is always DMARC1. There is no DMARC2.

p — The policy tag tells receiving servers what to do when an email fails both SPF and DKIM alignment. There are three options:

• p=none — Take no action. Just send reports so you can monitor what is happening.
• p=quarantine — Send failing emails to the spam folder.
• p=reject — Block failing emails entirely. They never reach the inbox or spam folder.

If you are setting up DMARC for the first time, start with p=none. This lets you collect data without affecting your email delivery. You can read more about choosing the right level in our DMARC policy levels guide, or see a direct quarantine vs reject comparison if you are ready to enforce.

Optional Tags (But Important)

rua — The aggregate report URI. This is where receiving servers send daily XML reports about emails using your domain. Set it to a mailto address: rua=mailto:dmarc-reports@yourdomain.com. Without this tag, you get no visibility into who is sending email as your domain.

ruf — The forensic report URI. This sends detailed failure reports for individual messages. Not all providers send forensic reports, and they can contain message content, so some organizations skip this tag. Format is the same: ruf=mailto:dmarc-forensics@yourdomain.com.

pct — The percentage tag controls what portion of failing messages the policy applies to. The default is pct=100, meaning the policy applies to all failing messages. During a gradual rollout, you might set pct=10 to apply the policy to only ten percent of failures while monitoring the results.

sp — The subdomain policy. This sets a separate policy for subdomains like mail.yourdomain.com or app.yourdomain.com. If you do not include this tag, subdomains inherit the main p policy. You might use sp=reject on subdomains you never send mail from, even while your main domain is still at p=none.

adkim and aspf — These control alignment mode for DKIM and SPF checks respectively. The values are r (relaxed, the default) or s (strict). Relaxed alignment allows subdomains to pass. Strict requires an exact domain match. Most organizations leave these at the default relaxed setting. If you are integrating DMARC into a CI/CD pipeline or automating DNS updates, our guide to DMARC for developers covers implementation patterns for engineering teams.

fo — Failure reporting options. Controls when forensic reports are generated. Common values are fo=0 (report when both SPF and DKIM fail, the default) and fo=1 (report when either SPF or DKIM fails). Setting fo=1 gives you more data.

Example DMARC Records for Different Scenarios

Starting Out — Monitoring Only

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1;

This collects reports without affecting delivery. Use this for at least two to four weeks before tightening your policy.

Moving to Enforcement — Gradual Quarantine

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc-forensic@yourdomain.com; fo=1;

This quarantines 25 percent of failing messages. Raise the percentage over time as you confirm legitimate senders are passing authentication.

Full Protection — Reject with Subdomain Policy

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@yourdomain.com; adkim=r; aspf=r;

This is the end goal for most domains. All failing messages are rejected for both the main domain and subdomains. You should only reach this point after confirming all your legitimate email sources pass SPF or DKIM.

Parked or Unused Domain

v=DMARC1; p=reject; sp=reject;

If you own a domain but never send email from it, set it to reject immediately. There is no legitimate mail to worry about breaking. You can skip the reporting tags since there is nothing to monitor.

Common Mistakes to Avoid

Skipping p=none and going straight to p=reject. This is the most common mistake. If you have a newsletter tool, CRM, or transactional email service that is not properly authenticated with SPF or DKIM, their messages will be blocked. Always start with monitoring.

Forgetting the rua tag. A DMARC record without reporting is like a security camera with no monitor. You will not know what is happening until something breaks. Always include at least the rua tag.

Using the wrong DNS host name. Your DMARC record must be a TXT record at _dmarc.yourdomain.com, not at the root domain and not at dmarc.yourdomain.com (without the underscore). This is the single most frequent DNS mistake.

Adding multiple DMARC records. You should have exactly one DMARC TXT record on _dmarc.yourdomain.com. If you have two, receiving servers may ignore both or pick one unpredictably.

Putting spaces inside tag values. Tags should be separated by semicolons with optional spaces between them, but do not put spaces inside values. Write p=none, not p= none.

Adding Your DMARC Record to DNS

The process varies by DNS provider, but the steps are the same everywhere:

What Happens After You Add Your Record

Once your DMARC record is live, receiving servers will start honoring your policy and sending you aggregate reports. If you set p=none, nothing changes about your email delivery — you just start getting data.

Those XML reports are dense and hard to read manually. Most people use a DMARC report analyzer to parse them. The reports will show you every IP address sending email as your domain, whether those messages passed or failed SPF and DKIM, and how many messages were sent.

Review your reports for two to four weeks. Look for legitimate services that are failing authentication. Fix those by adding the senders to your SPF record or configuring DKIM signing. Once all your legitimate mail is passing, move to p=quarantine and eventually p=reject. You can follow our DMARC setup guide for a detailed walkthrough of the full process.

Monitor Your New DMARC Record

You've created your DMARC record — now make sure it keeps working. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.