Dmarc as a Service

DMARC: The only 3 tags you really need

The DMARC standard defines a number of different 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 need only 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.

Components of a DMARC TXT record

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.

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 to not deliver failing messages to the recipient at all. Some receivers honor this request, while other receivers just mark failing messages as spam.


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 mailto URIs 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 purport to be from the domain. These reports are zipped XML documents containing aggregated information on source IP address and authentication status for all the messages in a given period — typically a day. When properly analyzed by a service like Valimail, they 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, the domain owner is blind. Moving to a ‘p=quarantine’ or ‘p=reject’ level becomes very unsafe because legitimate email may be unknowingly blocked. So while including a ‘rua’ tag is not mandatory from a specification perspective, it’s a very bad idea to leave it out.

For most DMARC records, these values are all you need. A typical TXT record might look like:

v=DMARC1; p=reject;

where the email address in the rua is replaced with the reporting address for your domain.

We’ll talk about some of the other values that can be defined in a DMARC record, and the comparatively rare cases in which they’re needed, in future blog posts.