Un enregistrement SPF suffit-il ?

Non. SPF ne vérifie que l’expéditeur technique (Return-Path) et échoue souvent en cas de transfert. Seul DMARC protège l’adresse d’expéditeur visible, et les grands fournisseurs de messagerie exigent SPF, DKIM et DMARC de la part des expéditeurs en masse.

Que se passe-t-il au-delà de 10 requêtes DNS dans l’enregistrement SPF ?

Le destinataire interrompt la vérification avec le résultat permerror. SPF est alors considéré comme non réussi, ce qui peut dégrader la délivrabilité et le résultat DMARC.

Faut-il utiliser -all ou ~all ?

Dès que tous les expéditeurs légitimes figurent dans l’enregistrement, -all est le choix le plus clair. ~all convient à la phase de transition ; la véritable protection contre l’usurpation est assurée par DMARC avec quarantine ou reject.

En combien de temps puis-je passer à p=reject ?

Prévoyez plusieurs semaines. Restez sur p=none jusqu’à ce que les rapports montrent que tous vos services d’envoi réussissent SPF ou DKIM et sont alignés, puis durcissez progressivement la politique.

Configurer SPF, DKIM et DMARC : guide avec exemples

Pourquoi l’authentification des e-mails est aujourd’hui indispensable

Le protocole de messagerie SMTP permet en principe à n’importe qui d’indiquer une adresse d’expéditeur quelconque. SPF, DKIM et DMARC donnent aux serveurs destinataires la possibilité de vérifier si un message provient réellement de votre domaine. Trois raisons concrètes plaident pour leur mise en place :

Délivrabilité : les e-mails non authentifiés sont plus souvent classés comme spam ou rejetés.
Exigences des grands fournisseurs : depuis février 2024, Gmail et Yahoo exigent de tous les expéditeurs au moins SPF ou DKIM. Ceux qui envoient de gros volumes (chez Google : plus de 5000 messages par jour vers des adresses Gmail) ont besoin de SPF, de DKIM et d’un enregistrement DMARC, au minimum avec p=none, ainsi que d’une authentification alignée sur l’adresse d’expéditeur. Depuis mai 2025, Microsoft exige également SPF, DKIM et DMARC pour Outlook.com, Hotmail.com et Live.com de la part des expéditeurs de plus de 5000 messages par jour.
Protection contre l’usurpation (spoofing) : ce n’est qu’avec une politique DMARC quarantine ou reject que les destinataires peuvent écarter de manière fiable les e-mails falsifiés utilisant votre domaine.

Comment les trois mécanismes fonctionnent ensemble

SPF liste les serveurs autorisés à envoyer pour votre domaine. C’est le domaine de l’expéditeur technique (Return-Path) qui est vérifié.
DKIM signe chaque message de manière cryptographique. Vous publiez la clé publique dans le DNS.
DMARC relie les deux à l’adresse d’expéditeur visible (From). Un message réussit DMARC si SPF ou DKIM réussit et que le domaine vérifié correspond au domaine From (alignement). DMARC définit en outre ce qu’il advient des messages en échec et fournit des rapports.

Tous trois sont des enregistrements TXT. Les bases sur les types d’enregistrements se trouvent dans le guide Les enregistrements DNS expliqués.

Configurer SPF

Structure d’un enregistrement SPF

L’enregistrement SPF est un enregistrement TXT placé sur le domaine lui-même :

example.ch.  3600  IN  TXT  "v=spf1 mx include:_spf.google.com ip4:192.0.2.25 -all"

Les mécanismes sont évalués de gauche à droite, et la première correspondance l’emporte :

ip4: / ip6: autorisent des adresses ou des réseaux individuels
a et mx autorisent les adresses des enregistrements A ou MX du domaine
include: reprend l’enregistrement SPF d’un fournisseur
all à la fin s’applique à tous les autres serveurs

Les qualificateurs devant « all »

Qualificateur	Résultat	Utilisation
`-all`	fail	Recommandé dès que tous les expéditeurs sont recensés
`~all`	softfail	Phase de transition pendant la mise en place
`?all`	neutral	Pratiquement sans effet
`+all`	pass	Autorise n’importe quel serveur au monde à envoyer : à ne jamais utiliser

La limite de 10 requêtes DNS

Lors de l’évaluation, un enregistrement SPF peut déclencher au maximum 10 requêtes DNS. Sont comptés include, a, mx, ptr, exists et redirect, y compris les includes imbriqués dans les enregistrements des fournisseurs. ip4, ip6 et all ne comptent pas. Si la limite est dépassée, la vérification se termine par permerror et SPF est considéré comme non réussi.

Pour rester sous la limite :

Supprimez les includes des services que vous n’utilisez plus.
Remplacez a et mx par ip4/ip6 si les adresses sont stables.
Faites envoyer les outils de newsletter ou de CRM via un sous-domaine dédié (p. ex. news.example.ch) doté de son propre SPF.
Renoncez à ptr, qui est obsolète.

Un seul enregistrement SPF par domaine

S’il existe deux enregistrements TXT commençant par v=spf1, le résultat est également permerror. Cela arrive souvent lorsqu’un nouveau service est configuré et que son modèle est ajouté en plus. Ajoutez plutôt l’include du nouveau service à l’enregistrement existant.

Configurer DKIM

Comprendre les sélecteurs

Chaque message signé contient dans son en-tête le domaine (d=example.ch) et un sélecteur (s=google). Le destinataire interroge alors la clé sous selecteur._domainkey.example.ch. Plusieurs sélecteurs peuvent coexister, généralement un par service d’envoi. Cela permet aussi de changer de clé sans interruption. Utilisez des clés de 2048 bits.

google._domainkey.example.ch.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh…"

Comment les principaux fournisseurs publient DKIM

Google Workspace : dans la console d’administration, sous Gmail, générez une clé dans « Authentifier les e-mails ». Le sélecteur par défaut s’appelle google. Publiez l’enregistrement TXT affiché, puis lancez l’authentification dans la console.
Microsoft 365 : vous définissez ici deux enregistrements CNAME, selector1._domainkey et selector2._domainkey, qui pointent vers des cibles de votre locataire (tenant) Microsoft. Les valeurs exactes sont indiquées dans le portail Microsoft Defender, où vous activez ensuite DKIM. Microsoft se charge de la rotation des clés.
Hostpoint : si le domaine et le DNS sont chez Hostpoint, activez DKIM pour l’hébergement e-mail dans le Control Panel, et l’enregistrement est ajouté à la zone. Si vous gérez le DNS ailleurs, reportez manuellement le sélecteur et la clé chez votre fournisseur DNS.
Infomaniak : DKIM s’active dans le Manager, au niveau du service mail. Si le DNS n’est pas chez Infomaniak, ajoutez vous-même l’enregistrement TXT affiché.

Les noms de sélecteurs ne peuvent pas être listés depuis l’extérieur. Vérifiez donc dans la documentation de chaque service quel sélecteur il utilise.

Configurer DMARC

L’enregistrement DMARC se trouve toujours sous _dmarc :

_dmarc.example.ch.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.ch"

Les principales balises :

p : politique du domaine, soit none (observer uniquement), quarantine (dossier spam) ou reject (rejeter)
rua : adresse des rapports agrégés quotidiens. Si elle se trouve sur un domaine tiers, celui-ci doit en autoriser la réception via le DNS.
sp : politique pour les sous-domaines ; à défaut, p s’applique
pct : pourcentage des messages auxquels la politique est appliquée (100 par défaut)
adkim / aspf : alignement pour DKIM ou SPF, r (relaxed, les sous-domaines sont considérés comme correspondants, par défaut) ou s (strict, correspondance exacte)

La méthode sûre jusqu’à p=reject

Observer : commencez avec p=none et rua, et analysez les rapports pendant deux à quatre semaines. Ils montrent toutes les sources qui envoient des e-mails avec votre domaine : CRM, newsletter, comptabilité, formulaires de contact.
Corriger : configurez correctement SPF et DKIM pour chaque source légitime, en alignement avec le domaine From.
Quarantaine : passez à p=quarantine, si nécessaire d’abord avec pct=25, puis augmentez progressivement.
Rejet : si les rapports restent propres, passez à p=reject.

_dmarc.example.ch.  3600  IN  TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.ch"

Les domaines qui n’envoient jamais d’e-mails se protègent avec v=spf1 -all, une politique DMARC p=reject et, en option, un MX nul (0 .).

MTA-STS et TLS-RPT

Alors que SPF, DKIM et DMARC sécurisent les e-mails sortants, MTA-STS protège la réception : les serveurs expéditeurs doivent établir une connexion chiffrée, avec un certificat valide, vers vos serveurs MX. Cela nécessite un enregistrement TXT et un fichier de politique sous https://mta-sts.example.ch/.well-known/mta-sts.txt.

_mta-sts.example.ch.  3600  IN  TXT  "v=STSv1; id=20261002"

version: STSv1
mode: testing
mx: mx1.example.com
max_age: 604800

TLS-RPT fournit des rapports sur les connexions TLS qui ont échoué. Démarrez MTA-STS avec mode: testing, analysez les rapports, puis passez à enforce.

_smtp._tls.example.ch.  3600  IN  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.ch"

Checklist

Tous les services qui envoient des e-mails avec votre domaine sont recensés
Un seul enregistrement SPF, 10 requêtes au maximum, terminé par -all ou ~all
DKIM actif pour chaque service d’envoi, avec des clés de 2048 bits
DMARC publié avec rua, en commençant par p=none
Rapports analysés, puis passage à quarantine et à reject
Domaines sans envoi protégés avec -all et p=reject
En option : MTA-STS et TLS-RPT configurés

La vérification e-mail de NetScanner contrôle MX, SPF avec le nombre de requêtes, DMARC, les sélecteurs DKIM courants ainsi que MTA-STS, TLS-RPT et BIMI. Vous contrôlez les enregistrements TXT individuels avec la recherche DNS. Si une modification n’est pas encore visible, consultez le guide sur la propagation DNS ; en cas de changement de fournisseur, la checklist de migration de domaine.

Configurer correctement SPF, DKIM et DMARC