En bref
LetsDMARC affiche des échecs qui proviennent de services de sécurité de la messagerie et de serveurs de redirection appartenant à vos destinataires. Derrière ces échecs se trouvent des copies de messages que vous avez envoyés correctement et qu'une autre partie a remis une seconde fois. L'échec ne vient pas de vos systèmes et n'est pas une erreur de LetsDMARC, et ce n'est pas une raison pour retarder le passage à la stratégie reject.
Avant de commencer
- Un accès au tableau de bord LetsDMARC pour le domaine que vous consultez.
- La liste des sources qui envoient réellement du courrier pour votre domaine, par exemple votre passerelle, votre tenant, votre plateforme marketing et votre outil de tickets.
- L'état DKIM actuel de chacune de ces sources.
Fonctionnement
Votre message quitte votre passerelle et passe SPF, DKIM et DMARC à la première remise. Le serveur destinataire l'accepte, et c'est cette remise qui compte pour vous et pour votre destinataire.
Beaucoup de destinataires déplacent ensuite le message une seconde fois. Leur serveur le confie à un service de sécurité externe via un connecteur, une règle de transport ou une API, ou bien une règle de boîte aux lettres le redirige vers une autre adresse. Dans les deux cas le message est remis de nouveau, et cette seconde remise part d'une adresse IP qui appartient au service ou au serveur qui redirige.
Cette adresse ne figure pas dans votre enregistrement SPF, donc SPF échoue, et c'est normal, car vous n'avez jamais autorisé cet hôte à envoyer du courrier pour votre domaine. Si le service modifie aussi le message, par exemple en ajoutant une bannière d'avertissement, en réécrivant les liens ou en changeant l'objet, la signature DKIM se casse également. Sans SPF ni DKIM alignés, DMARC échoue.
Le système qui reçoit cette seconde copie envoie un rapport agrégé à votre domaine, car le domaine de l'en-tête From est toujours le vôtre. LetsDMARC lit ce rapport et affiche l'échec avec le nom du service comme source.
Symptômes
Sur la page DMARC reports by sources vous voyez des échecs provenant de noms d'hôtes que vous ne reconnaissez pas et que vous n'avez jamais configurés. Ils apparaissent aussi dans l'encadré Top 5 failure sources, et c'est en général là que la question commence. La liste complète se trouve dans le grand tableau Details en bas de la page, avec une ligne par source ayant envoyé du courrier avec votre domaine dans l'en-tête From.
Les noms de sources observés jusqu'ici sont cloud-sec-av.com, inkyphishfence.com, perception-point.io, shield.security, ppe-hosted.com, mimecast.com, sonicwall.com et oraclecloud.com. La liste continue de s'allonger, car elle dépend du produit acheté par chacun de vos destinataires.
Ces sources affichent une conformité proche de zéro, avec SPF et DKIM tous deux à zéro, tandis que vos propres plateformes d'envoi restent à quatre-vingt-dix-neuf ou cent pour cent. Leur volume représente une petite part de votre trafic total.
Quatre signes réunis vous indiquent que vous êtes dans ce cas.
| Ce qu'il faut regarder | Ce que vous voyez dans ce cas |
|---|---|
| Source | Un service de sécurité de la messagerie connu, ou un serveur qui redirige le courrier pour un destinataire |
| Header From | Le même domaine que vos sources légitimes, car le message est une copie du vôtre |
| Forwarded | Souvent une valeur supérieure à zéro. LetsDMARC la calcule par ses propres moyens, et elle n'est pas toujours à cent pour cent : parfois elle est plus basse, parfois elle reste à zéro même pour un service qui redirige à coup sûr. À lire comme un indice, pas comme une preuve |
| Volume | Conforme à votre trafic habituel vers ce destinataire, sans pic soudain |
Cause
L'échec est généré par celui qui effectue la seconde remise. Il n'est pas généré par vos serveurs, qui ont fait leur travail correctement lors de la première remise, et ce n'est pas une erreur de LetsDMARC, qui affiche seulement les rapports reçus des systèmes ayant reçu cette seconde copie.
Rien n'est cassé de votre côté. Aucun réglage, ni dans votre DNS, ni dans votre passerelle, ni dans LetsDMARC, ne transforme ces échecs en succès, car la remise qui échoue est faite par un hôte qui ne vous appartient pas et que vous ne contrôlez pas.
Solution
- Ouvrez le grand tableau Details en bas de la page et regardez la source en échec. S'il s'agit d'un service de sécurité de la messagerie ou d'un serveur de redirection de l'un de vos destinataires, il n'y a rien à faire.
- N'essayez pas de faire passer ces échecs. Chercher à les corriger est la seule voie qui mène à un changement dangereux, et la bonne approche consiste à ne pas les compter quand vous jugez l'état de votre domaine.
- N'ajoutez jamais les adresses IP ni l'include SPF de ces services à votre propre enregistrement SPF.
- Assurez-vous que chacune de vos sources légitimes signe avec une clé DKIM alignée. Une signature intacte survit à une redirection simple, donc une partie de ces secondes remises peut encore passer DMARC grâce au seul DKIM.
- Passez à la stratégie reject une fois que vos sources légitimes sont conformes. Ces échecs à eux seuls ne sont pas une raison d'attendre.
Ajouter le service de sécurité d'un destinataire à votre enregistrement SPF est le seul changement qui aggrave la situation, car dès cet instant toute personne utilisant cette plateforme peut envoyer du courrier avec votre domaine et passer SPF.
Vérifier le résultat
Filtrez le tableau Details sur vos propres sources d'envoi et vérifiez que chacune est conforme, avec SPF ou DKIM aligné. C'est ce chiffre qui décide si vous êtes prêt pour reject.
Regardez ensuite de nouveau les sources en échec. Si elles sont toutes des services de sécurité ou des serveurs de redirection, et si le volume reste conforme à votre trafic habituel, votre domaine est en bon état même si le compteur d'échecs continue d'avancer.
Limites connues
- Votre première remise n'est jamais touchée. Le message que vous envoyez passe DMARC, la stratégie reject ne le concerne donc pas, il n'est pas bloqué et il n'est pas compté comme un échec. Les échecs que vous voyez ne concernent que la seconde remise.
- Ce qui arrive à la seconde copie ne peut pas être prévu de votre côté. Cela dépend de la façon dont le destinataire a configuré le service, de ce que le service fait au message et du système qui prend la décision finale, et un service mal configuré peut faire rejeter cette copie.
- SPF ne peut pas survivre à la seconde remise, car le message part d'un hôte que vous n'avez pas autorisé. SPF est conçu pour fonctionner ainsi.
- DKIM survit à une redirection simple, mais il se casse dès que le service modifie le message.
- Ces rapports continueront d'arriver tant que vos destinataires utiliseront ces services. Vous ne pouvez pas les arrêter de votre côté.