L'aplatissement SPF affecte-t-il DKIM et DMARC ?

Réponse courte : l’aplatissement SPF ne change pas DKIM du tout, et il ne touche DMARC qu’indirectement. L’aplatissement réécrit la façon dont votre enregistrement v=spf1 est évalué — il remplace les chaînes d’include: imbriquées par des entrées ip4:/ip6: explicites — mais il ne modifie jamais vos clés DKIM, vos signatures DKIM, ni les domaines contre lesquels DMARC s’aligne. Bien fait, l’aplatissement renforce même DMARC en maintenant le SPF sous le plafond de 10 requêtes afin qu’il passe de manière fiable. Mal fait (IP obsolètes, enregistrements surdimensionnés), il peut faire échouer le SPF et pousser DMARC à s’appuyer entièrement sur DKIM.

Si vous saisissez cette seule distinction, tout le reste en découle. Cette page parcourt exactement comment les trois protocoles interagissent, afin que vous puissiez aplatir avec confiance plutôt qu’avec crainte.

Comment SPF, DKIM et DMARC sont réellement liés

Les trois protocoles font des tâches différentes, et un seul d’entre eux est affecté par l’aplatissement SPF :

• SPF vérifie si l’IP de connexion est autorisée à envoyer pour le domaine figurant dans l’enveloppe SMTP (le MailFrom / Return-Path). L’évaluation parcourt les mécanismes DNS — include:, a, mx, ptr, exists, redirect — et, selon la RFC 7208, elle est plafonnée à 10 requêtes DNS. Franchissez cette limite et vous obtenez un PermError, qui compte comme un échec SPF pour chaque message du domaine.
• DKIM attache une signature cryptographique à chaque message à l’aide d’une clé privée, vérifiée contre une clé publique publiée dans le DNS. Il est totalement indépendant du SPF et de l’IP de connexion.
• DMARC relie les deux. Il passe lorsque soit SPF soit DKIM passe et s’aligne avec le domaine From: visible (relâché ou strict). Si les deux échouent, DMARC applique votre politique — p=none, p=quarantine ou p=reject.

L’aplatissement vit entièrement à l’intérieur du périmètre SPF. Il change la structure de l’enregistrement SPF, pas les domaines impliqués. C’est pourquoi il ne peut pas, par conception, altérer la signature DKIM ou l’alignement DKIM.

L’aplatissement SPF affecte-t-il DKIM ?

Non — pas directement, et en rien qui compte pour la signature. DKIM repose sur une clé privée sur votre plateforme d’envoi et une clé publique à selector._domainkey.yourdomain.com. L’aplatissement ne touche jamais ni l’une ni l’autre. Vos sélecteurs, la longueur de vos clés et votre canonicalisation (c=relaxed/relaxed vs simple/simple) sont intacts, quoi qu’un outil d’aplatissement fasse à votre enregistrement TXT v=spf1.

Il existe exactement une relation indirecte qui mérite d’être nommée : DKIM devient plus important dès l’instant où l’aplatissement tourne mal. Si un enregistrement aplati se périme et que le SPF commence à échouer, DMARC n’a plus qu’un seul chemin pour passer — DKIM. Ainsi, une configuration DKIM saine et alignée est votre filet de sécurité lors de tout accroc du SPF. C’est une raison de garder DKIM solide, et non une raison d’éviter l’aplatissement.

L’aplatissement SPF affecte-t-il DMARC ?

Oui, mais généralement pour le mieux. Le chemin SPF de DMARC passe lorsque le SPF s’évalue proprement et que le domaine MailFrom s’aligne avec le domaine From:. L’aplatissement améliore la première moitié de cette équation :

• Moins de requêtes, moins d’erreurs. Condenser les chaînes d’include: en littéraux IP fait généralement passer l’évaluation de plus de 10 requêtes à 1-3. Cela élimine le PermError (trop de requêtes) et réduit le TempError (délais d’attente DNS) qui s’enregistreraient autrement comme des échecs SPF — et DMARC traite un PermError SPF comme un échec.
• L’alignement est inchangé. L’aplatissement ne touche ni le domaine MailFrom ni le domaine From:, il n’aide donc ni ne nuit à l’alignement lui-même. Il augmente simplement les chances que le SPF puisse être évalué avec succès en premier lieu.

En pratique, les équipes qui aplatissent correctement voient leur taux de « réussite SPF alignée » DMARC grimper sensiblement, parce que le chemin SPF cesse de générer des erreurs. Le gain est réel, mais il provient de la fiabilité, non d’un changement de ce que DMARC vérifie.

La seule façon dont l’aplatissement peut nuire à DMARC

L’aplatissement fige les IP tierces dans votre zone. Lorsqu’un fournisseur fait tourner son pool d’envoi, un enregistrement aplati obsolète manquera les nouvelles IP, et les e-mails légitimes échoueront au SPF. Quand cela arrive, DMARC se rabat sur DKIM. Si DKIM est présent et aligné, les e-mails passent quand même. Si DKIM est absent ou désaligné — fréquent pour les envois transactionnels ou déclenchés — DMARC échoue, et sous p=quarantine ou p=reject, ces e-mails sont retenus ou rebondissent.

Le risque n’est donc pas l’aplatissement lui-même. Le risque est l’aplatissement non entretenu. C’est le point opérationnel le plus important de cette page.

Pourquoi la maintenance est tout l’enjeu

Les plages d’IP des fournisseurs changent constamment — les grands ESP et CDN font tourner leurs plages toutes les quelques semaines, parfois plus vite lors des périodes de pointe. Un enregistrement que vous aplatissez à la main aujourd’hui est exact aujourd’hui et dérive dès demain. Deux modes de défaillance en découlent :

Symptôme d’un enregistrement obsolète	Ce qui casse	Effet sur DMARC
Nouvelles IP de fournisseur manquantes	Les e-mails légitimes échouent au SPF	DMARC s’appuie sur DKIM ; échoue si DKIM absent/désaligné
Conservation d’IP retirées	Des IP réattribuées peuvent passer le SPF pour votre domaine	Fenêtre d’usurpation — un nouveau locataire pourrait envoyer des e-mails « autorisés »

Les deux sont évitables, mais uniquement avec une automatisation qui re-résout l’enregistrement à une cadence serrée. C’est exactement là qu’AutoSPF est conçu pour aider : il ré-analyse toutes les 15 minutes et met à jour automatiquement l’enregistrement dès que les IP en amont changent, et il résout vers exactement les mêmes IP que vos includes — pas de sur-autorisation, pas de super-réseaux larges laissés ouverts aux abus. Cette combinaison referme à la fois la faille de délivrabilité liée aux IP obsolètes et la fenêtre d’usurpation que l’aplatissement manuel laisse ouverte.

Garder l’enregistrement sûr : taille, requêtes et la règle de l’enregistrement unique

Au-delà de l’obsolescence, trois contraintes techniques empêchent un SPF aplati de casser DMARC :

• Un seul enregistrement. Un domaine ne peut publier qu’exactement un enregistrement TXT commençant par v=spf1. Deux d’entre eux produisent un PermError. Si vous devez diviser pour des raisons de taille, divisez en plusieurs chaînes au sein du même enregistrement TXT — jamais en enregistrements séparés.
• Surveillez le budget d’octets. Chaque segment de chaîne TXT est plafonné à 255 caractères (les implémentations les concatènent). Maintenez le total confortablement sous ~450-600 octets ; les enregistrements surdimensionnés risquent la troncature et la fragmentation entre résolveurs.
• Restez sous 10 requêtes. Un aplatissement partiel qui laisse des include:, a, mx ou exists imbriqués en place peut quand même heurter le plafond. Préférez les littéraux ip4:/ip6:, supprimez le ptr déprécié, et compressez les plages contiguës en CIDR.

Gardez votre qualificateur de fin délibéré — terminez par -all (échec strict) ou ~all (échec souple) selon votre politique. Apprenez tous les mécanismes dans comment aplatir un enregistrement SPF, et si vous comparez cela aux approches basées sur les macros, consultez l’aplatissement SPF vs les macros.

Ce que l’aplatissement ne peut pas corriger

L’aplatissement résout les erreurs de requêtes et de délais d’attente. Il ne résout pas :

• Le transfert. Lorsqu’un message est transféré, l’IP de connexion change, si bien que le SPF pour votre domaine échoue quelle que soit la propreté de votre enregistrement. Les solutions sont le SRS au niveau du transitaire ou — plus fiablement — un DKIM aligné, qui survit au transfert. C’est précisément pourquoi DKIM doit toujours être de premier plan.
• Le désalignement fournisseur. Si un ESP envoie avec un domaine de rebond qui n’est pas un sous-domaine de votre domaine From:, l’alignement SPF strict échoue quoi qu’il arrive. C’est un problème de configuration du MailFrom, pas un problème d’aplatissement.

Pour ces cas, la réponse est DKIM + DMARC (et SRS/ARC chez les intermédiaires), jamais un aplatissement plus agressif.

La posture recommandée

La configuration la plus sûre est hybride : aplatissez les fournisseurs stables à fort nombre de requêtes pour rester sous le plafond ; gardez les expéditeurs véritablement dynamiques sur des includes gérés par le fournisseur ; imposez un DKIM aligné sur chaque flux ; et surveillez les rapports agrégés DMARC afin de voir si c’est le SPF ou le DKIM qui porte réellement vos réussites.

Avant de changer quoi que ce soit, confirmez où vous en êtes aujourd’hui. Passez votre enregistrement actuel dans le SPF Checker pour voir votre nombre de requêtes en direct et repérer les includes qui vous poussent vers la limite — puis décidez quoi aplatir. Automatiser le rafraîchissement avec AutoSPF transforme le seul risque réel de l’aplatissement — la dérive — en un problème résolu, si bien que votre SPF aplati renforce DMARC au lieu de le saper discrètement.

Foire aux questions

L’aplatissement SPF change-t-il ma configuration DKIM ?

Non. L’aplatissement réécrit seulement la façon dont votre enregistrement SPF est évalué, en remplaçant les chaînes d’include: par des littéraux ip4:/ip6:. Il ne touche jamais votre clé privée DKIM, votre clé publique, vos sélecteurs ni vos signatures. Le seul lien est qu’une configuration DKIM solide et alignée agit comme le filet de sécurité de DMARC si un enregistrement SPF aplati venait à se périmer et que le SPF échouait.

L’aplatissement SPF va-t-il casser DMARC ?

Pas s’il est entretenu. Parce que DMARC passe lorsque SPF ou DKIM s’aligne, un aplatissement bien entretenu améliore en fait DMARC en maintenant le SPF sous la limite de 10 requêtes afin qu’il passe de manière fiable. DMARC ne souffre que si un enregistrement aplati se périme, que le SPF commence à échouer, et que DKIM n’est pas là pour couvrir le message.

L’aplatissement SPF est-il sûr ?

Oui, lorsqu’il est automatisé. Le seul risque réel est la dérive — les fournisseurs font tourner leurs IP et un enregistrement aplati statique se périme, provoquant des échecs SPF ou laissant des IP retirées autorisées. Un outil qui ré-analyse fréquemment et re-résout vers les IP amont exactes (AutoSPF vérifie toutes les 15 minutes) supprime ce risque. C’est dans l’aplatissement manuel « configuré puis oublié » que réside le danger.

Ai-je encore besoin de DKIM si mon SPF est parfaitement aplati ?

Absolument. DKIM est le chemin de réussite DMARC le plus fiable car il survit au transfert et aux listes de diffusion, là où le SPF échoue par conception. Même un enregistrement aplati impeccable peut rencontrer un problème DNS transitoire, et c’est DKIM qui maintient DMARC passant à ce moment-là. Ne considérez jamais l’aplatissement comme un substitut à DKIM.

L’aplatissement SPF peut-il provoquer l’usurpation d’e-mails ?

Uniquement par négligence. Si un enregistrement aplati conserve des IP qu’un fournisseur a retirées, et que ces IP sont réattribuées à un nouveau locataire, ce locataire pourrait passer le SPF pour votre domaine. Aplatir vers exactement les mêmes IP que celles auxquelles vos includes se résolvent — et élaguer automatiquement les plages retirées — prévient entièrement cette sur-autorisation.

À quelle fréquence un enregistrement SPF aplati doit-il être mis à jour ?

Aussi souvent que vos fournisseurs changent d’IP, ce qui, pour les expéditeurs cloud dynamiques, peut être tous les quelques jours. Les mises à jour manuelles ne peuvent pas suivre le rythme, c’est pourquoi l’automatisation compte : AutoSPF ré-analyse toutes les 15 minutes et republie dès que les IP en amont changent, si bien que l’enregistrement ne dérive jamais suffisamment pour casser le SPF ou laisser une fenêtre d’usurpation ouverte.