Close this search box.

5 tips for managing DMARC

Since the adverts and requirements from Google & Yahoo, having a DMARC record has become a basic requirement and can quickly lead to deliverability issues if it's badly managed! In this article, I'll give you 5 tips on how to manage your DMARC registration on your domains so that it doesn't have a negative impact on the delivery of your emails.

Tip #01: Deploy your DMARC registration!

To manage DMARC properly, the first thing to do is to have a DMARC record present directly or indirectly on all your domains, for three good reasons!

  • The first good reason Google and Yahoo require each sender domain to have a DMARC record (for the moment, only for mass senders ' + 5000 emails/day on the root domain including all its sub-domains);
  • The second good reason DMARC provides advertisers with activity reports for their domain name (a root domain and its sub-domains);
  • The third good reason DMARC gives you the option of combating phishing by indicating what to do with an email that doesn't comply with DMARC (cf. invalid or unaligned SPF and DKIM records), i.e. either put it in junk mail or reject it!

' Example of a DMARC record identified on the domain with the Dmarcian :

' Example of an unidentified DMARC record on the domain with the Dmarcian :

Tip #02: Correctly declare your DMARC registration!

There aren't 50 ways to declare a DMARC registration on your domain name! However, there are a few rules to follow to ensure that the registration is valid:

  • DMARC declares itself in a TXT DNS record ;
  • DMARC declares itself on the host name (or zone or subdomain) _dmarc of the domain (or sub-domain);
  • Onlya single DMARC record per domain ;
  • The safety policy must be written in lower case to avoid any ambiguity;
  • Tags v (for version) and p (for the security policy) are mandatory and must be in this order;

This is a non-exhaustive list of the problems I have encountered during my audits. The DMARC official website lists many more DMARC declaration errors.

' Example of a valid declaration for a DMARC record :

' Example of an invalid declaration for a DMARC record :

Tip #03: Define your DMARC security policy!

The DMARC security policy tells remote servers (which are capable of interpreting these policies) what to do in the event of a non-compliant email. To date, there are only THREE possible values that will apply to the domain where DMARC will be implemented (p=) or to all its sub-domains (sp=):

  • La policy none (or p=none) : No processing of the non-compliant email will be done, the email may be delivered to inbox or spam.
  • La policy quarantine (or p=quarantine) : The non-compliant email will be delivered as junk mail.
  • La policy reject (p=reject): The non-compliant email will not be delivered and a bounce will be sent to the sender.

Any other policy declaration will lead to different behavior on the part of ISPs / Webmails:

  • Gmail : Transform existing value by none (dmarc=pass p=NONE sp=NONE) ;
  • Microsoft: Output as result a permanent error (dmarc=permerror) ;
  • Yahoo : Produces a result unknown (dmarc=unknown) ;
  • La Poste: Ignore recording (dmarc=none reason="No policy found ").

' Example of a valid security policy for a DMARC record :

' Example of an invalid security policy for a DMARC record :

A word of warning about BtoB domains: I've already noticed that some domains were very strict and refused any email (with a well-defined bounce) with an invalid DMARC record!

Tip #04: Define your RUA attribute!

Having DMARC is great... with a restrictive security policy is even better! But the icing on the cake would be to monitor authentication reports sent by any organization supporting DMARC. To do this, you'll need to declare a RUA attribute (Reporting URI for Aggregate data) and an email address (not forgetting the mailto) which will allow you to receive all the aggregated reports from your sender domain.

' Example of a valid RUA declaration belonging to the domain :

' Example of an invalid RUA declaration belonging to the domain :

However, I would like to warn you about the use of the e-mail address that will receive the DMARC reports. If you are using a domain external to the sending domain, the latter must set up a special DMARC record (cf. trusted) which will enable it to receive all authentication reports for a sending domain. Without this setting, the number of reports received will be very limited, if not zero.
In the example below, Google does not fully authorize (nor does it like) the reception of DMARC reports with a address, which will have the effect of severely limiting the reception of reports in your Gmail mailbox...

Tip #05: Use a tool to monitor your reports!

If you're planning to monitor your DMARC reports (it's so cool), you'll need to get equipped! DMARC reports are in XML format and can therefore be very complicated to read / decipher, as they contain thousands of lines. Using a platform will enable you to read your reports easily and see if you have any problems with authentication or fraudulent or malicious use!

Here's a non-exhaustive list of tools currently available on the market:

Redsfit OndmarcDmarcianDmarc AdvisorPower DmarcEverest
Easy DmarcDmarc AnalyserDmarc.frUri PortsDmarc Eye
MeroxDmarc DigestsDmarclyPostmark DmarcEmailConsul
ValimailGlock AppsMailer Check

On the other hand, they all have very different prices and options. Depending on the advertiser's needs.


With its 5 Tips, you can easily set up DMARC without any undesirable effect on the delivery of your emails.
However, if you are unable to follow these feeds, don't hesitate to use our services 🙂

In a forthcoming article on DMARC, I'll talk about the different deployment strategies to be implemented depending on your domains (and sub-domains), but also the security policies to be applied. In short, quite a program 🙂

You can find below our various articles dedicated to email authentication:

The author

Laisser un commentaire

Your email address will not be published. Les champs obligatoires sont indiqués avec *