Résolution des problèmes liés aux e-mails sortants dans DMARC sur les infrastructures cloud avec SendGrid

Si les e-mails sortants de votre boutique (confirmations de commande, réinitialisations de mot de passe et e-mails transactionnels similaires envoyés via l’intégration SendGrid intégrée d’Adobe) échouent lors des contrôles DMARC, sont marqués comme spam ou sont rejetés par les serveurs de messagerie des destinataires, il existe deux causes possibles distinctes. Vérifiez laquelle s’applique à vous avant d’apporter des modifications DNS.

Description description

Environnement

Problème/Symptômes

Avant de commencer : vérifiez qu’il s’agit bien d’un problème d’authentification.

Tous les échecs de diffusion signalés avec la surveillance DMARC ne sont pas causés par DMARC/DKIM/SPF. Les rebonds côté destinataire (boîte aux lettres pleine, liste grise, limitation des adresses IP) semblent similaires dans les rapports, mais n’ont rien à voir avec l’authentification de domaine. Vérifiez la raison spécifique du bounce/bloc dans votre flux d’activité SendGrid avant de supposer que ce guide s’applique.

Comment confirmer chaque symptôme

Rebonds ou rejets avec erreurs liées à DMARC : ouvrez la source brute du message rebond ou rejeté dans votre client de messagerie et vérifiez l’en-tête Authentication-Results.

Exemple:

Authentication-Results: mx.google.com;
       dkim=fail;
       spf=fail (google.com: domain of bounce@mail.adobe.com does not designate XXX.XXX.XXX.XXX as permitted sender);
       dmarc=fail (p=REJECT sp=REJECT dis=REJECT) header.from=adobe.com

Que rechercher un résultat dmarc=fail dans cet en-tête confirme que le rejet est lié à DMARC et non à un rebond sans rapport (boîte aux lettres pleine, liste grise, limitation des adresses IP).

Résolution resolution

Pour résoudre ce problème, procédez comme suit :

Étape 1 : vérifier si votre domaine publie déjà un enregistrement DMARC

Exécutez cette opération pour vérifier si une politique existe déjà :

dig TXT _dmarc.yourdomain.com +short

Que rechercher : si une politique existe, une valeur de TXT entre guillemets commençant par v=DMARC1; est renvoyée (par exemple : "v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com"). Si la commande ne renvoie rien, aucun enregistrement DMARC n’est publié pour ce domaine. Exemple validé : l’interrogation de _dmarc.adobe.com ne renvoie actuellement rien, ce qui signifie que adobe.com n’a aucun enregistrement DMARC publié.

Scénario A : Un enregistrement DMARC existe déjà (le plus courant)

Si un enregistrement est renvoyé, votre domaine possède déjà une politique DMARC, généralement définie indépendamment par l’équipe informatique ou de sécurité de votre organisation, sans rapport avec Adobe Commerce. Dans ce cas, les échecs de DMARC signifient presque toujours que l’authentification de domaine d’SendGrid (DKIM et SPF) n’est pas encore configurée ou alignée pour votre domaine d’envoi, mais pas que quelque chose ne va pas avec votre enregistrement DMARC lui-même.

Résolution : consultez la documentation du service de messagerie SendGrid pour demander l’authentification de domaine DKIM et SPF via un cas d’assistance. Une fois que les enregistrements DKIM/SPF d’SendGrid sont correctement ajoutés à votre DNS et alignés sur votre domaine d’envoi, votre politique DMARC existante commencera à transmettre . Aucune modification de l’enregistrement DMARC lui-même n’est nécessaire.

Les valeurs d’enregistrement DNS peuvent changer au fil du temps : ne réutilisez pas les valeurs CNAME/TXT d’un ancien dossier de support ou d’un document interne. Les affectations de sous-compte SendGrid peuvent être réémises. Ainsi, un enregistrement correct dans le passé peut ne plus correspondre à votre configuration SendGrid actuelle. Demandez toujours les valeurs actuelles via un nouveau cas d’assistance plutôt que de réappliquer les valeurs historiques.

S’il s’agit d’un environnement d’évaluation ou hors production : SendGrid est activé par défaut pour l’évaluation et la production, mais l’authentification de domaine DKIM/SPF est généralement demandée pour la production uniquement et n’est jamais suivie pour l’évaluation. Il peut sembler fonctionner pendant des mois (en invoquant une politique de DMARC laxiste ou absente), puis échouer dès que votre organisation renforce l’application de DMARC. Si vous constatez uniquement des échecs dans l’évaluation lorsque la production est correcte, demandez une authentification DKIM/SPF pour l’environnement d’évaluation en particulier - ne supposez pas qu’elle était déjà couverte par la demande de production.

Vérification de la propagation des enregistrements DKIM/SPF

Une fois l’authentification de domaine DKIM/SPF demandée et appliquée, vérifiez que les enregistrements se sont réellement propagés dans le DNS avant de tester à nouveau l’alignement de DMARC ou de rouvrir un dossier. L’authentification de domaine d’SendGrid publie trois enregistrements CNAME pour votre sous-domaine d’envoi : un pour le branding des liens (em) et deux pour les clés de signature DKIM (s1._domainkey, s2._domainkey).

dig CNAME em.yourdomain.com +short
dig CNAME s1._domainkey.yourdomain.com +short
dig CNAME s2._domainkey.yourdomain.com +short

Que rechercher : chaque commande doit renvoyer une cible CNAME se terminant par .sendgrid.net. Si une commande ne renvoie rien, cet enregistrement n’a pas encore été ajouté ou n’a pas encore été propagé. Exemple validé : l’interrogation de s1._domainkey.adobe.com et s2._domainkey.adobe.com renvoie :

s1.domainkey.uXXXXXXX.wlXXX.sendgrid.net.
s2.domainkey.uXXXXXXX.wlXXX.sendgrid.net.

Un résultat vide, renvoyé par la même vérification par rapport à em.adobe.com dans cet exemple, signifie que cet enregistrement particulier n’est pas configuré. Demandez-la explicitement, plutôt que de supposer qu’elle a été incluse avec une requête DKIM/SPF précédente. Si un enregistrement ne se résout toujours pas 24 à 48 heures après son ajout, faites un suivi sur le dossier d’assistance existant plutôt que d’en ouvrir un nouveau.

Scénario B : aucun enregistrement DMARC n’existe

Si la commande ci-dessus ne renvoie rien, votre domaine n’a aucune politique DMARC. Dans ce cas, en plus de configurer DKIM/SPF selon le scénario A, vous devez également publier un enregistrement DMARC. Démarrez en mode surveillance, et non en mode application :

_dmarc.yourdomain.com   TXT   "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; pct=100"

Ne passez pas directement à p=quarantine ou p=reject avant de confirmer vos propres passes d’e-mail légitimes. En effet, cela peut entraîner le rejet silencieux de votre propre e-mail transactionnel par les serveurs de destinataires.

Lecture connexe