Deploy DMARC on your domain name!

Today, I propose to talk about DMARC. The goal is to help you - if you haven't yet taken the plunge - to better protect your domain names with DMARC, and the icing on the cake is an ultimate article on deploying BIMI if and only if you deploy a restrictive policy on DMARC!

On this first DMARC article of 2021, I'm going to update an old article I wrote in 2017 about DMARC implementation by going into a little more detail about its setup with all the options available! With that, you should be fine... If not, call on us :p).

Hey Sebastien... What is DMARC and what is it for?

Behind the acronym "DMARC" (Domain-based Message Authentication, Reporting and Conformance) is an authentication standard that will allow you to strengthen the security of your domain name.

The use of DMARC is threefold:

• Enforce SPF & DKIM limitations by applying a fail-safe rule.
• Limit spam and phishing on your sending domain and all its sub-domains through reports provided by some organizations.
• Make your e-mail flows compliant in order to improve their legitimacy.

Even if DMARC is not mandatory for the moment, it is still strongly advised to implement it... Your reputation may depend on it !!!

Okay! Can you tell me how it works and what I need to do to deploy DMARC?

DMARC will allow any organization that knows how to check and interpret it to apply a security policy that is previously defined in a TXT record of the sending domain (we are talking about the "From" domain).

This security policy is implemented in three ways:

• The "none" policy: no action will be taken on the e-mail in case of failure.
• The "quarantine" policy: the e-mail will be delivered as spam if it fails.
• The "reject" policy: the e-mail will be rejected if it fails.

To be functional, DMARC relies on two authentication systems which are SPF (Sender Policy Framework) and DKIM (DomainKey Identified Mail). If both fail when receiving an e-mail, the policy defined upstream will be applied.

To implement DMARC, you need:

• Have a valid SPF registration.
• Have a valid DKIM record.
• Have write access to the sending domain (either you, your IT department, or the hosting company that manages your domain)

If you meet all the criteria, all you have to do is create a TXT record (our famous catch-all record where SPF/DKIM will be stored) and insert a DMARC record! How simple is that?

Coooool! But can you give us a concrete example???

A quick aside on the logic of DMARC implementation. It is important to place it directly on the main domain so that the whole domain infrastructure (and its subdomains) is protected and compliant with DMARC. It would be a mistake to think that your main domain doesn't need DMARC because it doesn't send emails... A vulnerable domain is a godsend for any hacker and if it were to be listed on major block lists, your subdomains would pay a high price!

Now let's go to our three examples. You should know that DMARC has mandatory and optional tags... If a tag is not declared, it will automatically take the default value.

To show you these details, we will use some online tools like Dmarcian, Mxtoolbox, Dmarcanalyser. Feel free to do this little check to see if DMARC is already implemented or not:

Example n°1 :

Dmarcian tells us that DMARC is valid! We can also see that we have set a security policy to "quarantine" (p=quarantine) and that we are using the 250ok module to receive/monitor DMARC reports.

Example n°2 :

Mxtoolbox tells us that DMARC is valid! Here, we can see that Hermes applies a "reject" security policy (very restrictive) on its main domain. It uses the Proofpoint solution to receive/monitor DMARC reports.

Example n°3 :

Dmarcanalyzer tells us that DMARC has errors (*), hence the usefulness of checking its registration once implemented! Here we can see that Voyage Privé does not apply a security policy but only monitors the data in the reports (if they really do...).

* 3 errors: the first one, the tag "p" must be placed in 2^ème (cf. read the following paragraph) and the second one is about the declared addresses, they contain a space... The third one is the use of an external domain in the e-mail address, to be able to receive all the DMARC reports, it will be necessary to ask Google to make a modification on its "gmail.com" domain... Not sure that it will succeed !

You can see that from one configuration to another, the content of DMARC is totally different!

Uh... That's Chinese for you... Can you tell me the content of each DMARC record?

If you are not familiar with DMARC, it can be difficult to understand. More than analyzing the tags of the three records seen in the previous paragraph, I suggest you to list and detail all the options / values available for DMARC knowing that some are mandatory and others optional...

Mandatory elements

Two tags are mandatory and must be declared first, they are :

• "v": you declare here the version of DMARC... Don't panic, there is only one!

v=dmarc1;

• "p": here you declare the security policy that will be applied to the domain where DMARC is implemented. Three possible values : " none ", " quarantine ", " reject ".

p=none; or p=quarantine; or p=reject;

Two important points: don't forget to add the ";" after each value and above all no space should be put before or after the value.

Optional elements

• "sp": here you declare the security policy that will be applied to all subdomains of the domain where DMARC is implemented. Three possible values: "none", "quarantine", "reject". If the tag is not declared, all subdomains will automatically inherit the value declared in the "p" tag. This field is useful if you want to have a different policy between the main domain and the subdomains.

sp=none; or sp=quarantine; or sp=reject;

• "pct": here you declare the percentage of emails where the security policy will be applied (between 0 and 100). The default value is 100.

pct=50;

On this example, 5°% of the emails will be filtered if DMARC has a restrictive security policy.

• "rua": here you declare the email address that will receive the aggregated reports sent by the organizations. You can define a maximum file size by adding it at the end of your e-mail address.

rua=mailto:youremailaddress; or rua=mailto:youremailaddress!50m "

Two important points: use an e-mail address from your main domain or from a monitoring solution because you will have to authorize the domain of the chosen address to receive DMARC reports. If this is not the case, you will only receive a part of the reports.

Sizes are defined in "k" (kilobyte), "m" (megabyte), "g" (gigabyte), "t" (tetrabyte).

• "ruf": here you declare the email address that will receive failure reports (understand here sample emails) sent by some organizations.

ruf=mailto:youremailaddress;

Two important points also here, the same as for the "rua" address!

• "aspf": here you declare the type of SPF alignment you want. Two possible values: "r" for relaxed (see soft configuration), "s" for strict (strict configuration). If the tag is not declared, the default value will be " r ".

aspf=r; or aspf=s;

With a flexible configuration, the the Mailfrom address or Return-path can be a sub-domain of the From domain (see sender). Example : Mailfrom = em.badsender.com & From = badsender.com

With a strict configuration, the domain (or sub-domain) of the Mailfrom (or Return-path) address must be identical to the From domain (see sender). Example : Mailfrom = badsender.com & From = badsender.com

• "adkim": here you declare the type of DKIM alignment you want. Two possible values: "r" for relaxed (see soft configuration), "s" for strict (strict configuration). If the tag is not declared, the default value will be "r".

adkim=r; or adkim=s;

With a flexible configuration, the domain declared in the DKIM signature can be a domain or subdomain of the From domain (see Sender).

Example : DKIM > d=em.badsender.com & From = badsender.com

With a strict configuration, the domain declared in the DKIM signature must be the same as the From domain (see sender).

Example : DKIM > d=badsender.com & From = badsender.com

• "rf": here you declare the format of the failure reports you will receive. There is only one value available at the moment, the "afrf" format (see the e-mail you will receive in the attachment).

rf=afrf;

• "ri": here you declare the number of seconds that will elapse between sending aggregate reports. If the item is not declared, its default value is 86,400 seconds - or one day.

ri=86400;

• "fo": here you declare what type of aggregate reports you want to receive. Four values are available: "0" to receive SPF and DKIM failure reports, "1" to receive SPF and/or DKIM failure reports, "d" to receive DKIM failure reports, "s" to receive SPF failure reports. If the element is not declared, the default value is "0".

fo=0; or fo=1; or fo=d; or fo=s;

Ah great! And so with such a configuration, no more phishing?

Well, unfortunately not! Even if DMARC was created to limit spam and identity theft, it will not guarantee you an efficient protection to 100% and this for two reasons:

• Not all organizations (ISPs/Webmails, Enterprises, ...) know how to interpret DMARC, which implies that the security policy will not be applied.
• To be effective, the security policy should be as high as possible (see reject) with strict SPF/DKIM alignments.

Finish... We digest now!

With this "updated" article, you won't have any excuse to miss DMARC!

Next issue: we're going to analyze a DMARC report from Google! The kiff 🙂

- - - - -

Need help deploying DMARC? We're here to help 

- - - - -

Feel free to share, like, comment... In short, make some noise !!!!!

- - - - -

Badsender, emailing expertise agitator! Badsender is a team of craftsmen specialized in the various disciplines surrounding email marketing! Our emailing agency intervenes on questions of strategy, design, orchestration and deliverability. We offer this expertise in the form of coachingWe can also provide services such as audits, or act as an outsourced production force. 

- - - - -

Some articles with a common interest with this one:

SPF:

• What is SPF? Configuration, verification and monitoring.
• 10 tips to implement in your SPF configuration...
• How about switching your SPF record to the "-all" qualifier?!

DKIM:

• What is DKIM? Configuration, verification and monitoring.

DMARC:

• Badsender publishes a white paper to help you in your DMARC deployment!
• Monitoring DMARC Badsender.com - December 2020
• DMARC Monitoring Badsender.com - October vs. November 2020
• Email deliverability: Implement DMARC to protect your domains!

- - - - -

Photo by akyurt device on Unsplash