Un expéditeur peut prouver le contrôle de son propre domaine. Il peut néanmoins afficher votre domaine dans l'adresse From. Une authentification réussie seule n'établit pas la permission d'utiliser cette identité affichée.
Pourquoi SPF et DKIM peuvent-ils réussir alors que DMARC échoue ?
Les deux vérifications peuvent authentifier des domaines qui ne correspondent pas au domaine From visible.
SPF vérifie si le serveur connecté est autorisé pour le domaine de l'expéditeur d'enveloppe utilisé pour les avis de non-remise. DKIM valide une signature cryptographique associée à un domaine signataire, identifié par le tag d de la signature.
L'expéditeur d'enveloppe est fourni pendant la conversation SMTP. Il est distinct de l'en-tête From affiché par le client de messagerie du destinataire.
Par exemple, un expéditeur contrôlant attacker.example peut réussir SPF et DKIM pour ce domaine. L'expéditeur peut mettre billing@example.com dans From. Aucun des deux résultats ne valide example.com, donc DMARC échoue.
Un domaine organisationnel est la limite administrative contenant un domaine et ses sous-domaines, par exemple example.com pour news.example.com.
Qu'est-ce qui est considéré comme aligné ?
L'alignement souple exige un domaine organisationnel commun. L'alignement strict exige des domaines identiques.
Le RFC 9989 définit comment les récepteurs découvrent cette limite.
| Domaine authentifié | Domaine From | Alignement |
|---|---|---|
foo.example.com | news.example.com | Souple, car les deux partagent example.com |
news.example.com | news.example.com | Strict, car les domaines sont identiques |
foo.example.net | news.example.com | Aucun, car les domaines organisationnels diffèrent |
Le tag adkim contrôle l'alignement DKIM. Le tag aspf contrôle l'alignement SPF. Chacun accepte r pour souple ou s pour strict, avec souple par défaut.
Utilisez l'alignement strict uniquement lorsque vous avez besoin de domaines identiques, car il exclut des correspondances autrement valides entre sous-domaines frères. Un service signant en tant que foo.example.com ne peut pas satisfaire l'alignement strict pour From à news.example.com.
La spécification indique que la quasi-totalité des propriétaires de domaine trouvent l'alignement souple suffisant. Vos exigences de correspondance de domaine déterminent si l'alignement souple est approprié.
DMARC a-t-il besoin que les deux méthodes soient alignées ?
Non : un résultat aligné positif de SPF ou de DKIM suffit.
Le récepteur évalue les méthodes indépendamment. Un résultat positif mais non aligné ne peut pas fournir le résultat DMARC positif.
Le transfert peut casser SPF en changeant le serveur connecté. DKIM peut survivre si le relais préserve le contenu signé. Une signature intacte provenant d'un domaine aligné permet alors au message de réussir DMARC malgré l'échec de SPF.
Si le transfert modifie le contenu signé, DKIM peut également échouer. Comment corriger les échecs DMARC explique le diagnostic.
Pourquoi un service d'envoi peut-il casser l'alignement SPF ?
L'alignement SPF échoue lorsque le service utilise un domaine d'expéditeur d'enveloppe qui ne s'aligne pas avec votre domaine From visible.
Si le service utilise son propre domaine de rebond non lié, SPF peut réussir pour ce domaine. DMARC rejette ce résultat comme non aligné. Ajouter le service à un enregistrement SPF sur votre domaine ne change pas le domaine vérifié par le récepteur.
Configurez un chemin de retour personnalisé, le domaine utilisé pour les avis de non-remise, sous votre propre domaine. En alignement souple, bounce.example.com peut correspondre à From à example.com.
DKIM offre une autre voie : configurez le service pour qu'il signe avec un domaine aligné. Vous pouvez confirmer les deux résultats dans les rapports agrégés, qui résument les vérifications du récepteur.
Comment configurer le chemin de retour avec Bird ?
Vous publiez l'alias de chemin de retour de Bird sous votre domaine d'envoi.
Publiez cet alias en tant qu'enregistrement CNAME. L'alias de chemin de retour fournit la configuration SPF de Bird, vous n'avez donc pas besoin d'un enregistrement SPF séparé à la racine du domaine pour les envois Bird.
Le champ return_path.name de API accepte de 1 à 63 lettres, chiffres ou tirets, avec une lettre ou un chiffre à chaque extrémité. Un libellé plus long ou commençant par un tiret est invalide.
Bird ajoute votre domaine d'envoi. Par exemple, send sur mail.example.com devient send.mail.example.com. Ce chemin de retour peut s'aligner avec From à mail.example.com en mode souple.
Le guide du domaine de rebond couvre l'enregistrement. Vous publiez également l'enregistrement DKIM. Bird accepte une politique DMARC valide sur le domaine d'envoi ou sur son domaine organisationnel. Une politique de surveillance de p=none, qui n'exprime aucune préférence de traitement pour les échecs, est suffisante.
Comment la spécification trouve-t-elle les domaines organisationnels ?
Le RFC 9989 parcourt la hiérarchie de domaine à la recherche d'enregistrements qui établissent la politique applicable et la limite de domaine. Ce parcours est appelé DNS tree walk.
La spécification remplace l'approche Public Suffix List décrite par le RFC 7489. Cette liste identifie les suffixes d'enregistrement partagés tels que com et co.uk.
La distinction affecte l'alignement souple, car le domaine organisationnel découvert détermine si des noms liés correspondent. Elle affecte également la politique parente qui s'applique à un sous-domaine. Une spécification publiée n'établit pas quelle méthode de découverte un récepteur particulier implémente.
Un tag de pourcentage peut-il contrôler l'application de la politique ?
Le tag de pourcentage pct ne fournit pas une application partielle fiable. Le RFC 9989 l'exclut.
L'annexe A.6 décrit un traitement incohérent des pourcentages intermédiaires. Un réglage de pct=50 ne peut donc pas vous garantir qu'un traitement plus strict touche exactement la moitié des messages en échec.
Les valeurs exceptionnelles étaient zéro et cent, correspondant à aucune application basée sur le pourcentage et à une application complète. Certains intermédiaires traitaient également pct=0 comme un signal pour réécrire l'adresse From visible afin d'éviter des échecs en aval.
Utilisez les rapports pour corriger les échecs légitimes avant de modifier la politique via none, quarantine et reject. La valeur none n'exprime aucune préférence de traitement. La valeur quarantine signale les échecs comme suspects. La valeur reject identifie une utilisation non autorisée du domaine. Le guide de politique explique le déploiement.
Un résultat aligné positif prouve-t-il que le message est sûr ?
Un résultat aligné positif prouve l'utilisation autorisée du domaine From, sans établir si le message est souhaité ou sûr.
Un récepteur peut rejeter ou mettre en quarantaine un message ayant réussi en appliquant ses propres règles de filtrage. Il peut également accepter un message en échec lorsque d'autres éléments justifient la livraison.
L'autorisation de domaine et la réputation de l'expéditeur, l'évaluation du trafic d'un expéditeur par le récepteur, répondent à des questions différentes. Vérifiez les deux lors d'une investigation de livraison.
En bref
L'authentification doit correspondre au domaine visible.
SPF et DKIM peuvent réussir pour des domaines non liés, c'est pourquoi DMARC exige un résultat aligné pour le domaine dans From.
L'une ou l'autre méthode alignée peut fournir un résultat positif.
Une signature DKIM alignée intacte peut préserver un résultat DMARC positif lorsque le transfert casse SPF.
Les modes souple et strict utilisent des règles de correspondance différentes.
L'alignement souple accepte un domaine organisationnel commun. L'alignement strict exige des domaines identiques.
La découverte de domaine et l'application de la politique sont des mécanismes distincts.
Le RFC 9989 utilise un parcours d'arborescence DNS pour découvrir les limites de domaine. Il exclut le tag de pourcentage, jugé peu fiable, de son format de politique.