DMARC records explained

  • Published : March 25, 2024
  • Last Updated : May 3, 2024
  • 505 Views
  • 10 Min Read

Email authentication mechanisms are in place to protect the emails you send. This ensures that the sender’s identity and the email's contents are protected. However, it doesn't end with implementing these mechanisms. The next step in fully protecting emails is to list the course of action if they fail the authentication check at the receiving end. Without a proper feedback channel to tell senders about how authentication policies have been implemented, there will be no room to improve their authentication mechanisms.

Even if the sender and receiver were to privately interact about the implemented methods, it would eventually prove to be tedious because they require manual coordination between them. This conundrum is solved by Domain-based Message Authentication, Reporting and Conformance (DMARC).

DMARC is helpful in implementing authentication mechanisms and providing feedback to the sender about the how well SPF and DKIM policies are implemented. DMARC works along with the Sender Policy Framework (SPF) and Domain Keys Identified Mail (DKIM) to give a well-rounded protection to emails.

DMARC does the following things:

  • It shows the action to be implemented on emails that fail authentication.

  • It provides feedback to senders so that they can monitor authentication and judge the threats.

 

What is DMARC?

DMARC is a policy with which the receiving servers can decide what to do with the emails that fail SPF and DKIM checks. The action to be taken, of course, will be published by the sender in their domain's DNS.

DMARC helps tackle spoofing and phishing emails by comparing the domain in the sender's from address with the domain authenticated by SPF and DKIM. This method is called domain alignment. Any mismatches found will be handled using the instructions specified in the DMARC policy.

How does DMARC work?

To understand the concept of DMARC, you should be familiar with three concepts. They are:

  • SPF

  • DKIM

  • Identifier alignment

SPF

SPF lists all of the allowed IPs, domains, and servers eligible to send emails on your behalf. As a domain owner, you’ll be publishing this list in your DNS server. When the receiving server intercepts your email, it will obtain your domain's details from the return-path address from the email's header. Using this information, the recipient server will find the SPF records published in your domain's DNS server and compare them with the sending domain. If the values match, it is an SPF pass. If they don’t match, it is considered a fail.

DKIM

SPF authenticates the sender, while DKIM ensures that the email's content hasn't been tampered with. To do this, the sender converts the message into a hash value called a DKIM signature. This signature will contain the sending domain's information apart from the hash value. The signature is then encrypted using a private key, which will be available to the sender. 

This encrypted value will be sent along with the email. In addition to this value, the sender should publish a public key in their domain's DNS server. On the recipient’s side, the receiving server will obtain the public key, create their own hash value using the data available in the DKIM signature, and encrypt it. Next, it will decrypt the hash value sent along with the message. The receiver's encrypted value and the decrypted sender's value will be compared. If they match, it’s a DKIM pass.

Identifier alignment

Email authentication methods authenticate various sections of an email message. DKIM verifies the email content, while SPF authenticates the return path's domain. DMARC also authenticates the return path or the MAIL FROM domain, and requires it to be aligned with the authenticated identifier. The authenticated identifier refers to the domain that SPF and DKIM validate.

If the return path value matches this authenticated identifier, the values are said to be in alignment.

SPF identifier alignment 

The SPF alignment can occur in two modes: relaxed and strict.

This authenticates the MAIL FROM domain and the mail sending domain. The MAIL FROM domain is the domain specified in the return path address, and the mail sending domain is the domain obtained from the FROM address. The strict mode expects the domains to match exactly. For example, if the MAIL FROM domain is example.com and the sending domain is invoice.example.com, the strict mode will be a fail.

On the other hand, the relaxed mode doesn’t look for an exact match. Even a subdomain match will be allowed.

DKIM alignment 

DKIM alignment compares the domain in the "d=" tag with the MAIL FROM domain. DKIM also has two modes: strict and relaxed.

Similar to SPF alignment, the strict mode looks for an exact match between the domains, while the relaxed mode accepts a subdomain match too.

DMARC record

The domain owners publish the DMARC preference as a TXT record under the subdomain "_dmarc". For example, the DMARC record will be "_dmarc.example.com". So the receiver will issue a TXT query to the DNS for the subdomain.

The DMARC record will look like this:

 v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-reports@domain.com;

Here's a look at each of the tags in this record.

 V=DMARC1  

This tag gives the version of the record. This is a mandatory tag, so if this isn't available, DMARC verification will not be executed.

 P=reject 

The p tag tells the receiver what action is to be taken. In the above example, the tag is set to reject. This means that all of the emails that don’t pass the SPF and DKIM alignment will be rejected.

There are three values that the p tag takes:

  • None: The email will be accepted, but no action will be taken by the receiving server.
  • Quarantine: The domain owner wants the receiving server to mark emails that fail the DMARC check as suspicious. The email will still be accepted into the receiving server. But it will be sent to either the spam folder or a quarantine mailbox, where the admin will review whether it has to be sent to the spam folder or the inbox.
  • Reject: All of the emails that don’t clear DMARC verification will be rejected.

 Pct=100 (optional) 

Pct takes a value between 0 and 100. This refers to the percentage of emails to which the DMARC policy is to be applied. The purpose of this is to enable a gradual rollout of the DMARC policy. In the example given, pct is set to 100, which means that the DMARC policy is applied to all of the messages.

 Rua=mailto: dmarc-reports@domain.com; 

The rua is the address to which the DMARC aggregate reports should be sent. DMARC reports contain information on all of the emails that have been SPF and DKIM authenticated and which haven't. It’s a general report that contains information on the p, pct, and other tags specified in the policy along with the SPF and DKIM authentication results. These are not real-time results, but they’re sent everyday. It’s advised to have a dedicated email address to receive the email reports. You should mention the rua tag to receive the aggregate report.

The v tag and p tag are mandatory and should be present.

Once the SPF, DKIM, and DMARC values are published by the sender, the check occurs in the following manner:

  • The sender creates the message and sends it out.

  • The submission agent (MSA) sends it to the DKIM module for the email to be signed. This will be signed by the DKIM signer.

  • Once signed, the email will then be transferred to the recipient server by the Mail transfer agent (MTA).

  • On the recipient side, the Mail delivery agent conducts the SPF and DKIM checks by looking up the sender's DNS server.

  • The results are then sent to the DMARC module, where it will try to retrieve the policy from the sending domain's DNS server.

  • If the policy is found, along with the SPF and DKIM results, the DMARC policy will be executed.

  • The Mail transfer agent will deliver the message to the recipient.

  • The report corresponding to the message will also be sent to the sender.

 

How to implement DMARC?

To implement the DMARC policy, follow these steps:

  • Check if the SPF and DKIM records are configured to verify the sending domain.

  • Select an email address that will receive the DMARC feedback reports. This will help identify the issues with your authentication methods and resolve them.

  • Generate the DMARC.

  • Upload the generated record to your domain's DNS server.

 SPF and DKIM configuration

SPF and DKIM alignment is necessary for the implementation of DMARC. DMARC fails if SPF or DKIM fail, so it’s important to configure both.

If you’ve set up SPF, check if the following elements match:

  • FROM address: The address from which emails are sent.
  • Return path address: The address to which emails will be directed if the recipient address isn't reachable or available.

If you have set up DKIM, check for the following:

  • FROM address: The address from which emails are sent.
  • d tag: Mentions the domain where the DKIM lookup should occur.

  Choose an email address to receive emails

Once your DMARC policy is in place, you’ll start receiving reports immediately. These reports will be in XML format, which can be quite tricky and complex. However, there are several online tools like Dmarcian that can help you easily convert them.

  Generate DMARC

Finally, you can generate the DMARC record with the help of these online tools.

  Upload the record to DNS

Once you generate your record, you should upload it to your DNS server. DMARC is a TXT record and the steps for uploading the record varies for each hosting provider.

Once you upload your records and all of the data are correct, you’ll start receiving emails in 24 hours.  

  DMARC rollout

Once the DMARC policy is in place, the next step is its implementation. The two tags that help you with this are the p and pct tags. They allow you to limit the number of emails to which you apply DMARC and the action taken on them.

Initially, you can have your p tag set at none. This helps you get feedback on how your emails are faring without sending them to spam or rejecting them.

The next value you can assign to your tag is quarantine. Quarantine tells the receiving server to mark emails that don’t comply with the SPF and DKIM validation as suspicious and send them to the spam folder. Some clients offer a quarantine mailbox, which will hold the quarantined emails. The admin can review and decide the necessary course of action. You can start quarantine on a small portion of your emails.

For example, you can set your DMARC record as:

v=DMARC1; p=quarantine; pct=5; rua=mailto:abc@domain.com;

In this example, DMARC is applied to only 5% of your emails. Small organizations can choose to quarantine a larger portion of their emails. Large organizations can opt for a smaller number because they have multiple email channels.

Once you confirm that all of the emails you send out from your domain are authenticated, you can enforce a stricter policy. You can do this by having the policy set at p=reject for 100% of your emails.

If you’re focused on improving your brand identity and adopting BIMI, you must adopt p=reject.

A phased rollout helps your enforce DMARC policy to your emails.

  Additional DMARC tags

The tags mentioned in this example are the most commonly used ones. Apart from them, there are other tags that can be included in the DMARC tag. They are listed in the table below.

Tag

Description

adkim 

Default: r

Specifies the DKIM identifier alignment mode. It can take either of two values:

r for relaxed

s for strict

(Optional)

aspf 

Default: r

Specifies the SPF identifier alignment mode. It can take either of two values:

r for relaxed

s for strict

(Optional)

ruf

Used to specify the address to receive the failure/forensic reports. Failure reports are sent immediately after an email authentication failure occurs. You should specify this tag to receive the failure reports.

f

Used to specify the failure or forensic report options. This can be ignored if ruf is not mentioned. It can take four values:

0: Generate a DMARC failure/forensic report if both SPF and DKIM fail to produce an alignment pass.

1: Generate a DMARC failure/forensic report if either SPF or DKIM produces a result other than aligned pass.

d: Generate a DKIM failure report if the email's DKIM signature fails validation, irrespective of its alignment.

s: Generate a SPF failure report if the email fails SPF evaluation, irrespective of the alignment.

sp

Specifies the policy for all sub-domains. It takes the same value as the p tag. If sp is not mentioned, the value of p will be considered for the sub-domains.

(Optional)

rf

Default: afrf

Specifies the format to be used while generating reports for SPF and DKIM fails.

The values mentioned in the format should be along the lines defined here.

(Optional)

ri

(Optional)

Specifies the time interval (in seconds) between aggregate reports that are sent daily.

Default: 86400

DMARC and deliverability

DMARC helps you analyze how the SPF and DKIM mechanisms have fared and can change your authentication practices accordingly. DMARC, along with SPF and DKIM, ensures that your domain isn’t used by bad actors to send phishing emails or spams.

By ensuring that your domain isn't misused, they help create a good reputation for your domain. Emails from domains with a good reputation will have good deliverability. DMARC's aggregate reports help you modify and adapt your authentication practices to keep this deliverability in check.

Wrapping up

Implementing these authentication methods is easy and gives your emails the security they need. With spammers and spoofers searching for ways to impersonate your identity, it becomes a necessity to safeguard your emails. DMARC gives you the flexibility to start out with a "none" policy. This way, you’ll know how your emails are performing without actually losing them. So even if someone tries to spoof your customers, you’ll still be able to close the gaps and make your emails iron-clad.

Leave a Reply

Your email address will not be published. Required fields are marked

By submitting this form, you agree to the processing of personal data according to our Privacy Policy.

You may also like