DMARC Records: Simple Step-by-Step Guide

If your emails sometimes land in spam or you worry that attackers could fake your domain, you will eventually hear the word DMARC. At first it sounds technical and scary, but the main idea is simple: DMARC is a policy that tells receiving mail servers how to treat messages that claim to come from your domain.

DMARC does not work alone. It builds on two things you might already know: SPF and DKIM. Once those are in place, a DMARC record lets you say, “If a message fails SPF and DKIM checks, here is what I want you to do with it.”

What Is DMARC in Simple Terms?

DMARC stands for Domain-based Message Authentication, Reporting and Conformance. Yes, it is a long name. In practical language, DMARC lets you:

Tell receivers which authentication checks to apply (SPF and DKIM).
Define what should happen when checks fail (do nothing, quarantine, or reject).
Receive reports about how your domain is being used in email.

DMARC rules live in a special TXT record in DNS, usually at _dmarc.yourdomain.com. Mail servers look up this record when they receive a message that claims to be from your domain.

How DMARC Fits with SPF and DKIM

Before DMARC can do its job, you normally need:

A working SPF record describing which servers may send mail for your domain.
DKIM set up so your emails carry valid signatures.

DMARC checks whether at least one of these passes in a way that aligns with the visible “From” domain in the email.

In simplified form, a receiving server might ask:

Does SPF pass, and is the sending domain aligned with the From address?
Does DKIM pass, and is the signing domain aligned with the From address?
What does the DMARC policy say to do if neither is aligned?

If SPF or DKIM passes and is aligned, DMARC considers the message authenticated. If not, DMARC can tell the receiver to quarantine or reject that message, instead of just guessing.

What a DMARC Record Looks Like

A DMARC record is a structured text string with several key-value pairs. The simplest form might look like this:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

Let’s break down the important tags you will see:

v=DMARC1 – version, always required and always this value.
p= – policy for the domain:
- none – monitor only, do not change delivery.
- quarantine – treat failing mail as suspicious (often goes to spam).
- reject – reject failing mail outright.
rua= – address for aggregate reports (summary XML reports).
ruf= – address for forensic reports (per-message details, used less often).
pct= – percentage of mail to which the policy applies (for gradual rollout).
sp= – policy for subdomains, if different from the main domain.

You do not need every tag from day one, but it is important to understand what p= and rua= do at minimum.

The Three Main DMARC Policies: none, quarantine, reject

The policy (p=) is the heart of your DMARC record. It tells receivers how strict they should be when SPF/DKIM fail and are not aligned.

p=none – Monitor Only

This is the safest starting point. With p=none, you ask for reports but do not request any change to mail delivery.

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

Use this mode to:

See who is sending mail using your domain.
Check whether SPF and DKIM are configured correctly.
Understand potential problems before you start blocking anything.

p=quarantine – Mark Failing Mail as Suspicious

With p=quarantine, you tell receivers that messages failing DMARC should be treated with caution — usually placed in the spam or junk folder.

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

This is a good intermediate step when you are confident in your setup but still want a safety net. Many organizations move from none to quarantine before going all the way to reject.

p=reject – Block Failing Mail

With p=reject, you tell receivers they are allowed to reject messages that fail DMARC. Those emails may never reach the inbox or spam folder at all.

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

Reject is the strongest protection against spoofed mail, but it must be used carefully. If you forget to authorize one of your own legitimate sending services, their messages may also be rejected.

Step-by-Step: Setting Up a Basic DMARC Record

Here is a simple path to getting DMARC running in a safe way.

Make sure SPF and DKIM are already set up.
Your domain should have a valid SPF TXT record and DKIM records created by your email provider(s). If these are missing or broken, fix them first.
Choose an email address for reports.
Create a mailbox such as [email protected] or use a reporting service address. DMARC reports can be noisy, so some people use special inboxes or external tools.
Create a monitoring DMARC record (p=none).
In your DNS panel, add a TXT record:
```
Host / Name: _dmarc
Type: TXT
Value: "v=DMARC1; p=none; rua=mailto:[email protected]"
```
This starts collecting data without affecting delivery.
Wait and review reports.
Over the next days or weeks, you will receive XML reports from large providers. Use an online DMARC report viewer or service to make sense of them.
Adjust SPF/DKIM based on what you see.
If reports show legitimate mail failing, update SPF or DKIM to include those senders.
Increase strictness gradually.
When you are comfortable, you can change the policy to quarantine, then eventually to reject, optionally using pct= to apply the policy to only part of your traffic at first.

Using pct to Roll Out DMARC Slowly

The pct tag lets you apply your policy to only a percentage of messages while you test the impact.

Example: Quarantine 25% of failing messages:

v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]

This way, you can see how often legitimate email might be affected before moving to 100%. Once you are comfortable, you can increase pct to 50, 75, and finally 100.

DMARC for Subdomains (sp= Tag)

By default, your DMARC policy applies to the main domain and, depending on the receiver, often extends to subdomains. If you want a different policy specifically for subdomains, you can use the sp tag.

Example: strict reject for the main domain, more relaxed quarantine for subdomains:

v=DMARC1; p=reject; sp=quarantine; rua=mailto:[email protected]

This can be useful if you have many subdomains used by internal systems or separate services that you want to treat more gently while you clean them up.

What Are DMARC Aggregate Reports (rua)?

The rua tag tells receivers where to send aggregate reports. These are daily or periodic XML files that summarize:

Which IP addresses sent mail using your domain.
Whether SPF and DKIM passed or failed.
How many messages were seen for each combination.

Example with two report addresses:

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

These reports are not meant to be read directly in a normal email client; they are machine-readable. Many admins use external tools or services to visualize and analyze them.

Common DMARC Mistakes

A few recurring issues show up when people first deploy DMARC:

Setting p=reject too early. If SPF/DKIM for some legitimate senders are not correctly aligned, their mail may be rejected along with the bad traffic.
No reports (missing rua). Without rua, you lose the main benefit of visibility. You will not know who is sending what.
Using DMARC without SPF or DKIM. DMARC has nothing solid to check if neither SPF nor DKIM is configured and aligned properly.
Ignoring reports. DMARC is not a “set and forget forever” tool. It is worth reviewing reports regularly, especially when you add new services or change providers.

Key Takeaways About DMARC Records

DMARC defines how receivers should treat emails that claim your domain but fail SPF/DKIM checks.
The record lives at _dmarc.yourdomain.com as a TXT record.
You can start safely with p=none to monitor and collect reports.
Policies quarantine and reject let you actively protect users from spoofed mail.
Reports (via rua) are crucial for understanding who is using and abusing your domain.

DMARC FAQ for Domain Owners

What is a DMARC record in DNS?

A DMARC record is a TXT entry at _dmarc.yourdomain.com that tells receiving mail servers how to handle emails that claim to be from your domain. It specifies your policy (none, quarantine, or reject) and where to send reports about authentication results.

Do I need SPF and DKIM before setting up DMARC?

Yes, you should have both SPF and DKIM configured first. DMARC relies on the results of SPF and DKIM checks. Without them, DMARC cannot reliably distinguish between legitimate and spoofed messages from your domain.

Is it safe to start with p=reject right away?

It is usually safer to start with p=none to gather data, then move to quarantine, and finally to reject. Jumping straight to reject without testing can cause legitimate emails to be blocked if some senders are not configured correctly.

What kind of reports will I get from DMARC?

You will receive aggregate XML reports that show which IPs sent mail using your domain, which authentication checks passed or failed, and how many messages were involved. They are designed for automated processing, so most people use tools or services to read and analyze them.

Does DMARC improve my inbox placement?

A properly configured DMARC policy, combined with good SPF and DKIM, is a strong positive signal for mailbox providers. It does not guarantee perfect inbox placement, but it helps build a trustworthy reputation and protects users from fake messages using your domain.

DMARC Records: Step-by-Step Explanation for Non-Technical Domain Owners