DMARC Tags Cheat Sheet: Definitions and Examples

DMARC tags are the building blocks of a DMARC record. They tell receiving email servers how to process messages that fail authentication, where to send reports, and how strictly SPF and DKIM domains must align with the visible sender domain.

A DMARC record is published as a TXT record in a domain’s DNS. It consists of tags and values separated by semicolons. Using the correct tags helps protect your domain from spoofing while giving you greater visibility into legitimate and unauthorized email activity.

Key Takeaways

• Every DMARC record must include the v and p tags.
• The p tag determines what happens to messages that fail DMARC.
• The rua tag lets domain owners receive aggregate reports.
• The sp tag applies a separate DMARC policy to subdomains.
• The adkim and aspf tags control DKIM and SPF alignment.
• Starting with p=none allows you to monitor email traffic before enforcing stricter protection.
• DMARC reports should be reviewed regularly before moving to quarantine or reject.

Required DMARC Tags

 

The v Tag.

 
The v tag identifies the DMARC protocol version. It must appear first in the record.

Example:

v=DMARC1;

At present, DMARC1 is the standard value. A DMARC record without this tag will not be recognized correctly by receiving email servers.

The p Tag.

 
The p tag specifies the policy that receiving servers should apply to emails that fail DMARC.

There are three possible values.

p=none

This is a monitoring policy. Receiving servers do not receive special instructions to quarantine or reject failed messages.

Example:

v=DMARC1; p=none;

This policy is commonly used during the first stage of DMARC implementation. It allows domain owners to collect reports and identify all legitimate sending sources.

p=quarantine

This policy asks receiving servers to treat failed emails as suspicious. Such messages may be delivered to the spam or junk folder.

Example:

v=DMARC1; p=quarantine;

p=reject

This is the strongest DMARC policy. It asks receiving servers to reject messages that fail DMARC before they reach the recipient’s mailbox.

Example:

v=DMARC1; p=reject;

Domain owners should normally review their email sources and fix authentication problems before implementing a reject policy.

Optional DMARC Tags

 

The sp Tag.

 
The sp tag defines the DMARC policy for subdomains.

Example:

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

In this example, the main domain remains in monitoring mode, while messages from subdomains that fail DMARC should be rejected.

When the sp tag is not included, the policy defined in the p tag also applies to subdomains.

The pct Tag.

 
The pct tag determines the percentage of failed messages to which the DMARC policy should be applied.

Example:

v=DMARC1; p=reject; pct=25;

This record asks receiving servers to apply the reject policy to 25% of messages that fail DMARC.

The default value is 100. Gradually increasing the percentage can help domain owners introduce enforcement while limiting potential disruption.

However, support for percentage-based enforcement may vary between receiving systems. Reports should therefore be monitored carefully during policy changes.

The rua Tag.

 
The rua tag specifies where aggregate DMARC reports should be sent.

Example:

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

Aggregate reports provide summarized information about:

• Sending IP addresses
• Email volume
• SPF authentication
• DKIM authentication
• DMARC alignment
• Messages that passed or failed DMARC

These reports are normally delivered in XML format and can be difficult to analyze manually. A DMARC monitoring platform such as DMARKOFF can organize the report data and make authentication problems easier to identify.
 
Start 14-day Free Trial
 
Multiple reporting addresses can be added:

rua=mailto:dmarc@example.com,mailto:security@example.com;

The ruf Tag.

 
The ruf tag identifies where DMARC failure reports should be sent.

Example:

v=DMARC1; p=reject; ruf=mailto:failures@example.com;

Failure reports may contain details about individual authentication failures. However, not every receiving provider sends them, and availability may depend on the provider’s privacy and reporting policies.

The fo Tag.

 
The fo tag determines when failure reports should be generated.

Common values include:

• fo=0: Generate a report when both SPF and DKIM alignment fail.
• fo=1: Generate a report when either SPF or DKIM alignment fails.
• fo=d: Generate a report for a DKIM failure.
• fo=s: Generate a report for an SPF failure.

Example:

v=DMARC1; p=reject; ruf=mailto:failures@example.com; fo=1;

The fo tag is relevant only when the record also contains a ruf address.

Values may be combined using colons:

fo=0:d:s;

The adkim Tag.

 
The adkim tag controls DKIM identifier alignment.

It supports two values:

• adkim=r: Relaxed alignment
• adkim=s: Strict alignment

In relaxed mode, the organizational domain in the DKIM signature must match the organizational domain in the visible From address.

In strict mode, the domains must match exactly.

Example:

v=DMARC1; p=reject; adkim=s;

Relaxed alignment is the default when the tag is not included.

The aspf Tag.

 
The aspf tag controls SPF identifier alignment.

It also supports relaxed and strict modes:

• aspf=r: Relaxed alignment
• aspf=s: Strict alignment

Example:

v=DMARC1; p=reject; aspf=r;

Under relaxed alignment, the organizational domain in the Return-Path address must match the organizational domain in the visible From address. Strict alignment requires an exact domain match.

Relaxed mode is used by default.

The ri Tag.

 
The ri tag requests the interval between aggregate reports, measured in seconds.

Example:

v=DMARC1; p=none; rua=mailto:dmarc@example.com; ri=86400;

The value 86400 represents 24 hours and is the default reporting interval. Receiving providers are not always required to follow a custom interval exactly.

The rf Tag.

 
The rf tag defines the requested format for failure reports.

Example:

rf=afrf;

The default value is afrf, meaning Authentication Failure Reporting Format. Because this is the standard supported value, the tag is rarely necessary in a basic DMARC record.

How to Choose the Right DMARC Tags

 
A DMARC record does not need to contain every available tag. Most teams can begin with:

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

After publishing the record, monitor the reports and create an inventory of all legitimate services that send email on behalf of the domain. These may include marketing platforms, transactional email providers, customer support systems, and internal mail servers.

Check that each legitimate source passes SPF or DKIM and achieves DMARC alignment. Once authentication problems have been resolved, move gradually to p=quarantine and eventually p=reject.

Using DMARKOFF to process aggregate data can simplify this process by helping teams distinguish legitimate senders from unknown or potentially malicious sources.

Secure Your Brand
 

Conclusion

 
DMARC tags determine how a domain’s DMARC policy works. The required v and p tags activate DMARC and establish the policy, while optional tags provide control over reporting, subdomains, alignment, and enforcement percentages.

A simple monitoring record is often the safest place to start. Domain owners can then analyze DMARC reports, authenticate legitimate email services, and gradually move toward a reject policy.

Correctly configured DMARC tags improve domain security, reduce the risk of spoofing, and provide valuable insight into how a domain is being used across the email ecosystem.