Aller au contenu Aller au menu principal Aller au menu secondaire Aller au pied de page

SPF, DKIM and DMARC: what’s the situation with the .fr TLD?

Home > Observatory and resources > Expert papers > SPF, DKIM and DMARC: what’s the situation with the .fr TLD?
03/21/2023

Email is one of the oldest internet applications. It was conceived at a time when the internet was not yet a public network. Cases of identity theft using email are currently proliferating, since it is possible to fill in any address at all in the “From” section of the email, and this facilitates various kinds of abuse such as phishing. There are now solutions for plugging this gap, and they should be adopted in order to bolster confidence in email.

Three mechanisms, all using the DNS, have been developed for this purpose: SPF, DKIM and DMARC. Together, they protect the holder of a domain name against emails purporting to come from them. And they also make it easier for recipients to detect instances of attempted identity theft. But this protection is not automatic; all users or email service operators have to configure SPF, DKIM and DMARC on their own initiative in order to protect themselves.

This study aims to measure among other things the use of SPF, DKIM and DMARC in the .fr zone and the quality of the DNS configurations for emailing. Here are some of the results.

A few key figures

The study involved 4,029,741 domains extracted from the .fr zone on the night of 30 to 31 January 2023. Of these 4 million, 3,600,347 are published; 3,096,240 of them publish an MX record.

Distribution of domain names by use of SPF DKIM and DMARC

We found that, among the domains publishing MX records:
• 57.8% publish an SPF policy;
• 23.1% publish at least one DKIM key;
• 7.8% publish a DMARC policy.
Looking only at domains associated with a website, we find slightly higher rates of deployment:
• 62.7% for SPF;
• 25.2% for DKIM;
• 9.8% for DMARC.

Fewer than 10% of the domain names published in the .fr zone currently make full use of the DNS to ensure the authenticity of their outgoing emails.

SPF

Among the SPF policies deployed in the .fr zone, we detect very few technical configuration problems. We have compiled a few good practices and tested their proper implementation. Of the 1,891,368 domains publishing an SPF policy, we observe that:

  • 97,74% have a sufficiently restrictive SPF policy (with no “+all” endings to records and no excessively large IP ranges);
  • 98,69% have migrated from the SPF type DNS record, use of which is now deprecated, to the TXT type record;
  • 98,94% make no use of the “PTR” mechanism, use of which is also deprecated;
  • 99,16% make sure they have precisely a TXT record containing an SPF policy;
  • 99,61% do not list IP addresses that are private or reserved (non-routable on the internet);
  • 99,74% have a set of TXT records that fits within a DNS message of fewer than 512 bytes (beyond that, performance deteriorates);
  • 99,83% publish an SPF policy free of syntactical error;
  • 99,995% publish an SPF policy that can be evaluated without exceeding the limit of 10 DNS queries imposed by RFC 7208 (without counting the sub-policies included by the “include” mechanism and the “redirect” modifier).

At least 97% of .fr domain names have an SPF policy in accordance with good practices.

We then studied the 20 most frequent SPF policies.

These “top 20” include 17 policies associated with entities of various categories: web host companies or registrars that install them by default, web agencies and email service providers.

We also noted that a domain which publishes an SPF policy identifying an email service provider or a web agency is very likely to have developed a website.

We then listed the 20 sub-policies most often included in SPF policies, as shown in the table hereunder.

Ranking

Name included

Body

Category

1 mx.ovh.com OVH Web hosts, registrar
2 _mailcust.gandi.net Gandi Web hosts, registrar
3 spf.protection.outlook.com Microsoft (Office 365) Collaborative suite
4 spf.jabatus.fr O2Switch Web hosts, registrar
5 _spf.google.com Google Domains Collaborative suite, registrar
6 spf.mailjet.com Mailjet Email service provider
7 spf.webapps.net Register.it Web hosts, registrar
8 spf.infomaniak.ch Infomaniak Web hosts, registrar
9 _spf.mail.hostinger.com Hostinger Web hosts, registrar
10 spf.mandrillapp.com Mailchimp Email service provider
11 wanadoo.fr Orange Business Web hosts, registrar
12 sendgrid.net Sendgrid Email service provider
13 spf.sendinblue.com Sendinblue Email service provider
14 emailsrvr.com Rackspace Mail Web hosts
15 _spf.kundenserver.de Ionos Web hosts, registrar
16 _spf.perfora.net Ionos Web hosts, registrar
17 spf.webmo.fr Magic Online Web hosts, registrar
18 _spf.alwaysdata.com AlwaysData Web hosts, registrar
19 _spf-optimail.linkeo.com Linkeo Web agency
20 spf.viaduc.fr Viaduc Web agency, registrar

DKIM

DKIM is much less widespread than SPF: 23.1% of domains in the .fr zone publish at least one DKIM key in the root zone of the domain.

We note that 60.8% of the domains that have deployed DKIM have a website.

The analysis of the DKIM selectors most used and the characteristics of the public DKIM keys is under way and will be the subject of a dedicated publication.

DMARC

DMARC remains little used in the .fr zone: only 7.8% of domains publish a DMARC policy.

We attempted to gauge the quality of configuration by analysing the distribution of the terms “p=reject”, “p=quarantine” and “p=none” in the DMARC policies. Among the domains publishing a DMARC policy, we observe that:

  • 73,6% publish a “p=none” policy: consequently the receiving email servers do not reject messages that seem to be attempts at identity theft;
  • 18,5% publish a “p=reject” policy, so attempts at identity theft are rejected;
  • 7,9% publish a “p=quarantine” policy: in this case, attempts at identity theft are tagged as spam and then forwarded to the domain holder for review.

Among domains with a website, these percentages are: 81.6%, 11.3% and 7.0% respectively. In contrast, among domains with no website, the “p=reject” policy is over-represented, without however being the majority: these are mainly parked or defensively registered domain names.

p terms by website presence

There are several reasons that explain the low rate of strict configuration of DMARC:

  • In order to deploy DMARC, one must first have deployed SPF and DKIM (unless the domain declares that it has never sent any emails, in which case there is no need for DKIM);
  • Recipients’ configuration errors can cause emails to fail DMARC validation for SPF or DKIM alignment and thus cause delivery problems for sender domains with strict DMARC policies;
  • Certain mailing list systems relay emails without taking account of the problems introduced by SPF and DKIM, and this also produces false positives;
  • lastly, in general, configuration errors of the sender as well as the recipient can lead to emails being lost. It is precisely the domain name holders that have a website (and therefore a developed online presence making deliverability all the more important) who are most reluctant to tighten their DMARC configurations.

The viability of a strict DMARC policy depends on a large number of actors with varying degrees of competence and responsiveness as regards evolving standards. Consequently, a strict DMARC configuration (p=reject) increases the risk of authentic emails being rejected by recipients’ email systems.

Only a small proportion of the .fr zone is protected against identity theft by email

The proportion of .fr domain names protected against identity theft is very small: only 48,421, or 1.3% of the entire .fr zone publish a “p=reject” DMARC policy. And yet identity can have serious consequences, both for internet users, who are exposed to phishing, and for the brand image of the holder/sender of the email.

Afnic offers a dedicated training course on these three protocols, SPF, DKIM and DMARC, to enable you to configure an email policy that ensures the authenticity and deliverability of your email communications via the DNS. The next session will take place on 20 and 21 April 2023; don’t wait any longer to protect your online presence from malicious actors!