What is DMARC Record? Definition, Structure & Setup Guide

How DMARC Record Shields Your Domain and Why Every Brand Needs It

Phishing and spoofed emails have become so common that most people barely blink when they see a fake message pretending to be from a bank, delivery service, or even their own company. But behind the scenes, these attacks cause real damage, hitting deliverability, trust, and in some cases, leading to security breaches.

That’s where DMARC steps in. It’s a protocol that helps domain owners tell email providers, “Hey, only these sources are allowed to send mail on my behalf. If anything else tries, here’s what to do.” The DMARC record is a piece of instruction that makes it possible. It’s just a text record sitting in your DNS, but it plays a key role in deciding whether an email gets delivered, flagged, or blocked.

In this article, we’ll break down what a DMARC record is, how it works and why getting it right is critical for email security.

What is a DMARC Record?

DMARC record is just a DNS entry with TXT record. This record instructs the receiving server on how to handle messages that claim to come from your domain but do not pass SPF and DKIM checks. When emails are sent claiming it to be from your domain, the recipient’s mail server will check your DMARC record to see what to do if the message doesn’t pass validation: should it be delivered anyway, marked as suspicious or blocked entirely?

Here’s a basic example of what a DMARC record looks like:

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

The record has a quarantine policy, requests reports, and is applied to all mail (pct=100). It uses strict alignment on both SPF and DKIM.

This record contains multiple tags such as

v=DMARC1 denotes and sets the version,
p=none instructs the mail server to take no action but just monitor and
rua provides an email address to send reports about the DMARC.

This entire string is written like a single line in plain text and published in the DNS server of your domain. This record is specifically added in the subdomain _dmarc.yourdomain.com as a TXT record.

Anatomy of a DMARC Record

DMARC record is created in a key-value tag structure, and each key value serves a specific purpose. Some key values are mandatory, and others are optional. Together, using these key values defines how your domain will handle authentication failures and where you want your reports to be sent. Here’s a list of tags usually used:

v: This sets the DMARC version. Right now, it’s always DMARC1, and it has to be the first tag in your record.
p: The policy tag tells mail servers what to do when an email fails authentication. You can set it to none for just monitoring, quarantine to send it to spam or reject to block the email outright.
rua: This is where you specify the email address that should receive aggregate reports. These reports give you a high-level view of authentication results across different mail servers. Format for setting this is rua=mailto:dmarc-reports@yourdomain.com.
ruf: This tag lets you receive forensic or failure reports with detailed messages when something fails SPF or DKIM. It is an optional tag and should be used with caution, since not all providers support it, and it may raise privacy flags.
pct: This controls the percentage of mail that your policy should apply to. For example, pct=50 means only half of the failing messages will be affected by the policy. It’s useful when easing into stricter enforcement.
aspf: Sets the alignment mode for SPF. You can use aspf=r for relaxed or aspf=s for strict mode. Strict means the return-path domain must exactly match the “From” domain.
adkim: Same idea as aspf but for DKIM. Use adkim=s for strict alignment and adkim=r for relaxed.

When you put it all together, a full record might look like this:

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=100; aspf=s; adkim=s

This instructs recipients to quarantine failed messages and provide a daily summary report to your email address, and use strict alignment of SPF and DKIM. Every tag plays a role and getting them right means the difference between effective enforcement and accidental mail loss.

Where is a DMARC Record Published?

A DMARC record is published in your domain’s DNS, just like SPF and DKIM records. Specifically, it lives under a dedicated subdomain: _dmarc.yourdomain.com. That prefix is required and it’s how mail servers know where to look when trying to retrieve your DMARC policy. The record type should be set as TXT and the value is the DMARC policy string explained earlier.

For example, if you own domain.com, your DNS zone should include a TXT record at dmarc.domain.com that might look like this:

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

You can add this record manually in most DNS dashboards. Platforms like Cloudflare, GoDaddy, AWS Route 53, and others support it. Just be careful when entering the value. Extra spaces or tiny syntax errors can break how the policy works. If the DMARC record isn’t there, receiving mail servers won’t know what to do with failed messages. There’s no instruction to follow. This leaves your domain exposed to spoofing and phishing attacks.

How to Create or Generate a DMARC Record

There are two main ways to create a DMARC record either you can write it manually or use a generator tool to help you build one with fewer chances of making a mistake.

Manual method:

If you’re okay experimenting around with DNS records and know your way around the tags, you can actually put together a DMARC string yourself. You always start with v=DMARC1 (mandatory), then set your policy p=none, quarantine, or reject. After that, add a rua tag to start getting aggregate reports. You can also add in tags like pct, aspf, adkim, or ruf if you want more control over things.

Here’s a simple one to get going:

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

Once you’ve built your string, just publish it as a TXT record under _dmarc.yourdomain.com.

Using a DMARC generator:

Tools like MXToolbox, EasyDMARC and dmarcian provide you with a simple form where in you can choose your preferred settings and the form will generate a syntactically correct string for you. This is very helpful if you are new to DNS and don’t want to risk a typo or misconfiguration.

One important decision you need to make is choosing the right policy. If you’re just starting, use p=none to monitor how your mail is performing without affecting delivery. This helps you verify SPF and DKIM alignment before moving to stricter policies like quarantine or reject. Enforcement is critical but only when you’re ready for it.

Best Practices for Creating a DMARC Record

Like any good security control, DMARC works best when rolled out carefully and monitored closely. One of the safest starting points is to begin with p=none. This policy doesn’t block or quarantine any mail. It just monitors what’s happening behind the scenes. It lets you collect reports (rua) and see which services are sending on your behalf and whether they’re passing SPF and DKIM checks.

Always include a rua tag in your initial DMARC record. These aggregate reports sent by receiving mail servers give you visibility into who’s sending mail as your domain and how those messages are being treated. It’s the only way to validate that your authentication setup is working before enforcing anything.

Before tightening your policy to quarantine or reject, make sure both SPF and DKIM are properly aligned. That means your SPF records cover all legitimate sending services like Google Workspace, Mailchimp or your CRM, and your DKIM signatures are correctly configured and aligned with your domain. If either one is broken or misaligned, valid mail might get blocked when you move to enforcement.

Once reporting looks clean, you can gradually roll out enforcement by adjusting the pct tag. For instance, start with pct=25 and increase it over time. This phased approach helps avoid delivery issues that could disrupt business or communication.

DMARC Record vs. DMARC Policy: Are They Different?

DMARC policy and DMARC record are used interchangeably. Although they are both closely related, they are not identical. DMARC record is the actual TXT record in the DNS server that is published under _dmarc.yourdomain.com. Its a full string that has all the necessary tags such as v=DMARC1, p=, rua=, etc.

The policy, on the other hand, is just one part of that record, specifically the p tag. It tells the receiving server what to do when a message fails SPF and DKIM checks. Your policy might be ‘none‘, ‘quarantine‘, or ‘reject‘, depending on how strictly you want enforcement to be.

Final Thought

The deliverability of your emails is affected by your DMARC record. This also protects your domain from phishing and spoofing attacks. A properly configured DMARC will help your customers and employees avoid suspicious and fraudulent emails. It also reduces the chances of your email landing in spam folders. As much as DMARC seems helpful it should be noted that if your DMARC is not set properly, it can do more harm than good.

Related Articles:

What is DMARC Record? How it Protects Your Domain Against Email Threats