What Is Domain-Based Message Authentication Reporting And Conformance (DMARC) Policy & Reporting – A Comprehensive Guide

While it may all seem simple on the surface, emails are complicated. Emails have been manipulated in the past to perform malicious tasks unimaginable to humans. This is why email authentication and verification processes are now much stricter when compared to a few years ago.

Domain-based Message Authentication Reporting And Conformance, or DMARC, is one of the 3 major email authentication methods, alongside SPF and DKIM.

DMARC builds on top of these technologies and declares how emails should be handled if they fail their authentication checks. Additionally, it is also a reporting system that provides the statistics on the incoming emails, and whether they passed or failed the checks. This reporting mechanism helps you set up the DMARC policies tighter, and correctly.

Previously, many email service providers didn’t make the use of DMARC policies compulsory for email servers. However, Yahoo and Gmail are making drastic changes and making it compulsory for DNS servers to include DMARC records.

What is the purpose of DMARC

Before diving into the depths of DMARC, it is important to understand what it is needed for, especially if you already have SPF and DKIM records on your DNS server.

The SPF records tell which servers should the incoming mail server accept the emails from. If it’s not on the list, the email is probably a fake. The DKIM records verify the encrypted digital signature in the incoming email, match it from the envelope header, and verify the email. As you can see, these are both indicators, and do not make a decision on how to handle the email in case any one or both of these checks fail.

This is where DMARC comes in. DMARC judges what the results of the DKIM and SPF authentication are, and tells the server how to handle the email. It would either allow the email to land in the receiver’s Inbox, send it to the spam folder, or reject it altogether. But DMARC is a bit more complicated than that – it uses something called “DMARC alignment“, which has been discussed in detail further down this post. Right now, do not be alarmed by this term.

Moreover, if you do not correctly configure the SPF or the DKIM records, it might be possible that you or your clients stop receiving any emails altogether. For Example, if you missed one server while configuring the SPF record, the end-users might not receive emails. Similarly, if you misconfigure the DKIM keys, or did not include the correct one, the end-users may not receive the emails.

That said, it is likely not the case. Some emails, despite failing both SPF and DKIM checks, still end up in the user’s inbox. This is good for the servers that you forgot to add, but bad for the spoofers that you wanted to fill out in the first place. DMARC reporting can help you configure SPF and DKIM policies correctly while catering to any loopholes for spoofers, or rejecting authentic emails.

What is DNS DMARC Record

Like SPF and DKIM, DMARC records are also stored on the DNS server as a TXT record. It uses special syntax and file name that defines that it is a DMARC record. Inside the value of the record, special tags and parameters are used to define how the DMARC record handles the incoming emails, how strict the SPF and DKIM checks are, and where to send the DMARC reports.

The DMARC record holds the DMARC policy. What happens to an email once it is verified against SPF and DKIM data is determined by a DMARC policy. Emails pass or fail SPF and DKIM checks. If an email fails, the DMARC policy decides whether to classify it as spam, block it completely, or continue to send it to the intended recipient.

A DMARC DNS record has two major parts:

• The DMARC Record name
• The DMARC policy

DMARC Record name

If you know how the DKIM record is set up, you would know that it uses a selector which tells the email server which record to look up for DKIM authentication. It is the same selector in the DKIM header in an email. Similarly, the name of the DMARC record on a DNS server also needs to be specific.

The name of the DMARC TXT file needs to start with “_dmarc“, followed by your domain, and should look something like this:

_dmarc.yourdomain.com

“yourdomain.com” will be replaced by your domain name.

DMARC Policy

The DMARC policy or the DMARC record may look something like this:

v=DMARC1;p=quarantine;pct=100;adkim=s;aspf=r;rua=mailto:postmaster@itechtics.org;ruf=mailto:postmaster@itechtics.org

While all of the above-given tags are not necessary, they are required for different purposes but can be done without. It may seem confusing at first, but the table below will explain what each of these tags are for:

Tag	Condition	Description and Values
v	Mandatory	Defines the CMARC version. Normally it is “DMARC1“
p	Mandatory	Instructs what to do with emails that do not pass authentication. It can be “none“, “quarantine“, or “reject“
pct	Optional	Specifies the percent of unauthenticated messages that are subject to the DMARC policy – must be between 1 and 100
rua	Optional	The defined email address receives aggregated DMARC reports of spoofed emails
ruf	Optional	The defined email address receives forensic DMARC reports of spoofed emails
adkim	Optional	Sets alignment policy for DKIM. Can be “s” for strict (the sender domain name must exactly match the corresponding domain name in the DKIM mail headers), or “r” for relaxed (any valid subdomain of the main domain in the DKIM headers is accepted).
aspf	Optional	Sets alignment policy for SPF. Can be “s” for strict (the FROM HEADER should exactly match the MAIL FROM (envelope) header), or “r” for relaxed (the domain in the FROM HEADER should match or be a subdomain of the MAIL FROM header).
sp	Optional	Sets the policy for messages from subdomains of your primary domain. It can be “none“, “quarantine“, or “reject“. If ta is not used, the subdomains inherit the DMARC policy set for the parent domain.
fo	Optional	Determines the types of reports that are sent out. Can choose from “0“, “1“, “d“, and “s“, or use a combination.
rf	Optional	Defines the format to be used for message-specific failure reports. The current valid value is “afrf“, which stands for “Authentication Failure Reporting Format”.
ri	Optional	Indicates a request to receivers to generate aggregate reports separated by no more than the requested number of seconds. Valid value is a 32-bit unsigned integer. The default value is 86,400 seconds (24 hours).

I understand that the table above could introduce more confusion instead of clearing things up, which is why the following information has been added that further expands on the tags and values of a DMARC policy.

• “p” tag in DMARC policy

  The values for the P tag could be one of the following, and here is what each of these does:

  • none: DKIM and SPF checks do not affect email filtering and the emails are forwarded as-is. This option is mostly used for DMARC reporting.
  • quarantine: Emails that do not pass the DKIM and SPF checks are tagged and sent to the recipient’s spam folder.
  • reject: Emails that do not pass the DKIM and SPF checks are blocked and never delivered to the recipient.

• “pct” percentage in DMARC policy

  The “pct” tag is used to define the percentage of unauthenticated incoming emails that are subject to the DMARC policies.

  For example, if “pct” was set to “50”, it would mean that 50 percent of the emails that have failed DMARC authentication would be subject to the defined policy. If the “p” tag was set to “reject”, 50 percent of the emails would be rejected, while the other 50 percent would continue to be delivered to the recipient.

  At the initial stages of setting up the DMARC policy, the “pct” is usually set to “0” so it would not apply the policy to any emails. Meanwhile, you can analyze the generated DMARC reports and configure the policies correctly.

• “rua” and “ruf” tags in DMARC policy

  Both “rua” and “ruf” tags define the email addresses where the aggregated and forensic reports are to be sent. Both of these must include “mailto“, if being used.

  An aggregated report is in the XML format, sent intermittently, and has information on all the unauthenticated emails. However, the forensic reports are in plain text, sent immediately after an email was not authenticated, and contain information only for a single email.

• “fo” tag in DMARC policy

  The “fo” tag is for failure reporting options and determines the types of reports that are sent out. You can choose from the following options:

  • 0: Generate a DMARC failure report if all underlying authentication mechanisms (SPF and DKIM) fail to produce an aligned “pass” result. (Default)
  • 1: Generate a DMARC failure report if any underlying authentication mechanism (SPF or DKIM) produced something other than an aligned “pass” result. (Recommended)
  • d: Generate a DKIM failure report if the message had a signature that failed evaluation, regardless of its alignment.
  • s: Generate an SPF failure report if the message failed SPF evaluation, regardless of its alignment.

  You can also use two or more types simultaneously, and define them as a single value, separating them with a colon (:), like in this example:

  fo=0:1:s;

• “adkim” and “aspf” tags in DMARC policy

  “adkim” sets the alignment policy for DKIM alignment, and the “aspf” tag sets the policy for SPF alignment. You can choose either “s” or “r” for both of these tags, where “s” stands for Strict, and “r” stands for Relaxed. If you do not use this tag, the default value will be Relaxed for both of these tags.

  I understand that the term “alignment” may be confusing, and you may be wondering what it means. Since it is a confusing topic, I have explained it in detail in the next section below.

What is SPF, DKIM, DMARC alignment

Learn the key differences between SPF, DKIM, and DMARC.

Remember when we had discussed that the FROM HEADER was different from the MAIL FROM header? If not, don’t worry. Here is a quick recap.

An email has two parts (or does it?) – A body and a header. The body is where the text is, and the header is what contains the metadata for the email. The header has different parts; for example, the sender’s information, the receiver’s information, etc. It also has the DKIM header (which is different from a DKIM record).

However, there is another part of an email that the end user does not see, and is referred to as the “envelop”. The envelope has additional information about the email. More precisely, the envelope has a “FROM” header, which is also available in the email’s header. However, there is a difference.

The “FROM” header that you can see in an email tells you who the email sent. It is called the FROM HEADER. However, the envelope’s header, referred to as the MAIL FROM header, is actually what the SMTP protocol uses to route the email. While this header also contains the email’s sender, it might not be the same as the FROM HEADER.

Note that both of these headers have the sender’s domain inside them. For example, if I am the sender, and my email address is “subhan@itechtics.org“, then my domain is “itechtics.org“. This information is important since this is what SPF, DKIM, and DMARC use for alignment.

For SPF alignment to pass, the domain name in the MAIL FROM header must match the domain name in the FROM HEADER. If both domain names do not match exactly, or the domain in the MAIL FROM header is not even a subdomain of the MAIL FROM header, the SPF alignment fails.

For DKIM alignment to pass, the domain in the DKIM header (defined by the “d” tag) must match the domain in the FROM HEADER. If the two domains do not match, or the domain defined in the DKIM header is not even a subdomain of the FROM HEADER, the DKIM alignment fails.

Now, reverting back to the “adkim” and “aspf” tags in a DMARC policy, whether the two domains should be an exact match or a match with the subdomain, is determined by the value set for the tags. If the value is set to “s” for Strict, the two domains need to be an exact match. If the value is set to “r” for Relaxed, the domain in the DKIM header (for DKIM alignment) or the MAIL FROM header (for SPF alignment) can only be a subdomain of the FROM HEADER.

The following table might help you understand better:

Authentication method	Strict alignment	Relaxed alignment
SPF	An exact match between the SPF authenticated domain, and the domain in the header From: address.	The domain in the header From: address must match or be a subdomain of the SPF authenticated domain.
DKIM	An exact match between the relevant DKIM domain, and the domain in the header From: address.	The domain in the header From: address must match or be a subdomain of the domain specified in the DKIM signature d= tag.

With that understanding, let us move on to DMARC alignment. The DMARC check will only pass if one of the following checks passes:

• SPF authentication and SPF alignment
• DKIM authentication and DKIM alignment

A DMARC check fails if both of the following checks fail:

• SPF or SPF alignment
• DKIM or DKIM alignment

Based on these checks, and the DMARC policy leniency settings, DMARC makes a judgment on how to handle unauthenticated incoming emails.

What is a DMARC report

As discussed earlier while understanding the DMARC tags, the “rua” and “ruf” tags defined the email addresses for the DMARC reports, where the aggregated report is sent to the former email address, and the forensic reports are sent to the latter.

Aggregated reports are sent intermittently, perhaps once a day. It is in the HTML format, therefore quite hard to understand. People usually use third-party services or apps that take these HTML reports and translate them into human-readable format.

The forensic reports are generated and sent for each unauthenticated email, as soon as it is received by the mail server. These are in plain text and, therefore understandable by humans.

These reports can be used to determine whether you have configured the SPF, DKIM, and DMARC records correctly since the reports will inform you of the mail servers trying to spoof you, or the legitimate servers that are being blocked because of incorrect configurations.

DMARC reports inform you of the following:

• What servers are sending mail to your domain.
• What percentage of emails from your domain pass DMARC.
• Which servers or services are sending emails that fail DMARC.
• What DMARC actions does the incoming mail server take on unauthenticated emails for your domain.

Note: You just cannot begin sending DMARC reports to anyone; only the ones who allow you to. Read more about it in the “Allowing DMARC Reports” section below.

How to check DMARC Records

Like SPF and DKIM, you can retrieve the DNS DMARC records for any domain using third-party tools, like the Email Validation Tool. Simply enter the domain name and click Validate, and you will be presented with a bunch of information about the domain, including its DMARC records if they exist.

How to set up DNS DMARC record

If you want to set up a DMARC record, you must first have access to the DNS server. If you do, you must begin the DMARC setting with lenient configurations, so that the end users are not deprived of even legitimate emails. Meanwhile, you can benefit from the DMARC reports so you know which servers are spoofing your mail server, and which domains need to be allowed.

Moreover, before setting up the DMARC record, I would also recommend that you configure DKIM and SPF first. Although DKIM is not necessary, it is very much recommended.

Once ready, use the following steps to add a DMARC record on your DNS:

Note: Each DNS server might have different configurations and settings. However, the same logic and syntax apply.

1. Start by logging into your DNS server and navigating to the zone management portal.

2. Click “Add Record” and then click “Add TXT Record“.

   

3. Enter the name for the DMARC record using your domain name, such as this:

   _dmarc.[domain.com]

   

4. Now use the following syntax while replacing the variables and paste it into the Record field:

   Note: You can, of course, edit the following command and include or remote any optional tags, as per your requirement. It is recommended that you keep the policy lenient initially.

   v=DMARC1;p=[policy];pct=[percentage];adkim=[leniency];aspf=r[leniency];rua=mailto:[AggregateEmail];ruf=mailto:[ForensicEmail]

   

5. [Optional] You may adjust the Time To Live (TTL) value, which is actually how long the record will be cached for.

6. When done, click Save Record.

After performing the steps above, wait a while so the new DNS records can propagate across the internet. This can take anywhere between a few minutes to a day.

Moreover, once you begin receiving the DMARC reports, analyze them to make sure that you have configured the SPF, DKIM, and DMARC policies correctly. After a while, you may start tightening your DMARC policy and begin filtering out unauthenticated emails.

Allowing DMARC Reports

If you are not receiving DMARC reports even after configuring it correctly, there might be some additional configuration needed.

DMARC reports go out easily if you are sending them to someone on the same domain. For example, if “itechtics.org” is trying to send out DMARC reports to someone on “itechtics.com“, they won’t be delivered without explicitly allowing them, since the receiver is out of my domain.

To send reports to someone outside of the original domain, you must configure External Domain Verification or EDV. EDV is set up as a DNS TXT record on the receiving domain. EDV records are specific to the domain that you want to allow the reports from.

You will need to set up EDV under two conditions:

• You’re sending your DMARC reports to a different domain, or
• You’re not using a third-party DMARC reporting service.

You can add an EDV TXT record to a DNS server similar to creating a DMARC record. However, the record value and the name need to be specific.

The name of the EDV record needs to be as the following, where the [SendingDomainName] is the domain name of the report-sender, and the [ReceivingDomainName] is the domain name of the receiving server:

[SendingDomainName]._report._dmarc.[ReceivingDomainName]

The middle part “._report._dmarc.” will remain constant.

In the record value for the EDV, simply enter the following and save the record:

v=DMARC1

Conclusion

Understanding DMARC email authentication can be confusing. In this post, I have tried to explain the DMARC record, DMARC reporting, and DMARC alignment in the simplest way possible. After going through it, you should be able to understand DMARC lookups and even configure them if needed. Moreover, if you are experiencing issues with DMARC authentication and legitimate emails are not coming through, you can use this guide to enhance your knowledge base and configure SPF, DKIM, and DMARC records correctly.