DMARC tags: The only 3 tags you really need (rua, p, and v)

A DMARC record is made up of tags (sometimes called DMARC parameters or DMARC flags) that tell receiving mail servers how to handle email from your domain. There are eleven tags defined in the DMARC standard.

Fortunately, you only need three of them to have a fully functional, properly configured DMARC record. The other eight are optional, and most organizations never use them.

This guide covers the three required tags, what each one does, and a quick reference on the optional ones in case you ever need them.

What are DMARC tags?

DMARC tags are the individual components within a DMARC record. Some are mandatory, while others are optional. Each tag defines a certain aspect of DMARC, such as how to handle email that isn’t authenticated or where to send DMARC aggregate reports.

The three tags every DMARC record needs are v (version), p (policy), and rua (aggregate reporting address). Without all three, your DMARC record either won’t be recognized or won’t give you the visibility you need to manage it safely.

A complete, working DMARC record looks like this:

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

That's it. Three tags. Everything else is optional.

Components of a DMARC TXT record

1. v – version tag

First, every DMARC TXT record needs to begin with the mandatory v or version tag and the corresponding value of “DMARC1.” It’s the presence of this tag that lets receivers know that this DNS TXT record defines a DMARC policy and should be parsed appropriately.

2. p – policy tag

The second tag in a valid DMARC record must be the “p” or policy tag. The “p” tag allows the sending domain to define how a receiver should treat messages purporting to be from this domain (and its subdomains) that fail authentication. It can take one of three values:

• p=none: The sending domain is in test mode. An email that fails authentication will be reported, but no additional action will be taken. This is a good place to start, but domains at p=none get very few of the benefits of DMARC.
• p=quarantine: Receivers are asked to quarantine messages that fail authentication. Typically, the message is marked as spam.
• p=reject: Receivers are asked not to deliver failing messages to the recipient at all. Some receivers honor this request, while other receivers just mark failing messages as spam.

3. rua

The only other value that generally needs to be included in every DMARC record is the rua tag. The rua tag contains a comma-separated list of mail-to URLs that define where receivers should send aggregate reports.

Aggregate reports are the method receivers use to give feedback to domain owners on the messages they’re seeing that claim to be from the domain. These reports are zipped XML documents containing aggregated information on the source IP addresses and authentication status for all the messages in a given period (typically a day).

When properly analyzed by a service like Valimail, these reports can provide the domain owner with a comprehensive view of which servers and third-party services are sending messages on the domain owner’s behalf, as well as any potential abuse of the domain by phishers.

Without aggregate reports, you’re flying blind. Moving to a p=quarantine or p=reject policy becomes very unsafe because legitimate email may be unknowingly blocked. While including a rua tag is not mandatory from a specification perspective, we recommend including it consistently.

Sample DMARC records with tags

For most DMARC records, these values are all you need. A typical TXT record might look like this, where the email address in the rua is replaced with the reporting address for your domain:

Curious what your DMARC policy looks like and what tags you've used? Use Valimail's free domain checker to discover your tags:

Optional DMARC tags: a quick reference

There are more than three DMARC tags, but those are the only three that are absolutely required to set up your DMARC policy. However, there are other DMARC tags that are optional.

You don’t need to include all of these to benefit from DMARC. In fact, using too many too early can create confusion or misconfiguration. While you don’t need to use them, they may be helpful in some instances:

Tag	Name	Required	Description
v	Version	Yes	Must be set to DMARC1 to identify the record as a DMARC policy.
p	Policy	Yes	Tells receivers what to do with messages that fail DMARC (none, quarantine, or reject).
rua	Aggregate reports	Yes	Specifies where to send DMARC aggregate reports (mailto: URL). Not technically required, but essential for visibility.
ruf	Forensic reports	No	Sends detailed (and potentially sensitive) failure reports to a designated address. Rarely used today.
pct	Percentage	No	Applies policy to only a portion of your messages (e.g., pct=50 applies policy to half of traffic).
sp	Subdomain policy	No	Defines a different policy for subdomains than the main domain.
aspf	SPF alignment mode	No	Sets strict or relaxed alignment for SPF (r or s).
adkim	DKIM alignment mode	No	Sets strict or relaxed alignment for DKIM (r or s).
fo	Forensic options	No	Controls when forensic reports are sent (used with ruf).
rf	Report format	No	Specifies format of failure reports (usually left at default: afrf).
ri	Report interval	No	Suggests how often (in seconds) to send aggregate reports. Most receivers default to 86400 (24 hours).

For most organizations, the required tags (v, p, and rua) are all you need to:

• Start receiving feedback
• Monitor your domain’s mail streams
• Begin your journey toward full DMARC enforcement

Advanced tags like aspf, pct, or sp are useful in more complex deployments, but they’re not necessary for a standard DMARC rollout.

If you’re unsure what to include, keeping it simple is the best path, and Valimail can help you automate and manage this without the guesswork.

Putting it all together: sample DMARC records

Starting out (monitoring mode):

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

First enforcement step (quarantine):

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

Full enforcement (reject):

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

Notice that the only thing changing between these three records is the value of the p tag. The structure stays the same throughout your entire DMARC journey.

Easily manage your DMARC tags with Valimail

Make DMARC simple and safe to enforce.

Valimail simplifies email authentication. Our platform analyzes your DMARC reports, identifies trusted senders, and guides you step by step toward full enforcement with no broken email, no guesswork.

Start by signing up for Valimail Monitor and get free visibility and more management of your DMARC tags.

Frequently asked questions about DMARC tags