Breaking down a DMARC record: What it is and how it looks like

What is a DMARC record?

DMARC records are an integral part of your DMARC compliance – your domain’s authentication handbook, if you will.

In short, a DMARC record is a DNS TXT record that gets added to a domain to specify what should happen to an email that fails SPF and DKIM authentication. DMARC records tell mailbox providers what to do with these unauthenticated messages: do nothing, quarantine them, or reject them.

DMARC records are effectively a short line of text with instructions that is stored in the Domain Name System (DNS). They look just like this:

One of the most important elements in a DMARC record is the policy (p), which can be found at the beginning, but that’s not the only information you’ll find if you look closely.

So, what do all the other tags mean? What valuable information do they provide? Let’s examine each tag in detail.

How to create a DMARC record: The basic tags

DMARC records can contain a range of different tags to let mailbox providers know what to do with incoming email that fails DMARC authentication. Some of these tags are required, some are optional but commonly used, and others are less frequent.

Here’s a table with all the tags we’ll go over in this post – some of the more basic and other less common options you might find useful for your business.

Every DMARC record contains at least two tags – the ‘v’ and the ‘p’. But you also want to be sure and include the ‘rua’, and some of these optional tags that can also add valuable information.

Let’s start off by looking at the basic tags in a DMARC record.

The ‘v’ tag

The ‘v’ value is the identifier. It represents the version of DMARC that your domain is using. At this point, ‘v=DMARC1’ is the only version in use.

When the mailbox provider performs a DMARC scan, it’s looking for an identifier. If it doesn’t find one, it doesn’t perform a DMARC check. In other words, the ‘v’ tag makes it known that emails from your domain are eligible for DMARC authentication.

The ‘p’ policies

The ‘p’ tag tells the mailbox provider what to do with messages that fail DMARC. As mentioned earlier, there are three policy options: none, quarantine, and reject. The best policy for you depends on where you are in the process.

This is the most important part of the DMARC record. Let’s look at all three options.

Monitor policy: p=none

The DMARC policy ‘none’ tells the email receiver to do nothing with a message that fails authentication, and to send a report about it to an email address you specify in the DMARC record. This means the email’s recipient will still see the failed email in their inbox. In other words, nothing happens.

Interestingly, the current plans put forth by Yahoo and Google require bulk email senders only to set p=none as their policy, even though it’s the least restrictive choice. But why go to all this trouble to set up DMARC only to tell it to do nothing with emails that fail to pass authentication?

Well, it’s simple: When you’re just getting started, you don’t know exactly what to expect. And if you choose either of the other two policy options, you might get bombarded with thousands or even millions of emails notifying you of emails failing your DMARC checks.

You don’t want that. You might also end up quarantining or rejecting legitimate emails from your brand. You definitely don’t want that, either.

Quarantine policy: p=quarantine

The next policy option is ‘quarantine’. This DMARC policy instructs email receivers to filter emails that fail the DMARC checks into the recipient’s spam folder. Then, it sends the DMARC report to an email address you specify, just like with the ‘p=none’ policy.

So, quarantining emails means that recipients can still see and open problematic emails, but they’ll be in their spam folder.

Reject policy: p=reject

The third policy option is ‘reject’. Like the others, it also sends a DMARC report. But additionally, this option completely rejects emails that fail DMARC checks and blocks them from ever reaching the recipient’s email inbox. 

As you monitor and adjust your DMARC record, your goal is to reach a point where you can confidently reject all emails from spammers and spoofers attempting to profit off of your brand.

The ‘rua’ tag

The ‘rua’ tag specifies the email address you want to receive all aggregated DMARC reports that will get created whenever an email fails authentication. It looks like this:It looks like this:

You can add any email address you choose to the ‘rua’ tag, or even specify multiple ones.

However, you’ll want to make sure you create a new email address that will only be used for this purpose. You might get a lot of DMARC reports – probably one per day – and you don’t want to clog up your other email addresses with them.

The ‘ruf’ tag

The ‘ruf’ tag indicates the email address where the forensic reports of DMARC failures will be sent. These forensic reports contain additional details about each email that fails to pass authentication.

The tag looks something like this:

You’ll get emails with forensic reports in real time, meaning you’ll get many more of these than the aggregate ones. So, again, make sure you identify a dedicated email address for these reports.

But unlike the ‘rua’ email address, which can be anything, the address you specify in your ‘ruf’ tag must be from the domain that published the DMARC record.

The ‘rf’ tag

The ‘rf’ tag specifies the format for the reports you’ll receive. Currently, ‘afrf’ is the only value in use, so there isn’t necessarily a strong reason to do this, other than to further strengthen your DMARC record.

Oh, and in case you were wondering, ‘afrf’ stands for aggregate failure reporting format.

The ‘pct’ tag

The ‘pct’ tag allows you to control what percentage of emails that fail authentication get quarantined or rejected.

In other words, if you select ‘p=quarantine’ or ‘p=reject’, but do not select a ‘pct’ other than 100, 100% of failing emails – that is, all emails – will get quarantined or rejected.

If you’re just starting with your DMARC authentication, it might be wise to start off with a lower percentage, such as 10%, and make sure the emails failing your DMARC policy are correctly flagged.

For example, you might begin with ‘p=quarantine’ and ‘pct=10’. This would mean that 10% of emails that fail authentication will get quarantined into the spam folder, and the remaining 90% will pass through to the inbox.

Other DMARC record tags

We’ve covered the basic tags in the section above, but these are not the only pieces of information that can be added to your DMARC record.

There are several other tags that can be included to provide additional instructions for mailbox providers. Here are a few important ones:

The ‘sp’ tag

By default, a DMARC policy is hierarchy based, meaning any policy applied at the top level will filter through to all subdomains.

The ‘sp’ tag allows you to change the DMARC policy for your subdomains. It works in the same way as the policy (‘p’) tag from earlier, and has the same three options – none, quarantine, and reject –, but they can differ from what you specify for your ‘p’ values.

For example, suppose you never intend to send any emails from any subdomains and want to prevent spoofers from attempting to do so. You might use this combination of tags in your DMARC record: p=none; sp=reject.

In this example, the ‘p’ value applies to your main domain, and the ‘sp’ value applies to all possible subdomains.

The ‘adkim’ tag

The ‘adkim’ tag gives you two options for defining what an email must do to pass your DKIM authentication, and it can be set to ‘s’ for strict or ‘r’ for relaxed. If you don’t set this value, it defaults to relaxed.

• Strict (‘s’) means an email passes the DKIM portion of DMARC authentication only if the entire ‘d=’ field in the DKIM signature exactly matches the From address.

• Relaxed (‘r’) means that email messages will pass if the DKIM ‘d=’ field matches only the root domain of the From address.

The term ‘root domain’ refers to the core section of your email address. Let’s assume that is ‘address.com’. So, a sending domain such as ‘service.address.com’ would fail a strict setting, but would pass a relaxed one, because they share the address.com domain.

The ‘aspf’ tag

Similar to the previous tag, the 'aspf’ tag specifies what an email must do to pass your SPF authentication. You can set it to the same two values: strict (‘s’) s and relaxed (‘r’).

Both of these values work the same as they do in the ‘adkim’ tag - ‘s’ looks at the entire address specified in the ‘s=’ field of your SPF signature, while ‘r’ focuses only on the root domain.

As before, if you don’t specify this value, it defaults to the relaxed setting.

The ‘ri’ tag

How often do you want to receive DMARC aggregate reports? If you don’t specify anything different, these reports come once a day, reporting all the emails that failed your authentication protocols.

The ‘ri’ tag allows you to alter how often you get these reports. The minimum – and default – value is once a day, but you can set it to a different timeframe, so they come every other day, once a week, or at whatever cadence you prefer.

It’s important to note that this value is measured in seconds, not days. A ‘ri’ value of 86400 means you’ll get reports once a day, so if you want to set a different timeframe, you’ll need to get good at math. Did you know there are 86,400 seconds in a day? Well, now you do.

How to add your DMARC record

So, now you know the tags. Take some time to reflect on which ones you want to include and create a DMARC record that matches your email needs. Remember – you might not need them all, but you’ll at least want to include the ‘v’ and ‘p’ tags. And like we said before, at Sinch Mailjet, we also recommend specifying the ‘rua’ tag.

Once you’ve created your DMARC policy, you need to go to your host’s DNS settings to publish it. Depending on your host, the steps might vary, but here’s the basic procedure:

1. Under DNS hostname, enter your record name: _dmarc.yourdomain.com.

2. Under DNS record value, input your DMARC record: Make sure this is the full record with all the tags and values as discussed earlier.

3. Save the changes.

Adding and publishing your DMARC record is a relatively simple process, but it’s only one step in setting up your DMARC authentication, so make sure you’ve completed the full configuration before you call it a day.

Want to learn more about DMARC? Check out what the experts had to say in Sinch Mailgun’s podcast, Email’s Not Dead. Join Ash Morin from Dmarcian and Kate Nowrouzi, VP of Deliverability at Sinch Mailgun, as they discuss the ins and outs of DMARC with our hosts.

Setting up your DMARC authentication

Okay, had enough code talk for one day? We thought so.

DMARC records are an essential part of your DMARC authentication, but that doesn’t mean you need to add all these tags or learn them off by heart. Keep this post handy whenever you're setting up or changing your DMARC configuration and apply the tags that best fit your use case.

With the recent changes announced by Gmail and Yahoo, setting up your DMARC authentication is no longer a choice, and bulk email senders will need to familiarize themselves with new authentication requirements – soon.

Still need some extra help? Sinch Mailjet’s support team is ready to help Mailjet customers navigate these changes. Whether you need a helping hand while going through configuration or just some reassurance that your DMARC policy has been correctly set up, we’ve got you. Just reach out to our team for assistance!