Principe des enregistrements DNS

Les trois mécanismes d’authentification reposent sur des enregistrements TXT publiés dans le DNS du domaine. L’enregistrement SPF décrit les adresses IP autorisées à envoyer pour le domaine, l’enregistrement DKIM expose la clé publique associée à un sélecteur, et l’enregistrement DMARC indique la politique à appliquer lorsque SPF ou DKIM échouent. Le guide cite un exemple SPF : 

v=spf1 include:_spf.google.com ~all
qui autorise les serveurs Google et indique un softfail pour les autres. L’exemple DKIM montre la syntaxe typique : 
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu3Xk...IDAQAB
. Enfin, l’enregistrement DMARC présenté est : 
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=r; pct=100
où p=quarantine indique que les messages non alignés doivent être placés en quarantaine.

Fonctionnement de SPF, DKIM et DMARC

Lorsqu’un serveur de réception reçoit un courriel, il interroge trois domaines différents. SPF examine le Return‑Path (enveloppe d’expédition) : si l’adresse IP du serveur figure dans la liste SPF, le test passe. DKIM vérifie la signature cryptographique insérée dans l’en‑tête ; le champ d= indique le domaine signé et le sélecteur (selector._domainkey.domain) permet de récupérer la clé publique. DMARC combine les deux résultats en exigeant qu’au moins l’un d’eux soit valide et que le domaine utilisé corresponde à l’adresse From visible. L’alignement peut être « relaxed », ce qui accepte des sous‑domaines partageant le même domaine organisationnel (ex. mail.example.com et send.mail.example.com).

Le texte souligne que Gmail impose SPF ou DKIM même aux petits expéditeurs, et les trois contrôles pour les volumes supérieurs à 5 000 messages/jour vers des comptes Gmail personnels. Cette exigence montre que l’absence d’un enregistrement peut entraîner un rejet 550 5.7.26, même si le contenu du message est légitime.

Analyse des limites et bonnes pratiques

Le principal point de friction réside dans le domaine vérifié par chaque mécanisme. SPF ne regarde jamais l’adresse From ; il se base sur le Return‑Path, souvent remplacé par le domaine du fournisseur d’envoi. Cette dissociation crée des échecs lors du forwarding, où le serveur de relais n’est pas listé dans le SPF d’origine, entraînant un softfail. DKIM, quant à lui, reste robuste face au forwarding tant que la signature n’est pas altérée, mais il dépend de la bonne publication de la clé publique et de la sélection d’en‑têtes signés (From, Subject, etc.). DMARC ne résout pas les problèmes de délivrabilité liés à la réputation de l’expéditeur ; il ne fait que rejeter ou mettre en quarantaine les messages qui ne respectent pas l’alignement. Ainsi, même avec SPF + DKIM + DMARC correctement configurés, les filtres anti‑spam peuvent encore classer le message comme indésirable si la réputation IP est faible.

En pratique, la vérification doit être faite en deux temps : (1) confirmer que les enregistrements DNS sont correctement publiés et (2) envoyer un message test et analyser les en‑têtes de réception pour s’assurer que SPF et DKIM passent et que DMARC indique « pass ». L’article recommande d’effectuer ces contrôles immédiatement après la connexion du domaine à un service d’envoi, afin d’éviter les rebonds et les placements en spam qui impactent les flux critiques comme les réinitialisations de mot de passe ou les factures.