The DMARC standard defines a number of different DMARC tags that can be used in a DMARC record. Some of these tags are required, but most are optional, and a number of the tag definitions can be a little confusing.
In most cases, a well-formed DMARC record needs to include three tags, while the remaining tags can be ignored. Get these three tags right, and you’ll be able to take advantage of the visibility, control, and anti-phishing benefits that DMARC has to offer:
- V – version tag
- P – policy tag
- RUA
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.
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:
- none: The sending domain is in ‘test’ mode. 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.
- quarantine: Receivers are asked to quarantine messages that fail authentication. Typically the message is marked as spam.
- 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 give the domain owner a global view into which servers and third-party services are sending messages on the domain owner’s behalf, as well as any abuse of the domain by phishers.
Without aggregate reports, you’re flying blind. Moving to a ‘p=quarantine’ or ‘p=reject’ level becomes very unsafe because legitimate email may be unknowingly blocked. While including a ‘rua’ tag is not mandatory from a specification perspective, we recommend always including it.
Learn more about DMARC
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:
v=DMARC1; p=reject; rua=mailto:reports@example.comWant to learn more about DMARC and DMARC tags? We’ve got you covered. Read our comprehensive guide to DMARC to learn all the ins and outs.
