Traitez séparément la vérification de l’adresse et l’authentification
Une adresse d'expéditeur vérifiée prouve l'accès à cette boîte aux lettres ; cela ne prouve pas en soi qu'une newsletter s'est alignée DKIM ou SPF. Commencez par un domaine contrôlé par votre organisation, une adresse d'expéditeur approuvée, un accès administratif DNS et un propriétaire pour la campagne. Inventoriez les autres services qui envoient déjà pour le domaine avant de modifier ses enregistrements.
Le flux de travail de domaine documenté de GetResponse se trouve sous Profil > E-mails et domaines. DKIM personnalisé utilise une clé et un identifiant générés dans le compte. N'utilisez pas de générique sélecteur à partir d'un tutoriel ou d'une clé exportée depuis un autre compte. La question pertinente est de savoir quel domaine signe le message réel, et non de savoir si une adresse d'expéditeur a été ajoutée avec succès.
Séparez ce travail de domaine de messagerie de la configuration du domaine du site Web et de la page de destination. Redirection serveurs de noms ou la connexion à un site Web n'est pas nécessaire simplement pour publier un enregistrement d'authentification sur l'hôte DNS existant.
Générer et publier l'enregistrement DKIM
Dans Adresses e-mail, ouvrez le menu Actions du domaine, choisissez Afficher Enregistrements TXT et Authentifiez votre domaine avec DKIM . Copiez l'identifiant et la clé affichés. La documentation propose également un Clé de 2048 bits et avertit que la confirmation de la génération invalide la clé et l'identifiant existants. Planifiez cette action comme une rotation coordonnée, et non comme une préférence d'affichage inoffensive.
Avant la rotation, enregistrez le sélecteur actuel et l'état de signature, identifiez la personne qui peut publier DNS rapidement et convenez de la manière dont les campagnes seront suspendues ou récupérées en cas d'échec de la validation. Ne présumez pas qu’une ancienne clé reste utilisable une fois que le produit l’a invalidée. Résolvez tout chevauchement ou capacité de restauration avec le fournisseur avant de dépendre de lui.
Publiez le propriétaire TXT renvoyé et la valeur complète sur le service DNS faisant autorité. Vérifiez les règles de suffixe de l'éditeur et la gestion des TXT longs. Une clé tronquée, un caractère de sélection manquant ou un suffixe de domaine dupliqué peuvent rendre inutilisable un enregistrement apparemment enregistré. Si l’interface utilisateur ne peut pas conserver la totalité de la valeur, obtenez des conseils d’hôte DNS pris en charge plutôt que de diviser la clé en enregistrements indépendants.
Vérifiez la configuration automatique avant de l'approuver
GetResponse documente également un flux automatique à l'aide d'Entri. Une fois l'adresse de l'expéditeur ajoutée et vérifiée, choisissez Authentifier dans le menu du domaine. Le flux peut afficher les enregistrements de texte proposés avant de continuer, détecter le fournisseur DNS et demander la connexion et la confirmation appropriées. La configuration manuelle reste une alternative si l'intégration ne peut pas terminer le travail.
Le processus automatique est documenté pour ajouter DKIM personnalisé, un enregistrement SPF TXT et un p=none DMARC politique lorsqu’une politique correcte n’existe pas déjà. Inspectez les modifications proposées par rapport aux enregistrements existants avant de les autoriser. L'automatisation ne supprime pas la nécessité de préserver une politique appliquée, évitez les doublons Enregistrements SPF ou examinez les autorisations accordées à une intégration DNS .
Ne présumez pas qu’une confirmation d’intégration réussie prouve que chaque enregistrement demandé a été publié auprès du propriétaire des droits. Comparez ensuite les réponses faisant autorité et conservez l’ensemble de modifications exact. Si le processus échoue en cours, inspectez ce qui a déjà changé avant de réessayer, afin qu'une deuxième tentative ne crée pas de conflits ou n'obscurcisse pas la récupération.
Comprendre la décision distincte SPF
La page SPF de GetResponse indique que son domaine d'envoi a déjà SPF et que l'ajout un enregistrement au domaine visible-from du client n'est pas nécessaire simplement d'envoyer via le service. Il fournit des informations SPF affichées sur le compte pour les clients qui choisissent de les configurer. Utilisez ces valeurs actuelles plutôt que de deviner une inclusion universelle.
La distinction du protocole est importante : SPF évalue le expéditeur d'enveloppe domaine, pas le visible Depuis l'en-tête. Une autorisation ajoutée à example.com ne peut pas fabriquer d'alignement si le message utilise réellement un domaine d'enveloppe non lié. Une signature DKIM personnalisée valide alignée sur example.com peut fournir le chemin DMARC indépendamment. Vérifiez ce que fait le message avant de traiter une modification SPF racine comme une réparation.
Lorsqu’une mise à jour légitime SPF est nécessaire, examinez la politique existante et son coût de recherche DNS. Conservez un seul enregistrement SPF candidat valide chez ce propriétaire et conservez les autres expéditeurs approuvés. Ne concaténez pas deux stratégies v=spf1 complètes et ne créez pas une deuxième stratégie TXT à côté de la première.
Vérifier la campagne réelle
Recherchez sur chaque serveur faisant autorité le propriétaire exact DKIM et comparez la valeur publique complète avec le compte. Répétez la validation du produit le cas échéant, en tenant compte des réponses précédemment mises en cache une fois que la publication faisant autorité est correcte. Envoyez ensuite une newsletter contrôlée via le flux de travail GetResponse prévu à un destinataire autorisé ayant accès aux en-têtes bruts reçus.
Capturez le visible depuis, le domaine de l'enveloppe, chaque DKIM d= et s=, ainsi que les résultats d'authentification du destinataire de confiance. Exemple synthétique : un message contient From news@example.com , SPF passe pour une enveloppe appartenant au fournisseur et DKIM passe avec d=example.com. Le pass SPF appartenant au fournisseur n'est pas aligné sur example.com , mais le pass DKIM du domaine exact peut satisfaire DMARC . Si le domaine de signature appartient au fournisseur, ne l'appelez pas succès de domaine personnalisé simplement parce que DKIM lui-même a réussi.
Testez chaque domaine sensiblement différent et le flux de travail d'envoi. Une newsletter envoyée à partir d'une adresse différente de celle de l'échantillon d'acceptation peut exercer une configuration de domaine différente. Un test DNS réussi ne remplace pas cette vérification au niveau de la route.
Diagnostiquer et conserver un dossier de récupération
Si la clé est manquante dans DNS , réparez le propriétaire ou la valeur exacte. Si la clé est correcte mais que la signature est absente ou utilise un autre domaine, vérifiez l'expéditeur sélectionné et la configuration du produit. Si l'authentification réussit mais que le placement est médiocre, étudiez séparément le consentement, la réputation, le contenu et la politique du destinataire ; DKIM ne garantit pas le placement dans la boîte de réception.
Conservez l'ancienne configuration, les modifications proposées, les modifications réelles, le résultat de la validation et les preuves du message. N'affaiblissez pas une politique DMARC à l'échelle du domaine pour masquer un échec de rotation. Ce guide est basé sur une documentation propriétaire conservée et une interprétation synthétique, et non sur un locataire GetResponse en direct ou une campagne livrée. L'acceptation de la production nécessite les preuves actuelles de l'administrateur et l'approbation humaine.
Décidez de ce que signifie la récupération après l'invalidation
Pour le cas de rotation écrit GR-01, supposons que l'administrateur ait confirmé la génération de l'option 2048 bits, que le nouvel identifiant de compte soit démo-nouveau et que la zone ne contienne toujours que l'ancien démo. Aucune clé publique actuelle ni signature reçue n’a été observée. Le propriétaire de la campagne suspend la version concernée pendant que le propriétaire DNS obtient et publie la valeur exacte nouvellement générée chez son propriétaire requis. La republication d'une ancienne valeur n'est pas une hypothèse de récupération prise en charge après l'invalidation documentée ; renseignez-vous auprès du fournisseur sur tout état de signature récupérable avant de vous y fier. Clôturez seulement après une comparaison faisant autorité et une campagne contrôlée dont d=/s= réel et le résultat fiable sont acceptés. Aucune génération de clé, modification DNS ou envoi n'a eu lieu pour cet exemple.
Préserver la limite d’application
La section 7.4 RFC 9989 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.