Commencez par la configuration actuelle du domaine
L'article d'aide de Get a Newsletter décrit une configuration plus récente qui a remplacé son ancienne sélecteur et les instructions root-SPF. Utilisez la configuration actuelle du domaine d'envoi plutôt que de combiner tous les enregistrements trouvés dans les messages d'intégration précédents. Le fournisseur a modifié cet arrangement en janvier 2023 afin que les clients n'aient plus besoin d'ajouter son ancienne inclusion à la leur. Enregistrement SPF pour cette configuration.
Avant d'apporter des modifications, identifiez le domaine From utilisé par la newsletter, le propriétaire du compte et l'hôte DNS faisant autorité. Inventorier les enregistrements existants aux noms demandés. Confirmez que vous contrôlez le domaine et que l'adresse d'envoi est appropriée pour la campagne. Un domaine de boîte aux lettres gratuit que vous n'administrez pas ne peut pas être configuré en ajoutant des enregistrements ailleurs.
L’objectif est de vérifier le parcours réel de la newsletter. L'organisation peut également envoyer du courrier aux employés, des factures ou des notifications de candidature en utilisant le même domaine parent. Ces routes conservent leurs propres exigences d'authentification ; l'intégration de ce service de newsletter n'est pas une raison pour effacer leur SPF autorisations.
Publier l'ensemble CNAME documenté
La page d'aide actuelle répertorie trois CNAME : gan1. _domainkey à gan1._domainkey.gansend.com , gan2. _domainkey vers gan2._domainkey.gansend.com et gan vers mta.gansend.com . Confirmez-les par rapport aux instructions du compte courant et du fournisseur avant la publication. Utilisez les règles de noms relatifs de l'éditeur DNS et conservez les noms de domaine cibles exacts.
Les deux entrées _domainkey sont des recherches de sélecteur ; le troisième est un espace de noms distinct utilisé par la configuration la plus récente. Ne placez pas les trois chez un seul propriétaire, créez des clés TXT à la place des alias documentés ou placez un CNAME à côté des enregistrements contradictoires. Si gan dessert déjà une autre application, mettez en pause et résolvez la collision avec le fournisseur plutôt que de le déplacer silencieusement.
Pour un domaine synthétique example.com , gan1. _domainkey est destiné à être publié sur gan1._domainkey.example.com . Un éditeur qui ajoute automatiquement la zone ne doit pas recevoir un nom qui devient gan1._domainkey.example.com.example.com . Notez les noms complets prévus avant de sauvegarder, puis interrogez ces noms par la suite.
Ne réintroduisez pas la recette SPF retirée
La page d'aide identifie l'ancienne newsletter getanewsletter. Configuration _domainkey et l'ancienne instruction include:spf.gansend.com . Il s'agit d'un contexte historique et non d'instructions pour les ajouter à côté de la nouvelle configuration. N'utilisez pas un ancien blog ou une liste de contrôle copiée pour remplacer la configuration actuelle du fournisseur.
De même, ne supprimez pas un enregistrement existant sans comprendre son utilisation restante. Le retrait d'un ancien sélecteur nécessite de confirmer qu'aucun message actif n'en dépend encore. La suppression d’une inclusion SPF nécessite de revoir la politique complète et l’itinéraire actuel du service. Préservez tous les expéditeurs légitimes non liés ainsi que le comportement final prévu de la stratégie.
La raison du protocole est simple : SPF évalue le domaine de l'enveloppe SMTP . L’ajout d’une inclusion à un autre domaine visible-From ne modifie pas automatiquement cette évaluation. DKIM et SPF alignement doit être évalué à partir des identités réelles des messages, et non déduit de la présence du nom du fournisseur dans une racine Enregistrement TXT.
Valider dans le compte et dans DNS
L'itinéraire documenté du compte est l'icône de profil, l'expéditeur, Afficher les détails et Vérifier l'état. L'article d'aide suggère de vérifier après une heure. Considérez cela comme une orientation opérationnelle plutôt que comme une garantie que chaque résolveur a supprimé les données plus anciennes. Vérifiez d’abord que les enregistrements faisant autorité sont corrects ; l'attente ne peut pas corriger une étiquette mal saisie.
Interrogez chaque propriétaire CNAME auprès du service DNS faisant autorité et vérifiez sa cible. Suivez le chemin de résolution approprié lors du diagnostic d’une recherche de clé. Conservez les réponses et les horodatages sans prétendre à une livraison réussie de la newsletter à partir du seul DNS . Si une cible CNAME est résolue mais que la validation du compte échoue toujours, comparez le domaine exact saisi dans le compte et le propriétaire réel publié.
Une vérification d'état réussie établit la vérification de configuration effectuée par le service. Cela ne prouve pas que chaque adresse de campagne utilise le même domaine authentifié. Enregistrez chaque identité d'envoi que le propriétaire de la campagne a l'intention d'utiliser et vérifiez les messages représentatifs de l'itinéraire réel.
Prouver l’alignement avec une newsletter reçue
Envoyez une newsletter contrôlée à un destinataire de test autorisé et conservez le message brut. Enregistrer à partir du domaine d'enveloppe, des domaines et sélecteurs de signature DKIM , ainsi que du SPF , DKIM et du destinataire de confiance. DMARC résultats. Ne traitez pas les informations insérées par l'expéditeur Authentication-Results comme preuve du séquestre.
Interprétation synthétique : à partir de news@example.com , l'enveloppe utilise un sous-domaine de example.com et un valide Signature DKIM utilise d=example.com. Le domaine DKIM exact s'aligne. Le sous-domaine d'enveloppe peut satisfaire un alignement SPF détendu mais pas une correspondance exacte stricte avec example.com . Cet exemple n’est pas une mesure de l’utilisation par défaut de l’enveloppe ou du sélecteur de Get a Newsletter ; inspectez le vrai message plutôt que de remplir une réponse attendue.
Si seul un domaine DKIM appartenant au fournisseur réussit, vérifiez si la configuration du domaine personnalisé est active pour cet expéditeur. Si le sélecteur attendu est manquant, comparez la configuration du domaine expéditeur du compte et l'itinéraire des messages. Si l'authentification alignée réussit mais que le placement de spam persiste, évaluez séparément la réputation, le consentement, le contenu et le filtrage des destinataires.
Préserver les récupérations et les preuves
Conservez les enregistrements précédents, les nouvelles valeurs approuvées et le moment auquel le propriétaire de la campagne peut reprendre l'envoi. Mettez sur pause une campagne qui a échoué plutôt que d’affaiblir la politique DMARC de l’ensemble de l’organisation. En cas de restauration, restaurez uniquement la configuration affectée après avoir vérifié si la signature a déjà changé. Enregistrez le résultat du premier message après la récupération.
Ce guide conserve les instructions de première partie et fournit un raisonnement synthétique DNS et d'identité. Aucune validation de compte, modification DNS , campagne livrée ou mesure de locataire n'a été effectuée. L'acceptation de la production nécessite les réponses faisant autorité de l'administrateur et les preuves des messages reçus, suivies de la décision du propriétaire humain responsable.
Résolvez un nom de gan occupé sans interrompre un autre service
Le cas écrit GAN-01 suppose que le From prévu est news@example.com , les deux noms de sélecteur gan1/gan2 ne sont pas utilisés, mais gan.example.com a déjà un Un record appartenant à une application indépendante. La configuration actuelle à trois CNAME ne peut pas être terminée sur ce nom occupé sans conflit. Laissez l'application intacte et demandez au propriétaire du compte de newsletter et à l'administrateur DNS de résoudre un plan d'espace de noms pris en charge avec le fournisseur. Aucun verdict de domaine personnalisé n'est disponible : les résultats de l'enveloppe et DKIM restent inconnus. Ne déduisez pas une étiquette alternative et ne restaurez pas la recette Root-SPF retirée. Il s’agit d’une collision fictive, et non d’une recherche exécutée, d’une demande d’assistance ou d’une campagne.
Préserver la limite d’application
RFC 9989 La section 7.4 requiert DKIM valide, et non SPF seul, pour les domaines publiant p=reject, et met en garde contre l'interopérabilité du courrier indirect et des listes de diffusion. Un seul test réussi de message direct ne prouve pas que chaque voie légitime est prête à faire l’objet d’une politique plus forte. Conserver la protection approuvée existante tout en diagnostiquant l’écart réel ; tout changement de politique nécessite sa propre décision.