Ne plus finir en spam : configurer SPF, DKIM et DMARC sur son domaine

Vos e-mails de connexion arrivent bien chez vos utilisateurs Gmail… mais tombent en spam chez ceux qui utilisent Apple Mail / iCloud. Ce guide explique pourquoi, et surtout comment régler ça proprement — en partant d’un cas réel.

Récemment, en mettant en production une application, j’ai constaté un classique : les e-mails transactionnels (liens de connexion « magic link ») passaient en spam sur Apple Mail, alors que Gmail les acceptait sans broncher. Le diagnostic et la correction m’ont fait dérouler toute la chaîne d’authentification e-mail. Voici le tout, expliqué de façon à ce que n’importe qui puisse le reproduire.

Le problème, concrètement

Vous envoyez des e-mails « au nom » de votre domaine (no-reply@mondomaine.fr), généralement via un prestataire d’envoi (Brevo, SendGrid, Mailgun, Postmark…). Le destinataire, lui, ne vous connaît pas. Son serveur de messagerie se pose une seule question :

« Ce message qui prétend venir de mondomaine.fr a-t-il vraiment été autorisé par mondomaine.fr ? Ou est-ce un usurpateur ? »

Tant que la réponse n’est pas un oui franc et vérifiable, le message est suspect → dossier spam. C’est aussi le mécanisme que les attaquants exploitent pour le phishing : usurper votre domaine pour tromper vos clients ou vos collaborateurs. Et tous les fournisseurs ne mettent pas la barre à la même hauteur : Gmail est tolérant, Apple/iCloud est sévère. D’où l’effet « ça passe chez les uns, pas chez les autres ».

La bonne nouvelle : « prouver qu’on est bien soi-même » se fait avec trois enregistrements DNS. C’est tout.

Le trio SPF / DKIM / DMARC, avec une analogie

Imaginez que vous envoyez un colis (l’e-mail) via un transporteur (ex. Brevo). Le destinataire (le serveur de réception) veut s’assurer qu’il vient bien de vous.

SPF — « la liste des transporteurs que j’autorise »

SPF (Sender Policy Framework) est une liste, publiée dans votre DNS, des serveurs autorisés à envoyer du courrier pour votre domaine. C’est l’équivalent de dire au gardien : « Seuls les livreurs de telle société ont le droit de déposer un colis en mon nom. »

Concrètement, un enregistrement TXT sur votre domaine :

v=spf1 include:spf.brevo.com ~all

Le serveur de réception regarde l’IP qui lui livre le message et vérifie qu’elle est bien dans la liste.

Un seul enregistrement SPF par domaine. Si vous en avez déjà un, on fusionne les include: dans la même ligne — on n’en crée pas un deuxième (deux SPF = SPF invalide). C’est un point souvent oublié lors d’une migration de messagerie : on ajoute le nouvel include: sans retirer ni fusionner l’ancien.

DKIM — « le sceau de cire infalsifiable »

DKIM (DomainKeys Identified Mail) ajoute une signature cryptographique au message. Le prestataire signe chaque e-mail avec une clé privée ; la clé publique correspondante est publiée dans votre DNS. Le destinataire recalcule la signature : si elle correspond, c’est la preuve que le message vient bien de votre domaine et n’a pas été altéré en route.

C’est le sceau de cire sur l’enveloppe : personne ne peut le contrefaire sans la clé privée.

Dans le DNS, cela ressemble à des enregistrements CNAME (avec Brevo, deux clés) :

brevo1._domainkey.mondomaine.fr  →  b1.mondomaine-fr.dkim.brevo.com
brevo2._domainkey.mondomaine.fr  →  b2.mondomaine-fr.dkim.brevo.com

DMARC — « les consignes + la vérification que le nom colle »

DMARC (Domain-based Message Authentication, Reporting & Conformance) fait deux choses :

1. Il donne une consigne au serveur de réception : « Si un message prétendant venir de chez moi échoue aux contrôles, que dois-tu en faire ? » → ne rien faire (none), le mettre en spam (quarantine), ou le rejeter (reject).
2. Il impose l’alignement — et c’est le concept clé que beaucoup ratent.

Un enregistrement TXT sur _dmarc.mondomaine.fr :

v=DMARC1; p=quarantine; rua=mailto:rapports@mondomaine.fr

Le concept qui change tout : l’alignement

On peut avoir SPF et DKIM qui « passent »… et quand même échouer DMARC. Pourquoi ? Parce que SPF et DKIM vérifient des choses techniques qui ne concernent pas forcément le domaine affiché dans le De :.

• Le From: que voit l’utilisateur (no-reply@mondomaine.fr) est ce qui compte pour lui.
• Mais l’adresse technique de retour (le Return-Path, utilisée par SPF) est souvent celle du prestataire (bounces-xxx@sender-sib.com pour Brevo).

L’alignement DMARC, c’est vérifier que le domaine prouvé par SPF ou DKIM correspond bien au domaine du From:. Il suffit qu’un des deux soit aligné.

Dans mon cas réel, l’analyse des en-têtes donnait :

spf=pass    smtp.mailfrom=bounces-...@sender-sib.com   ← SPF pass, mais domaine du prestataire (non aligné)
dkim=pass   header.d=mondomaine.fr                     ← DKIM pass ET aligné sur mon domaine
dmarc=pass  header.from=mondomaine.fr                  ← donc DMARC pass grâce à DKIM

Leçon : c’est le DKIM aligné sur votre domaine qui sauve la mise dans une configuration via prestataire. D’où l’importance de bien poser les clés DKIM.

Diagnostiquer avant d’agir : lire les en-têtes

Avant de toucher au DNS, il faut regarder ce qui se passe réellement. Ouvrez un e-mail reçu et affichez ses en-têtes complets :

• Apple Mail : Présentation → Message → Tous les en-têtes (⌘⇧H)
• Gmail : menu ⋮ → « Afficher l’original »
• Thunderbird : Affichage → En-têtes → Complets (ou Ctrl+U / ⌘U pour le code source du message)

Le même réflexe vaut pour d’autres clients de messagerie.

Cherchez la ligne Authentication-Results :

Authentication-Results: dmarc.icloud.com; dmarc=pass header.from=mondomaine.fr
Authentication-Results: ...; dkim=pass header.d=mondomaine.fr
Authentication-Results: ...; spf=pass smtp.mailfrom=...

Et le Received: vous dit par où le message est réellement passé (from gx.d.sender-sib.com = envoyé via Brevo).

C’est ce qui m’a permis de comprendre que, dans mon cas, l’authentification était déjà parfaite : le spam ne venait pas de là, mais de la réputation. Sans lire les en-têtes, j’aurais « corrigé » un problème qui n’existait pas.

Règle d’or : on ne configure pas à l’aveugle. On lit d’abord les en-têtes.

L’architecture gagnante : séparer ses domaines

Voici le choix qui simplifie tout le reste, et que je recommande :

Domaine	Usage	Envoi via
mondomaine.fr	E-mails transactionnels & marketing (notifications, liens de connexion, newsletters)	Un seul prestataire (Brevo)
mondomaine.com	E-mails humains (votre boîte pro)	Votre fournisseur

Pourquoi c’est puissant :

• Isolation de réputation : si une campagne marketing dégrade la réputation, elle n’affecte pas vos e-mails professionnels, et inversement.
• DMARC sans risque : puisque mondomaine.fr n’envoie que via Brevo, 100 % de son trafic est aligné. On peut donc durcir la politique DMARC jusqu’à reject sans jamais bloquer un e-mail légitime. C’est le point clé : un domaine à canal unique est un domaine qu’on peut verrouiller.
• Clarté : chaque domaine a un rôle, une configuration DNS dédiée, un diagnostic simple.
• Moins de dépendance fournisseur sur un seul canal mixte : si vous changez de prestataire d’envoi, vous ne cassez pas la messagerie humaine, et inversement.

Ce point complète une migration de messagerie : SPF, DKIM et DMARC doivent être en place dès le basculement des MX, sinon les nouveaux envois partent en spam.

La configuration pas à pas

Étape 1 — Authentifier le domaine chez votre prestataire

Dans Brevo (Senders, Domains & Dedicated IPs → Domains), ajoutez votre domaine. Le prestataire vous fournit les enregistrements exacts à poser :

• un code de vérification (TXT sur @) pour prouver que le domaine est à vous ;
• deux clés DKIM (CNAME brevo1._domainkey et brevo2._domainkey) ;
• éventuellement un rappel pour SPF et DMARC.

Étape 2 — Poser les enregistrements dans votre DNS

Chez votre registrar / hébergeur DNS, créez :

# Vérification de propriété
@                       TXT     brevo-code:xxxxxxxxxxxxxxxxxxxx

# DKIM (les deux clés)
brevo1._domainkey       CNAME   b1.mondomaine-fr.dkim.brevo.com
brevo2._domainkey       CNAME   b2.mondomaine-fr.dkim.brevo.com

# SPF (si vous n'en avez pas déjà un — un SEUL enregistrement SPF par domaine !)
@                       TXT     v=spf1 include:spf.brevo.com ~all

Revenez chez le prestataire et cliquez sur « Vérifier ». La propagation DNS peut prendre de quelques minutes à quelques heures.

Vous pouvez contrôler vous-même en ligne de commande (voir aussi l’aide-mémoire des commandes Linux) :

dig +short CNAME brevo1._domainkey.mondomaine.fr
dig +short TXT   _dmarc.mondomaine.fr
dig +short TXT   mondomaine.fr | grep spf1

Étape 3 — DMARC : la montée en puissance progressive

Ne passez jamais directement en reject. On y va par paliers.

Palier 1 — Observer (p=none)

v=DMARC1; p=none; rua=mailto:rapports@mondomaine.fr

Aucun impact sur la délivrabilité : vous collectez juste des rapports (rua) pour vérifier que tous vos envois légitimes sont bien alignés. Restez-y quelques jours à deux semaines.

Palier 2 — Mettre en quarantaine (p=quarantine)

v=DMARC1; p=quarantine; sp=quarantine; adkim=r; aspf=r; pct=100; rua=mailto:rapports@mondomaine.fr

Les messages non authentifiés « au nom » de votre domaine partent en spam chez le destinataire. Comme votre trafic légitime est aligné (DKIM), il n’est pas affecté. Bonus : ce palier débloque BIMI.

Palier 3 — Rejeter (p=reject)

v=DMARC1; p=reject; sp=reject; adkim=r; aspf=r; pct=100; rua=mailto:rapports@mondomaine.fr

Le signal maximal de confiance : les usurpations sont refusées avant même d’atteindre la boîte. C’est l’objectif final pour un domaine transactionnel dédié.

Décoder les paramètres DMARC

Paramètre	Rôle	Conseil
p	Politique du domaine	none → quarantine → reject, par paliers
sp	Politique des sous-domaines	Alignez-la sur p — sinon vos sous-domaines (mail., marketing.) restent des portes ouvertes au spoofing
adkim	Alignement DKIM	r (relaxed) convient presque toujours ; s (strict) est plus fragile
aspf	Alignement SPF	idem, r
pct	% de messages soumis à la politique	100
rua	Où envoyer les rapports agrégés	indispensable pour surveiller
ruf	Où envoyer les rapports d’échec détaillés	optionnel ; sans lui, l’option « générer un rapport si un contrôle échoue » n’a aucun effet

Le piège classique : laisser sp=none. Vous protégez mondomaine.fr mais laissez n’importe qui usurper n-importe-quoi.mondomaine.fr. Si aucun sous-domaine n’envoie de courrier légitime, mettez sp au même niveau que p — aucun risque, sécurité en plus.

Documentez ces enregistrements dans votre inventaire SI : c’est un point souvent absent des audits SI, alors qu’une mauvaise config DNS casse la délivrabilité du jour au lendemain.

Pourquoi Apple est plus dur — et le facteur qu’on oublie

Même avec une authentification parfaite, un e-mail peut encore filer en spam. Deux raisons, chez Apple en particulier.

La réputation d’un domaine neuf

Un domaine créé il y a quelques semaines n’a aucun historique. Apple/iCloud, très prudent, préfère l’écarter le temps de vous « observer ». Cela se construit avec :

• le temps (comptez 2 à 4 semaines d’envois réguliers) ;
• l’engagement : quand un destinataire sort votre message du spam ou vous ajoute à ses contacts, il l’apprend vite (dans mes en-têtes, un message ainsi « repêché » portait déjà X-Apple-Movetofolder: INBOX) ;
• la régularité du volume (pas de pic soudain) ;
• éventuellement une IP dédiée chez le prestataire, si votre volume le justifie, pour ne plus subir la réputation mutualisée de l’IP partagée.

BIMI : le bonus de confiance

BIMI (Brand Indicators for Message Identification) affiche votre logo à côté de vos e-mails dans les boîtes compatibles (dont Apple Mail). Ce n’est pas qu’esthétique : c’est un signal de confiance fort. Mais BIMI exige au minimum p=quarantine — c’est pour ça que le durcissement DMARC est doublement gagnant. Un en-tête bimi=skipped reason="insufficient dmarc" signifie simplement : « reviens quand tu seras au moins en quarantine. »

Checklist récapitulative

• Un domaine dédié au transactionnel/marketing, séparé du domaine humain
• Domaine authentifié chez le prestataire d’envoi (code de vérification validé)
• Deux clés DKIM posées et vérifiées (brevo1 / brevo2._domainkey)
• Un seul SPF, incluant le prestataire (include:spf.brevo.com)
• DMARC en place, en montée progressive none → quarantine → reject
• sp aligné sur p (sous-domaines protégés)
• rua configuré et rapports surveillés
• Diagnostic par lecture des en-têtes (Authentication-Results) avant/après
• Patience : laisser la réputation se construire (2-4 semaines) + encourager l’engagement
• Bonus : BIMI une fois en quarantine / reject

En résumé

L’authentification e-mail n’est pas de la magie noire : c’est trois enregistrements DNS qui répondent à une seule question — « êtes-vous vraiment qui vous prétendez être ? ». SPF liste vos expéditeurs, DKIM les signe, DMARC arbitre et impose l’alignement. Le reste — Apple plus strict, spam malgré une auth parfaite — se joue sur la réputation, qui se construit avec le temps et l’engagement.

Le meilleur conseil : séparez vos domaines, lisez vos en-têtes avant de toucher au DNS, et durcissez DMARC par paliers. Vous passerez d’un domaine suspect à un domaine de confiance — et vos utilisateurs Apple recevront enfin vos e-mails là où ils doivent être : dans leur boîte de réception.

Pour aller plus loin sur le même périmètre : migration d’emails en crise, prévention ransomware / phishing, éviter le vendor lock-in, et le pilotage IT pour intégrer ces contrôles dans la feuille de route plutôt que de les traiter en urgence.