SPF, DKIM, DMARC and BIMI on .fr: still on the rise in 2025

Adoption is still on the rise

Let’s start by comparing the adoption statistics for 2023, 2024 and 2025. First of all, let’s implement a slight change in methodology: instead of looking only at domains that publish at least one MX record at the domain apex, from now on we will look at all .fr domains. In fact, all domains are at risk of email spoofing, so it is important to set up defensive SPF and DMARC policies for domains that are not used to send emails. Furthermore, the absence of MX records does not means that a domain does not accept emails (only a “null MX”, as described in RFC 7505, can indicate this) and says nothing about its intention of sending emails.

For these reasons, we will henceforth be examining all domains, whether they have an MX record or not. This will give us a more accurate picture of the adoption of SPF, DKIM and DMARC across .fr.

As shown in the figure hereunder, there has been a considerable increase in the adoption of SPF, DKIM and DMARC between 2023 and 2025. SPF seems to have reached an inflection point, whereas DKIM has seen a slightly faster increase and DMARC also continues to increase.

Do DMARC policies change over time?

The usual advice for a new deployment of DMARC on a domain is to start by publishing a p=none DMARC policy with an address at which to receive automated reports (rua tag: rua = Reporting URL for Aggregate reports), to analyse each incoming report in detail and to make any necessary changes. Once the holder is sure that all genuine traffic is correctly authenticated, the policy can be changed from p=none to p=quarantine or p=reject.

But is this advice followed in practice? How have DMARC policies changed over the past two years?

Looked at broadly, the proportions of the p=none, p=quarantine and p=reject terms have changed considerably. From 2024 to 2025, the proportion of p=quarantine declined, while the others increased.

Table 1: Proportion of DMARC policy “p”-terms in .fr domains between 2023 and 2025

But how can the changes in these proportions be explained? The diagram hereunder gives a more detailed view of how all the DMARC policies applied to .fr domain names have evolved over time.

So we see that for two consecutive years, the increase in absolute numbers of p=quarantine and p=reject DMARC policies was due mainly to holders newly implementing DMARC and opting immediately for a more restrictive policy. There are very few year-on-year transfers from p=none to p=quarantine or p=reject. In other words, a p=none policy published in 2023 is very likely to still be p=none two years later.

BIMI

As a reminder, BIMI is a mechanism allowing an organisation’s logo to be displayed in DMARC-authenticated emails.

A slight increase that hides a trend

In 2024 we had established that 2,435 domains had implemented BIMI. In 2025 we counted 2,547 domains, representing an increase of 4.6%.

However, this growth rate hides another reality: nearly 40% of the BIMI implementations accounted for in 2024 were removed the following year. But this was largely offset by new implementations of BIMI by other domains, including some that did not exist in 2024.

In fact, BIMI removals were broken down as follows:

• 800 domains with BIMI that no longer existed in 2025;
• 89 domains that were transferred to “indeterminate state”, in other words domains for which it was no longer possible to determine with certainty whether or not BIMI had been adopted;
• 81 domains that deleted their BIMI records.

Against this are new implementations, broken down as follows:

• 523 domains that already existed in 2024 but which did not have BIMI last year;
• 163 domains that already existed in 2024 but that were in “indeterminate state”;
• and 396 new domains.

The figure hereunder shows a graphic representation of these changes.

Out of 2,547 domains, we gained direct access to 1,443 BIMI assertion records using the default selector (i.e. default._bimi.domain.example). We eliminated one record that had a syntactical error and three null assertions.

There are two types of BIMI assertion records: “certified” and “self-asserted”. For certified records, the URL of a logo is published and, in addition, that of a “Verified Mark Certificate” (VMC) or “Common Mark Certificate” proving rights to the trademark or logo and therefore the right to use it. For self-asserted records, only the URL of the logo is published, without its being associated with a certificate.

Of the 1,439 correctly implemented BIMI assertions that we examined, 1,312 (91.2%) were self-asserted and 127 (8.8%) were certified.

BIMI records in certified mode: 30% of configurations are incorrect

For the configuration in a BIMI record to be correct, merely pointing to a certificate’s URL is not enough. First of all the URL must work, and it must lead to an X.509 certificate. Next, the certificate must be issued by a trusted certificate authority, it must be explicitly intended to be used with BIMI and it must not have expired. Finally, the email must have been authenticated with a strict DMARC policy: p=quarantine without a pct tag, p=quarantine with pct=100 or p=reject.

Yet according to our analysis, 30% of the 127 domains publishing a certified BIMI assertion on the default selector were incorrectly configured. As a result, if messages from these domains use the BIMI default selector, there is a risk that compatible messaging services will refuse to include the logo indicated by the BIMI configuration.

We extracted 110 distinct URLs from the above-mentioned 127 BIMI assertion records. Our analysis showed that only 73 URLs led to a valid certificate, corresponding to 89 domains.

The configuration errors observed are wide-ranging:

• Expired BIMI certificates: 13 certificates (affecting 14 domains) pointed to a VMC which had expired upon retrieval. The time elapsed between expiry and retrieval varied between 12 and 960 days, with a median of 102 days;
• BIMI certificates issued by Entrust after 15 November 2024: a number of incidents involving the certificate authority Entrust has led various entities, such as Google, to remove Entrust from the list of trusted certificate authorities. Apple no longer recognises Entrust BIMI certificates issued from 15 November 2024. There are four such certificates, affecting four domains.
• Inadequate DMARC configuration: BIMI works only if the email has been authenticated by a strict DMARC policy. However, three domains published a p=none DMARC policy or no policy at all, thus rendering BIMI inoperative for at least some of the emails sent from the domain, unless the messages are sent from a sub-domain with a stricter DMARC configuration. These three domains correspond to three certificates.
• HTTP errors: in all, eight URLs were unreachable. Of these, five (concerning five domains) gave a 404 error and three (concerning three domains) gave a 403 error. This affected eight domains.
• Expired TLS certificates: in one case it was not the VMC itself that had expired but the certificate presented by the HTTPS server hosting it. Given that the VMC’s URL must necessarily be an https URL, this is a clear illustration of the fact that not one but two cryptographic certificates need to be monitored when deploying BIMI. This configuration error affected one domain.
• Well-formed X.509 certificates not valid for BIMI: the certificates used for BIMI must be in the format specified by recommendation ITU-T X.509, as must TLS (including HTTPS) certificates. In order for a certificate to be valid for BIMI, it must indicate that it is valid for this purpose: this means it must include an “X.509 v3 Extended Key Usage” extension listing the dedicated OID (Object IDentifier) for BIMI, 1.3.6.1.5.5.7.3.31. There are four certificates, concerning four domains, in this situation.
• URL not pointing to a certificate: some URLs pointed to something other than a certificate. In four cases (concerning four domains), the file retrieved was not an X.509 certificate: it contained a GPG public key, an image and two HTML pages. This concerned a total of four domains.

The following table summarises these findings.

Table 2: Summary of configuration errors detected in BIMI deployments with certified assertion records.

Maintaining a BIMI configuration in certified mode is no easy task, as shown by the sizable proportion of domains which, despite such configuration, have one or more problems that can lead to an email service provider refusing to display the logo despite the presence of a certificate.

Don’t forget to protect your parked domains!

A parked domain is a domain name that has been registered but is not actively connected to a website, email, or other online service. This may concern a domain name registered before the start of a project, defensive registration to prevent typosquatting, a domain put up for sale by its holder, etc. In any case, parked domains also require SPF and DMARC configuration to avoid being used as sending addresses by malicious third parties.

Here is an example of a phishing message that was brought to our attention last year:

From: Payment of rent <rentpaymentreceipt@[domain].fr>
To: [addressee]
Subject: Receipt

Hello,

Your November payment is not registered in our accounting file.

Please send us your payment receipt so that we can check and 
confirm your payment for the month. 
Have you received our new bank account details (RIB) 
for payment of November’s rent?

Contact email: [email address]

Kind regards,

Accounting Dept.

The sender’s address (RFC5322.From) spoofed a .fr domain unbeknownst to its holder. The envelope sender (RFC5321.MailFrom) however used a different domain from the first one and the message was not signed with DKIM. If DMARC had been configured on this domain, there would have been a simultaneous failure of SPF, due to the non-alignment of the envelope sender addresseand the header’s From address, and of DKIM, due to the lack of signature, and therefore DMARC would fail.

But the domain of the sender’s address (RFC5322.From) did not publish a DMARC policy, and this contributed to making this identity theft possible. It did publish a so-called “null” SPF policy (i.e. v=spf1 -all), but with no DMARC, the configuration of this domain, which has no reason to send emails, was incomplete. A simple p=reject DMARC policy would have made this phishing campaign less effective.

Could the holder have corrected this configuration? Its domain was parked on a resale platform. This platform requires its clients to change the name servers for the domain name; these servers are then configured to serve the same zone file for all the domains delegated to them. By parking the domain with them, the holder loses control of the corresponding zone’s contents and it is up the platform to configure it correctly. The holder was therefore unable to harden its parked domain against this risk.

In conclusion: review your portfolio of parked domains and check that there are defensive SPF and DMARC records. There is an example of a good defensive configuration in the Best Common Practices guide published by the M³AAWG.

And soon, DMARCbis

DMARCbis, the successor to DMARC, will soon be published. Currently a draft (with separate specifications for the format of aggregate and individual reports), this future RFC will be a Proposed Standard, as opposed to an Informational RFC, such as RFC 7489. The initiative aims in particular to integrate operational experience from numerous DMARC deployments and to correct certain details.

Among the main changes, DMARCbis specifies a different method for determining the organisational domain associated with the domain from which an email originates; it redefines the np tag, a late addition to DMARC specified in RFC 9091; the pct, rf and ri tags are deprecated and for sending reports, verification of external addressees, until now optional, becomes mandatory.

Organisational domain and public suffixes

First of all, what is an organisational domain? For DMARC, it is a domain that has been registered immediately under a public suffix. Sticking blindly to the last two components of the domain name can lead to errors: for example, for the address ne-pas-repondre@dgfip.finances.gouv.fr, the domain registered with Afnic is finances.gouv.fr, not gouv.fr.

The current algorithm works as follows: among the suffixes in the Public Suffix List, determine the longest one (in this case gouv.fr), then add a label to the right to get the organisational domain, finances.gouv.fr. There are some disadvantages to this method: a local copy of the Public Suffix List has to be kept up to date, since the list is subject to change.

As for DMARCbis, it breaks free entirely from the Public Suffix List and relies solely on the DNS and its tree graph model (the “DNS Tree Walk”). The procedure is as follows: first try to obtain a DMARC policy for the exact domain, dgfip.finances.gouv.fr. If there is none, try the parent domain (truncated, where necessary, to the seven labels furthest right so as to never make more than eight queries), then its parent, and so on up to and including the top-level domain, (like fr) or until a DMARC policy with a psd=y or psd=n tag (PSD=Public Suffix Domain) is found. There are then three possibilities: if a DMARC policy is found with psd=n, the organisational domain is the domain where this DMARC policy is. If a DMARC policy is found with psd=y, then it is a public suffix: the organisational domain is the domain one level below the suffix. If no DMARC policy has a psd=y or psd=n tag, we apply the DMARC policy found in the longest domain. The complete procedure can be found in section 4.10.2 of DMARCbis.

In short: rather than relying on a centralised list that has to be updated regularly, we determine the organisational domain by means of a new mechanism which allows public suffix administrators to declare themselves as such.

Deprecated tags

Next, the pct tag, which recommended applying a p=reject or p=quarantine term only to a certain percentage of incoming messages, is deprecated in favour of a new t (testing) tag with the value y or n, serving to indicate a deployment of DMARC in a testing phase.

An alternate use of the pct tag consisted in publishing a restrictive policy (p=quarantine or p=reject) with pct=0, which had the emerging effect of downgrading p=quarantine to p=none and p=reject to p=quarantine, thereby serving as a signal that testing was under way. Nor were the percentages always adhered to by the receiving systems and the only values that could be guaranteed to be followed exactly were 0 and 100.

Two other tags are deprecated: rf, which specifies the desired format of individual failure reports, and ri, the time interval between two aggregate reports, and will no longer be taken into account by recipients implementing DMARCbis.

Verification of external addressees

Another change concerns verification of external addressees. The idea is to avoid an ill-intentioned actor publishing a DMARC policy with the sole aim of flooding a third-party messaging service with unsolicited reports. Thus, if the domain arles.example publishes a DMARC policy with the term rua=dmarc@brest.example, brest.example will have to indicate that it agrees to receive the reports concerning arles.example: this is done by publishing a TXT record with the text v=DMARC1; at the domain name arles.example._report._dmarc.brest.example.

But according to RFC 7489, checking that this special record was present was not obligatory: it was a “SHOULD”. DMARCbis changes this “SHOULD” to “MUST”.

At present, this verification of external domains is far from systematically done by the leading messaging services providers, as demonstrated by Hureau et al., 2024. However, the implementation of DMARCbis could lead to a change in this situation.

Conclusion

There is still some way to go before all .fr domain names are covered. But the fact is that today the ability of SPF, DKIM and DMARC to make email spoofing more difficult is sufficiently recognised for more and more email service providers to require sending domains to adopt these three mechanisms. With DMARCbis addressing some of the drawbacks of the current DMARC and consolidating ten years of operational experience, it is to be expected that SPF, DKIM and DMARC will become a requisite for emails to have a chance of being accepted, as was the case with other measures aimed at combating spam.

Adoption of BIMI remains small and limited to corporations that have the financial resources and the willingness to invest money in the necessary certificates for a full setup. Nonetheless, given the price of these certificates, it is surprising to see the substantial proportion of certified-mode BIMI deployments that run the risk of not having the logos displayed.

As for DMARCbis, some measures would be worth taking now so as to be ready when the RFC is published:

• For registries: if it is possible, or has been possible in the past, to register a domain name in a second-level suffix, such as asso.fr or co.uk, a DMARC record associated with these suffixes with the term psd=y would be advisable.
• For administrators of domains under a second-level suffix, adding a psd=n term to the DMARC policy associated with the domain name is recommended in order to prevent a DMARC policy from higher up in the tree structure being applied.
• For all existing DMARC policies, removal of the rf, ri and pct terms should be considered, as they will no longer be taken into account by DMARCbis implementations.
• As for the leading consumer email service providers, there are perhaps users who receive DMARC reports at an own address. For example, it is fairly common to see DMARC policies that designate a Gmail address for the receipt of reports. But the node _report._dmarc.gmail.com does not exist in the DNS, so any DMARCbis compliant messaging service would systematically refuse to send the report to a Gmail address. In this case, there are two options: either the domain administrator designates a different address, or Google has to publish a TXT record v=DMARC1; at the wildcard name *._report._dmarc.gmail.com.

Lastly, don’t forget that Afnic offers training on SPF, DKIM and DMARC intended for IT professionals and domain holders. While waiting for the next session, you can also explore the other resources that Afnic makes available on the same subject:

• the Zonemaster tool, which includes a test of the syntax of SPF policies;
• a presentation and an on-stage demonstration of SPF, DKIM and DMARC at the Afnic Scientific Council (JCSA) Open Day in 2023, the video of which is available here;
• and the source code of the SPF, DKIM and DMARC tutorial used in this on-stage demonstration.