Passer au contenu 
SPF DMARC décide aujourd'hui si les serveurs de messagerie acceptent vos messages, les mettent en quarantaine ou les rejettent complètement. J'explique comment l'alignement SPF du serveur de messagerie et les politiques DMARC interagissent, où les erreurs se produisent et comment vous pouvez améliorer la livraison, l'authenticité et la confiance en la marque étape par étape.
Points centraux
Je résume les principales conclusions de manière compacte, afin que vous puissiez directement tourner les bonnes vis. SPF détermine quels serveurs peuvent envoyer, mais c'est l'alignement qui relie cette technique au domaine visible de l'expéditeur. DMARC contrôle la réaction du destinataire et fournit des rapports que j'utilise pour l'optimiser. Sans alignement propre, vous perdez la livraison, même si les contrôles individuels réussissent. C'est pourquoi je planifie les chemins de l'expéditeur, les chemins de retour et les domaines DKIM de manière cohérente par rapport au domaine principal. J'établis ainsi une protection progressive sans mettre en danger les courriers légitimes.
- Alignement décide : From, Return-Path et DKIM-Domain doivent correspondre au domaine principal.
- Politique DMARC tax : none, quarantine, reject - serrer progressivement.
- SPF faire le ménage : un seul enregistrement, des inclusions claires, pas de doublons.
- DKIM signés : clés uniques, rotation, sélecteurs valides.
- Rapports utiliser les données : Lire les rapports, consolider les chemins d'expédition.
SPF en bref : la liste des expéditeurs dans le DNS
Je définis dans le DNS les systèmes autorisés à envoyer des e-mails pour mon domaine et sécurise ainsi le Chemin d'expédition. Un seul enregistrement SPF regroupe toutes les IP et les inclusions, afin que les fournisseurs d'accès puissent évaluer le contrôle de manière univoque. Je garde l'enregistrement léger, je limite les recherches DNS et je supprime les anciennes entrées qui n'ont pas d'utilité. Objectif n'ont plus de droits. Un qualificatif dur (-all) marque tout ce qui est inconnu comme non autorisé, dès que tous les chemins légitimes sont corrects. Ceux qui souhaitent aller plus loin trouveront des étapes pratiques dans ce guide compact. Guide d'authentification des e-mailsJe l'utilise comme liste de contrôle.
SPF Alignment dans la pratique : le From visible rencontre le Return-Path
Je vérifie d'abord si le domaine dans le flux visible correspond au domaine du chemin de retour, car c'est là que se trouve le Alignement. DMARC accepte un alignement détendu si les deux se trouvent sous le même domaine principal d'organisation ; strictement signifie : correspondance exacte. Je configure les services d'envoi externes de manière à ce que le gestionnaire de rebond utilise un sous-domaine de mon domaine principal. De cette manière, je lie clairement le contrôle technique et l'expéditeur visible et je définis un Standard, de la livraison. Les return paths erronés rompent souvent l'alignement sans que l'on s'en aperçoive - je le vérifie systématiquement à chaque nouvelle intégration.
Comprendre DMARC : Politique, alignement et rapports
DMARC évalue chaque message à l'aide du SPF et du DKIM et contrôle avec une Politique, ce qui se passe en cas d'erreur. Je commence avec p=none, je lis les rapports et j'identifie toutes les sources légitimes avant de passer à quarantine ou à reject. Avec aspf et adkim, je détermine si je demande un alignement détendu ou strict pour SPF et DKIM. J'utilise rua pour les rapports d'agrégation et renonce généralement à ruf au début, afin de garder le volume sous contrôle. Voici comment je construis un Image de toutes les voies d'expédition et de détecter rapidement les abus.
Comparaison des politiques DMARC : impact et utilisation
Le choix du niveau a une influence sur la livraison et la protection, c'est pourquoi je le fais sur la base de données, après avoir analysé les résultats de l'enquête. Rapports. Je sécurise d'abord SPF et DKIM par chemin, puis j'applique la politique. Je combine souvent un alignement plus strict avec DKIM, car les redirections brisent parfois SPF. Dans ce tableau, vous voyez les principales différences dont je tiens compte lors de la planification. Ainsi, la Contrôle à tout moment chez vous.
| Politique | Effet en cas d'échec | Recommandé pour | Remarque | Exemple d'enregistrement |
|---|---|---|---|---|
| none | Pas d'application | Phase de démarrage, état des lieux | Rassembler les rapports, combler les lacunes | v=DMARC1 ; p=none ; rua=mailto:[email protected] ; aspf=r ; adkim=r |
| quarantaine | Dossier spam/junk | Transition après épuration | Effet visible, risque modéré | v=DMARC1 ; p=quarantine ; rua=mailto:[email protected] ; aspf=r ; adkim=r |
| rejeter | Rejet | Application finale | Uniquement selon des pistes d'audit stables | v=DMARC1 ; p=reject ; rua=mailto:[email protected] ; aspf=s ; adkim=s |
Les erreurs typiques et comment y remédier
Je vois souvent plusieurs enregistrements SPF par domaine, ce qui facilite l'évaluation chez le destinataire. confus. Je consolide donc tout en une seule entrée et supprime les textes contradictoires. Un autre classique : les outils externes envoient avec votre domaine From, mais ne sont pas dans le SPF ou ne signent pas avec votre domaine DKIM. Je corrige le chemin de retour vers un sous-domaine propre et j'active DKIM avec un sélecteur de votre domaine. Ce n'est que lorsque tous les chemins d'accès sont corrects que j'applique une règle plus stricte. Politique, Les messages légitimes ne seront pas perdus.
Hébergement et infrastructure : ce à quoi je fais attention
Je choisis un fournisseur qui offre la gestion DNS, la signature DKIM sur le serveur et des assistants clairs pour Entrées propose. Une infrastructure de messagerie avec une bonne réputation aide, car les grands fournisseurs d'accès utilisent un filtrage strict. Je préfère les environnements dans lesquels je peux définir rapidement des sous-domaines, des sélecteurs et des adresses de reporting. Pour les configurations d'administration avec Plesk, ce Guide Plesk des étapes utiles que j'utilise souvent dans les projets. Cela me permet de garder les modifications claires et d'assurer Livraison durablement.
Introduction progressive : du suivi à l'application
Je commence chaque projet par un inventaire complet de tous les chemins d'expédition, afin de ne pas perdre de temps. Source oublier de le faire. Ensuite, je nettoie l'enregistrement SPF et j'active DKIM sur chaque système qui envoie du courrier. Je règle DMARC sur p=none, je collecte des rapports et je les compare à mon inventaire. Une fois que tout est authentifié proprement et aligné, je change la politique en quarantaine. Avec des chiffres suffisamment stables, je passe progressivement à rejeter, ce qui me permet d'obtenir des résultats clairs. Frontières pour les abus.
Évaluer les rapports : des données aux décisions
Les rapports d'agrégation m'indiquent quelles IP, quels domaines From et quelles valeurs de résultat apparaissent, de sorte que je puisse Anomalies de l'information. Je regroupe par source, je vois les taux d'échec et je vérifie s'il manque un alignement ou une signature. Si de nouvelles IP apparaissent, je décide de les inclure dans SPF ou de les bloquer. Pour l'évaluation, j'utilise des outils qui présentent les données XML de manière compréhensible et font apparaître des tendances. Cette introduction compacte à Analyser les rapports DMARC, que j'aime appeler Référence utilise.
Redirections, DKIM et ordre correct
Les redirections classiques peuvent casser SPF, car l'IP de redirection ne figure pas dans le SPF du domaine d'origine. se trouve. C'est pourquoi je sécurise en plus les envois avec DKIM, car la signature survit aux transferts propres. Je veille à respecter un ordre clair : d'abord fixer tous les chemins d'accès de l'expéditeur, puis surveiller, puis appliquer progressivement. Cela réduit les risques et permet de gagner du temps lors de la recherche d'erreurs, si certains chemins ne sont pas encore propres. En procédant de la sorte, on maintient les Taux d'erreur durablement bas.
Dans les chaînes plus complexes, je mise en outre sur des normes qui rendent les retransmissions plus robustes. Avec SRS (Sender Rewriting Scheme), il est possible de réécrire l'Envelope-From chez le redirecteur de manière à ce que SPF puisse à nouveau être correct. Cela ne fait pas partie de DMARC, mais c'est pratique si vous ne pouvez pas vous passer de redirections de domaine. Pour les listes de diffusion et les passerelles qui modifient le contenu, je tiens compte du fait que les signatures DKIM peuvent être brisées ; dans ce cas, je soutiens les chaînes de destinataires avec ARC (Authenticated Received Chain), afin que les contrôles précédents restent compréhensibles. Je prévois sciemment ces cas particuliers et les teste avec des scénarios réalistes avant de renforcer la politique.
SPF en détail : mécanismes, limites et structure propre
Je maintiens SPF techniquement de manière à ce qu'il reste stable et maintenable. Le principe des 10 lookups n'est pas négociable : include, a, mx, exists et redirect comptent. Je consolide les inclusions, supprime les cascades et évite le copier-coller „à plat“ de listes IP entières sans cycle de vie, car elles deviennent rapidement obsolètes. J'utilise redirect de manière ciblée lorsqu'un sous-domaine doit hériter exactement du SPF du domaine principal - include reste mon outil pour relier d'autres sources légitimes. je n'utilise pas ptr ; il n'est pas fiable et n'est pas recommandé. Je définis des réseaux clairs via ip4/ip6 avec des masques CIDR appropriés et j'utilise délibérément les qualificatifs : + (implicite), ~softfail pour les transitions et -fail dès que l'inventaire est terminé.
Je structure l'enregistrement SPF de manière à ce que les occurrences les plus fréquentes soient placées le plus tôt possible (courte distance d'évaluation) et je définis un TTL pratique afin de pouvoir déployer les modifications de manière contrôlée. Pour HELO/EHLO, je vérifie des identités SPF séparées si les systèmes le supportent, car certains destinataires évaluent en plus l'identité HELO. Je lie l'Envelope-From (Return-Path) à un propre sous-domaine qui correspond à ma surveillance et je m'assure qu'un enregistrement SPF approprié s'y trouve également. De cette manière, je conserve à la fois le contrôle technique et la vue d'ensemble de l'exploitation.
Déployer correctement DKIM : Clé, en-tête et rotation
J'utilise par défaut des clés RSA de 2048 bits et je prévois une rotation régulière avec des noms de sélecteurs clairs (par ex. basés sur l'année ou le trimestre). Le sélecteur doit être attribué de manière univoque à chaque système émetteur, afin que je puisse échanger des clés sans faire de compromis. Je signe les en-têtes pertinents (From obligatoirement, plus généralement Date, Subject, To, Message-ID) et j'oversigne From pour éviter les manipulations. Pour la canonicalization, je choisis c=relaxed/relaxed, car elle est en pratique robuste contre les changements de format triviaux. Je ne mets pas la balise l= (body-length), car elle peut ouvrir la voie à des abus et rendre la vérification plus fragile.
Je veille à ce que le domaine DKIM (d=) corresponde au domaine principal de l'organisation et contribue à l'alignement DMARC. Pour les expéditeurs externes, je configure si possible un sous-domaine propre et j'y fais signer mon sélecteur. Je ne mets pas de drapeaux de test de manière permanente : t=y est uniquement destiné à de courtes phases de test, t=s (strict) limite les correspondances de sous-domaines et ne convient pas à chaque concept d'alignement. Je planifie les TTL DNS pour les clés DKIM de manière à ce qu'une rotation au sein d'une fenêtre de maintenance soit possible sans longs délais d'attente - d'abord publier, puis changer les systèmes de production, puis supprimer les anciennes clés de manière ordonnée.
Stratégie de sous-domaine et staging : sp=, pct= et chemins d'accès propres aux expéditeurs
Je sépare les rôles par le biais de sous-domaines : transactionnel, marketing, support et messages système fonctionnent sur des chemins clairement nommés avec leur propre gestion des rebonds. Dans DMARC, j'utilise sp= pour imposer séparément les sous-domaines lorsque le domaine principal est encore sous surveillance. Pour des déploiements sans risque, j'utilise pct= pour échelonner par étapes jusqu'à ce que toutes les sources légitimes soient stables. Avec ri, je régule la cadence des rapports si le volume devient trop élevé, et j'enregistre plusieurs destinataires pour rua afin de séparer les évaluations opérationnelles des évaluations relatives à la sécurité. Je peux ainsi contrôler de manière granulaire sans mettre inutilement en danger le trafic productif.
BIMI : visibilité en prime sur la base de DMARC
Je considère BIMI comme un accélérateur de confiance visible, qui repose sur un DMARC propre. La condition préalable est une politique appliquée (quarantaine ou rejet) et un alignement cohérent. Je veille à ce que le logo de la marque soit propre et uniforme et à ce que les conventions de l'expéditeur soient claires, afin que l'affichage ne semble pas aléatoire. Un Verified Mark Certificate peut en outre augmenter l'acceptation ; je ne le prévois toutefois que lorsque SPF, DKIM et DMARC fonctionnent de manière fiable. Ainsi, BIMI devient la récompense d'une authentification d'e-mail déjà solide et non un raccourci risqué.
Routine d'exploitation et dépannage : contrôler les changements, trouver rapidement les erreurs
Je gère un journal des changements léger pour les modifications DNS, SPF, DKIM et DMARC, je définis les TTL appropriés et je déploie les adaptations dans les fenêtres de maintenance. Nous définissons des alertes en fonction des données : l'augmentation des taux d'échec DMARC, les nouvelles IP inconnues ou la baisse des taux de passes DKIM déclenchent des notifications. J'observe en outre les KPI opérationnels tels que les taux de rebond et de plaintes, les temps de distribution et les pourcentages de dossiers de spam. Cette combinaison de métriques techniques et de livraison nous évite de collecter uniquement des „coches vertes“, mais de passer à côté de véritables problèmes dans la boîte de réception.
Dans l'analyse, je commence par les en-têtes : Received-SPF m'indique l'identité et le résultat (pass/softfail/fail) et quel domaine a été vérifié (HELO vs. MailFrom). Authentication-Results liste dkim=pass/fail avec d= et s= ainsi que dmarc=pass/fail plus la politique appliquée. Si SPF=pass mais que DMARC échoue, je regarde l'alignement : le domaine From correspond-il au chemin de retour du point de vue organisationnel ou au domaine DKIM ? Si les signatures des listes de diffusion sont brisées par des préfixes de pied de page/objet, je choisis des signatures plus robustes et je m'appuie davantage sur l'alignement DKIM. Cela permet d'isoler la cause réelle et d'y remédier en quelques étapes.
Exigences des grands fournisseurs d'accès : ce que je prends en compte en plus
Les grandes boîtes aux lettres ont durci leurs règles : une politique DMARC appliquée, une hygiène de liste propre et un faible taux de plaintes sont aujourd'hui des conditions de base. Je définis les en-têtes List-Unsubscribe de manière cohérente (y compris la variante One-Click), je maintiens la stabilité du DNS inversé et des noms d'hôtes EHLO et j'impose TLS dans le transport là où c'est possible. Je contrôle les volumes élevés afin de construire une réputation et j'isole le trafic marketing sur mes propres sous-domaines. Je réponds ainsi aux attentes des fournisseurs d'accès modernes et traduis l'authentification directement en qualité de livraison.
Protection des données dans les rapports d'expertise : choisir en connaissance de cause
Je n'active ruf que de manière ciblée, car les rapports d'expertise peuvent contenir des contenus à caractère personnel et le volume est difficile à calculer. Lorsque j'active ruf, je stocke et traite les données de manière restrictive, je minimise les durées de conservation et je vérifie la base légale. Avec fo, je contrôle le volume, la plupart du temps, des rapports agrégés me suffisent entièrement pour prendre des décisions. Je respecte ainsi la protection des données tout en obtenant les informations dont j'ai besoin pour l'optimisation.
Bref résumé : ce qui est important maintenant
Je mise sur la cohérence Alignement entre From, Return-Path et DKIM-Domain, car c'est là que se décide la distribution. Je nettoie SPF, active DKIM à toutes les sources et démarre DMARC avec p=none pour obtenir des rapports pertinents. Avec une base de données claire, j'applique la politique de quarantaine et plus tard de rejet. J'observe les rapports en permanence et j'adapte les inclusions, les sélecteurs et les chemins d'accès aux expéditeurs lorsque les systèmes changent. Ainsi, je garantis l'authenticité, je réduis les abus et j'augmente la sécurité. Confiance tout courrier portant votre nom.
