Un message n'a pas besoin des deux SPF et DKIM produire un niveau de message DMARC passer. Il lui faut au moins un parcours qualifiant : SPF doit réussir et s'aligner, ou au moins un Signature DKIM doit passer et aligner.
Cette règle est facile à simplifier à l’extrême. Une transmission au niveau du message n’est pas la même chose qu’un déploiement complet d’authentification de domaine. Il ne remplace pas non plus les exigences distinctes des fournisseurs de boîtes aux lettres qui peuvent exiger que les expéditeurs configurent à la fois SPF et DKIM . Conservez le résultat du protocole, le programme d’envoi et les exigences du fournisseur sous forme de trois décisions distinctes.
Appliquer correctement la règle booléenne
Pour un message bien formé avec une politique valide applicable et des vérifications complétées, RFC 9989 §5.3.5 donne la règle de validation au niveau du message :
DMARC pass = ( SPF passe ET l'identité SPF s'aligne) OU (une signature DKIM passe ET son domaine d= s'aligne)Le mot OU compte. L'une ou l'autre branche peut satisfaire la condition au niveau du message. Le mot ET compte à l’intérieur de chaque branche. Une passe d'authentification brute sans alignement ne le satisfait pas.
L'alignement compare le domaine authentifié avec le domaine d'auteur dans From. Le mode strict nécessite une égalité exacte sous RFC 9989 §3.2.10.2. Le mode détendu utilise la relation de découverte dans RFC 9989 §4.10.2.
Comparez les trois cas essentiels
Les exemples fictifs suivants utilisent From orders@example.com. Il s’agit de cas pédagogiques synthétiques et non de trafic client capturé.
- Cas : A ; SPF : Passer pour example.com , aligné ; DKIM : Échec ; Résultat DMARC : Réussite ; Raison : La branche SPF se qualifie
- Cas : B ; SPF : Échec ; DKIM : Passer avec d=example.com, aligné ; Résultat DMARC : Réussite ; Raison : La branche DKIM se qualifie
- Cas : C ; SPF : Pass pour vendor.example.net , non aligné ; DKIM : Passer avec d=vendor.example.net, non aligné ; Résultat DMARC : Échec ; Raison : Aucune des deux succursales n’est admissible
Le cas A montre pourquoi un échec DKIM ne signifie pas automatiquement un échec DMARC . Le cas B montre pourquoi un transfert qui perturbe SPF peut toujours laisser un chemin DKIM aligné. Le cas C montre pourquoi deux résultats bruts verts peuvent toujours produire un échec DMARC .
Ne lisez pas ces exemples comme des objectifs de conception. Dépendre uniquement du chemin de l'enveloppe peut être fragile lorsque les messages sont transférés. Dépendre uniquement du DKIM peut être fragile lorsque les intermédiaires modifient le contenu signé. La résilience vient généralement de la configuration correcte des deux mécanismes, puis de la vérification du comportement des messages réels.
Distinguer la validation de la pleine participation
La validation au niveau du message indique si le message reçu comporte au moins un chemin aligné de passage. Un programme de domaine mature pose des questions plus larges : les messages légitimes sont-ils systématiquement couverts, les deux mécanismes sont-ils déployés comme requis, la politique est-elle appropriée, les rapports sont-ils examinés et les propriétaires opérationnels corrigent-ils les exceptions ?
RFC 9989 définit également la pleine participation pour un domaine de manière plus large que le résultat de validation d'un seul message. En particulier, un rejet de publication de domaine NE DOIT PAS s'appuyer uniquement sur SPF et DOIT appliquer des signatures DKIM valides sous RFC 9989 §7.4. La pleine participation est précisée dans RFC 9989 §8. Ne transformez pas la règle OR au niveau du message en un conseil selon lequel un mécanisme peut être ignoré dans l’ensemble de l’organisation.
La même distinction est importante lorsqu'un fournisseur de boîte aux lettres publie les exigences de l'expéditeur. Par exemple, Consignes d'expédition de Google nécessitent une configuration SPF , DKIM et DMARC pour expéditeurs en masse aux comptes Gmail personnels. Un fournisseur peut exiger que SPF et DKIM soient configurés pour une catégorie d'expéditeur même si la validation DMARC pour un message particulier utilise toujours la règle du chemin aligné. Le non-respect de l'exigence distincte du fournisseur ne peut être contesté en citant l'expression booléenne DMARC .
Diagnostiquer la branche défaillante avant de modifier la stratégie
Lorsqu'un message légitime échoue DMARC , capturez :
- Preuve : Du domaine ; Question : Quel domaine d'auteur est protégé ?
- Preuve : résultat SPF et domaine évalué ; Question : Le chemin de l'enveloppe a-t-il réussi et a-t-il été aligné ?
- Preuve : chaque résultat DKIM et domaine d= ; Question : Des signatures ont-elles été adoptées et alignées ?
- Preuve : modes d'alignement ; Question : Une comparaison stricte ou assouplie a-t-elle été appliquée ?
- Preuve : résultat du récepteur de confiance ; Question : Où la conclusion a-t-elle été produite ?
Réparez ensuite la branche que l'expéditeur est censé utiliser. Pour SPF , cela peut impliquer un domaine d'enveloppe personnalisé et un chemin d'envoi autorisé. Pour DKIM , cela peut impliquer d'activer la signature avec le domaine de l'organisation et de vérifier un message représentatif reçu. N’affaiblissez pas la politique simplement parce que la table d’identité n’a pas encore été constituée.
Comprendre le courrier indirect
Comme décrit dans RFC 7208 §10.3, le transfert change souvent la source de connexion, de sorte que SPF peut échouer au niveau du récepteur final même s'il est passé plus tôt. Une signature DKIM alignée survivante peut toujours fournir un chemin de qualification. Les modifications apportées au contenu signé peuvent invalider DKIM sous RFC 6376 §3.7, tandis que d'autres comportements intermédiaires peuvent affecter les deux chemins.
DMARC ne garantit pas que chaque flux indirect légitime conservera un chemin qualifiant. Évaluez l’itinéraire réel, les preuves du destinataire et les besoins commerciaux. Un séquestre peut également appliquer la politique locale et d’autres preuves pour décider de la disposition.
Évitez quatre conclusions courantes
Tout d’abord, ne dites pas que SPF et DKIM doivent réussir pour que chaque message passe DMARC . Ce n'est pas la règle au niveau du message.
Deuxièmement, ne dites pas qu’un seul mécanisme suffit pour l’ensemble du domaine d’envoi. Un seul exemple passager ne permet pas d’établir la couverture, la résilience ou la pleine participation.
Troisièmement, n’assimilez pas la réussite au placement dans la boîte de réception. L'authentification est un élément permettant de recevoir des décisions.
Quatrièmement, n’assimilez pas l’échec à une fraude avérée. Un service légitime peut être mal configuré, tandis qu'un domaine appartenant à un attaquant peut authentifier son propre courrier.
Utilisez le guide de la chaîne d'identité des e-mails pour recueillir les preuves et les Guide SPF , DKIM et DMARC de placer le résultat dans le programme plus large.
Conserver la conclusion dans les preuves
Pour le luminaire booléen, évaluez chaque branche comme étant réussie ET alignée avant de les combiner avec OU. Une signature qui échoue ne peut pas emprunter l’alignement d’une autre signature, et une réussite SPF ne peut pas emprunter l’alignement d’un autre domaine. Si les vérifications DNS requises échouent, RFC 9989 §5.3.6 sépare cette erreur d’un résultat normal de réussite/échec. Aucun véritable vérificateur n’a été exécuté.