Back to main menu

Deliverability

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

DMARC is becoming increasingly important amidst changes from mailbox providers, but it can be a fairly technical concept. Let’s dive into an example of a DMARC record and break down what each part means and how it relates to the goals of DMARC authentication.

Greek god and goddesses by a laptop

PUBLISHED ON

PUBLISHED ON

DMARC authentication is hard – we know it. For many email senders, the technical complexities of DMARC are just enough of a headache to put it off until it becomes an absolute must in the world of email.

Well, that time has come. Gmail and Yahoo have announced they’ll be strengthening their fight against unsolicited emails in 2024 with new requirements, including enhanced email authentication – and that includes DMARC.

DMARC records are a critical part of the DMARC authentication process and understanding how to create yours is key to ensure DMARC is set up correctly.

We discussed the basics of DMARC and how to implement it in our post “What is DMARC and how it works”. Now, we’ll cover what DMARC records are, how to create yours and what each tag means, and how to get it added to your domain’s DNS.

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.

TAG

REQU­IRE­D

WHAT­ IT DOES­

TAG

v

Yes

The ‘’ tag iden­tifies the DNS reco­rd and spec­ifies the DMAR­C vers­ion.

REQU­IRE­D

p

Yes

The ‘’ tag spec­ifies a doma­in’s DMAR­C poli­cy: none­, quar­antine, or reje­ct.

WHAT­ IT DOES­

rua

No

The ‘r­ua’ tag indi­cates the emai­l addr­ess wher­e DMAR­C ag­gregate repo­rts for fail­ed emai­l auth­entications will­ be sent­.

ruf

No

The ‘r­uf’ tag indi­cates the emai­l addr­ess wher­e DMAR­C fo­rensic repo­rts for fail­ed emai­l auth­entications will­ be sent­.

rf

No

The ‘r­f’ tag decl­ares the fore­nsic repo­rting form­at – curr­ently, only­ ‘a­frf’.

pct

No

The ‘p­ct’ tag indi­cates the perc­entage of emai­ls that­ will­ be quar­antined or reje­cted if auth­entication fail­s.

sp

No

The ‘s­p’ tag spec­ifies a part­icular DMAR­C poli­cy for emai­ls comi­ng from­ subd­omains.

adkim

No

The ‘a­dkim’ tag defi­nes what­ an emai­l must­ do to pass­ DKIM­ auth­entication.

aspf

No

The ‘a­spf’ tag defi­nes what­ an emai­l must­ do to pass­ SPF auth­entication.

ri

No

The ‘r­i’ tag indi­cates how ofte­n aggr­egate repo­rts are sent­ to the emai­l addr­ess spec­ified in the ‘r­ua’ tag.­

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.

dmarc policy mailjet Image

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.

p=none is a good policy to start with so you can see where things stand initially. It’s the monitoring step. You can get a sense of your current data and the reality it represents, and then begin adjusting your DMARC record over time.

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.

Over time, the goal is to have your ‘pct’ value set to 100. So, if you decide to start it off lower, be sure to monitor your data and increase this percentage as you gain confidence the policy is working as it should.

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.

If you have a variety of email addresses and use various subdomains as part of your email communications, you may want to start off with sp=none to see some DMARC reports and study the data before taking action.

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.

  • Badge Check

    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.

  • Badge Check

    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.

At Sinch Mailjet, we recommend our customers to set their ‘adkim’ setting to a relaxed status and avoid using strict if possible.

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.

At Sinch Mailjet, we recommend our customers to set their ‘aspf’ setting to a relaxed status and avoid using strict if possible.

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. Badge Check

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

  2. Badge Check

    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. Badge Check

    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.

If you’re not sure what DMARC is, why you need it, or how to set it up, check out our post “What is DMARC and how does it work”. We’ve got everything you need to get your email authentication in check before these new requirements come into effect in January 2024.

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!

Sinch Mailjet

Need help publishing your DMARC policy?

Contact our support team to get assistance with your DMARC setup. Our team of email experts will be more than happy to answer any questions or concerns you may have.

Popular posts

Hermes rides a firework next to a Goddess in front of a night sky with more fireworks

Email best practices

6 min

Top email marketing trends for 2022

Read More

Hermes on a moped delivering mail to a mailbox

Email best practices

8 min

Reducing email’s carbon footprint

Read More

Mother's day gift for Hera

Marketing

14 min

Marketing calendar 2024: Dates you shouldn’t miss this year

Read More

It's never been easier to build connected experiences. Start sending with Mailjet today.Get started on your path
CTA icon