Un SPF pass peut être tout à fait correct sans rien faire pour authentifier l’adresse que voit votre client. Le serveur d'envoi peut être autorisé pour le domaine d'enveloppe d'un fournisseur tandis que le visible De utilise votre domaine professionnel. DMARC demande si une identité d'authentification réussie correspond à ce domaine d'auteur.
Il s'agit d'un problème d'identité, pas nécessairement d'un problème d'adresse IP manquante. Commencez par les domaines dans le message réellement reçu avant d’étendre les autorisations SPF .
Comparez trois observations distinctes
Enregistrez le domaine From visible, le domaine SPF évalué et le domaine à chaque passage Signature DKIM'sd= champ. Enregistrez le résultat du récepteur pour chaque mécanisme séparément. Ne pas en déduire alignement d'un SPF vert ou DKIM badge qui cache le domaine qu’il a évalué.
RFC 9989 section 4.4.2 définit l'alignement SPF . Un alignement strict exige que les domaines SPF et auteur correspondent exactement sous RFC 9989 §3.2.10.2. L'alignement détendu utilise la découverte du domaine organisationnel dans RFC 9989 §4.10.2. Il n'autorise aucun domaine appartenant à un fournisseur avec lequel vous avez un contrat.
Exemple travaillé : une passe correcte sans alignement
Ce qui suit est un outil de diagnostic synthétique supposant une politique DMARC applicable. Un message s'affiche De : accounts@example.com . C'est COURRIER DE est delivery@vendor.example.net . L'adresse IP de connexion est 192.0.2.17 . La politique d'enveloppe du fournisseur est v=spf1 ip4:192.0.2.17 -all, donc SPF passe.
Supposons que les domaines organisationnels soient example.com et example.net . Ils diffèrent, de sorte que le chemin SPF ne s'aligne pas en mode détendu ou strict. Si DKIM passe également uniquement avec d=vendor.example.net, aucune des deux identités transmises ne s'aligne. DMARC n'a donc pas de chemin aligné de dépassement sous RFC 9989 §5.3.5. Ajout de cette adresse IP à celle example.com Enregistrement SPF ne change rien au fait que cette transaction a utilisé vendor.example.net .
Considérons maintenant une enveloppe personnalisée prise en charge de return@bounce.example.com . Si SPF passe pour bounce.example.com et que lui et example.com ont la même découverte domaine organisationnel, un alignement détendu SPF peut passer. Un alignement strict n’est toujours pas possible car les noms diffèrent. Alternativement, une signature DKIM transmise avec d=example.com peut fournir un chemin DKIM aligné.
Choisissez une correction prise en charge
Demandez à la documentation du service ou à l'administrateur s'il prend en charge un domaine MAIL FROM personnalisé, DKIM aligné ou les deux. Obtenez les valeurs DNS exactes générées par le service. Une inclusion SPF générique ne configure pas elle-même une enveloppe personnalisée, et la fabrication manuelle de l'adresse de retour du fournisseur peut perturber la gestion des rebonds.
Choisissez la correction qui correspond au flux de travail et à votre politique. Un déploiement DKIM aligné offre souvent une résilience utile grâce au transfert, bien que les modifications apportées au contenu couvert puissent briser les signatures sous RFC 6376 §3.7. Si vous utilisez MAIL FROM personnalisé, testez l’enveloppe réelle une fois la configuration des rapports du fournisseur terminée. La disponibilité du produit et les étapes de configuration doivent être vérifiées pour le produit et le compte utilisés.
Ne relâchez pas l’alignement simplement pour supprimer un avertissement sans comprendre la limite qu’il crée. À l’inverse, ne sélectionnez pas un alignement strict comme gage de sécurité si les expéditeurs de sous-domaines légitimes ont été intentionnellement conçus pour un alignement détendu. Documentez pourquoi la relation d’identité choisie est acceptable.
Testez à nouveau le chemin, pas seulement DNS
Envoyez un message représentatif à une boîte aux lettres où vous pourrez inspecter les résultats des destinataires de confiance. Testez le type de notification qui a échoué, car les produits marketing et transactionnels d'un fournisseur peuvent utiliser des identités différentes. Capturez la nouvelle enveloppe, le résultat SPF , le domaine de signature DKIM et le résultat DMARC .
Si le publipostage fonctionne mais pas le courrier transféré, étudiez cet itinéraire séparément. N'appelez pas une correction DNS infructueuse simplement parce qu'un filtre de contenu sans rapport place toujours le message dans le spam. Les résultats de l’authentification et le placement de la boîte aux lettres sont des résultats distincts.
Les plats pratiques à emporter
Un diagnostic utile nomme le domaine de passage et montre pourquoi il s'aligne ou non. Réparez l’identité d’envoi prise en charge, puis vérifiez un vrai message. Des autorisations SPF plus larges sur le mauvais domaine ne peuvent pas combler un écart d'alignement.
Gardez la décision reproductible
Utilisez une ligne par identité de passage et son mode d'alignement. Avec uniquement le passage vendor.example.net pour From= example.com , marquez les deux passes brutes comme non alignées plutôt que de joindre un résultat à un autre domaine. Si d=example.com vérifie également, enregistrez ce chemin DKIM aligné séparé. Testez le comportement personnalisé de MAIL FROM indépendamment, même si DMARC global est déjà réussi.