Portée et configuration spécifique au fournisseur
La vérification de l'expéditeur des campagnes par e-mail est un flux de travail différent de l'hébergement d'un site Web ou de la publication d'enregistrements DNS arbitraires. Le guide Squarespace actuel indique que les domaines achetés par Squarespace et les domaines migrés depuis Google Domains sont automatiquement vérifiés. Les domaines tiers nécessitent les enregistrements affichés par les campagnes par e-mail. Vérifiez la configuration réelle de l'expéditeur même lorsque le site Web fonctionne.
Ouvrez les paramètres de la campagne e-mail, ajoutez le nom de l'expéditeur et l'adresse e-mail si nécessaire, puis terminez la vérification du code de la boîte de réception. Sous Détails de l'expéditeur, choisissez Authentifier. La fenêtre fournit un CNAME et Enregistrement TXT. Le documenté DKIM CNAME est un espace carré. _domainkey pointant vers squarespace-domainkey.squarespace-mail.com ; utilisez les valeurs réellement affichées dans le compte. L'enregistrement TXT se trouve à _dmarc et sa valeur Data provient de cette fenêtre. Examiner un domaine existant à l'échelle DMARC politique avant de la modifier. Ne publiez pas de concurrents Enregistrements DMARC ou affaiblir une politique établie simplement pour reproduire un exemple de configuration.
Publiez via l’hôte DNS réel. Pour Serveur de noms Connect, Squarespace décrit les domaines gérés par des tiers, Modifier, les paramètres DNS et les enregistrements personnalisés. Pour DNS Connect, utilisez le fournisseur externe. Après l'enregistrement, vérifiez si le domaine n'est pas authentifié et disparaît des détails de l'expéditeur. Le guide autorise jusqu'à 48 heures de résolution, ce qui est une estimation opérationnelle plutôt qu'une preuve de propagation universelle.
Un changement important par rapport aux anciennes instructions est que Squarespace a supprimé l'exigence d'enregistrement SPF de ce flux de travail de vérification. N'ajoutez pas de Squarespace obsolète SPF inclure tiré d'un autre tutoriel. Le guide prévient également qu'un p=reject le domaine ne peut pas utiliser ces informations d'expéditeur tant que la vérification n'est pas terminée. Préservez cette politique et terminez l’authentification plutôt que de considérer l’application comme un défaut.
La décision qui compte
Testez un itinéraire de campagne réel après la vérification du domaine, en particulier lorsque le domaine possède déjà Application DMARC.
Vérifier les enregistrements publiés et le chemin d'envoi réel
Enregistrez le propriétaire du changement, le produit d'envoi, le domaine, la fenêtre de maintenance approuvée et les réponses DNS antérieures avant de procéder à la modification. Obtenez les valeurs d'enregistrement actuelles à partir du compte nommé ou du flux de travail du fournisseur documenté. Séparez les valeurs fournies par le fournisseur des choix contrôlés par votre organisation, tels que la stratégie DMARC et les destinataires des rapports. Les boîtes aux lettres MX existantes, les enregistrements TXT de vérification sans rapport et les sélecteurs DKIM actifs ne sont pas des candidats au nettoyage simplement parce qu'un nouveau service est ajouté.
Interrogez les serveurs de noms faisant autorité pour chaque propriétaire exact et type d'enregistrement après la publication. Enregistrez l'heure de la requête, le serveur qui répond et la réponse complète. Comparez les chaînes TXT comme une valeur logique où la réponse DNS les divise en chaînes de caractères. Vérifiez les cibles CNAME ainsi que l'alias de départ. Comparez ensuite une réponse de résolution récursive pour identifier les différences de mise en cache. Une validation réussie du fournisseur constitue une preuve utile de la configuration, mais elle ne permet pas d'établir ce qu'un destinataire réel a reçu.
Envoyez uniquement un test autorisé à un destinataire contrôlé en utilisant l'itinéraire de produit prévu. Conserver le message brut et le système de réception de confiance Authentication-Results. Enregistrez le visible du domaine, SMTP COURRIER DE ou observé Return-Path domaine, chaque valeur DKIM d= et s=, les résultats SPF et DKIM et le résultat DMARC du récepteur. Une vérification SPF ou DKIM réussie prend en charge DMARC uniquement lorsque son domaine authentifié s'aligne sur le domaine De visible dans le cadre de la stratégie applicable. Répondre à et un nom d’affichage de marque ne sont pas des identités d’alignement. RFC 7208 , RFC 6376 et RFC 9989 fournissent la base protocolaire de ces distinctions.
Feuille de travail d'acceptation, limites de récupération et de preuves
Il s'agit d'une feuille de travail d'acceptation originale, et non d'un rapport de tests en direct. Marquez chaque porte en attente jusqu'à ce que des preuves existent : étendue du compte confirmée ; DNS précédent capturé ; nouveau propriétaire/type/valeur exact publié ; vérification du fournisseur terminée ; itinéraire prévu exercé ; identités reçues enregistrées ; authentification alignée confirmée ; les autres expéditeurs ne sont pas affectés. Attribuez une personne et un dossier de preuves à chaque porte. Une porte rouge bloque le déploiement même lorsque le tableau de bord du fournisseur est vert.
Si un test échoue, distinguez d'abord la publication manquante, les données obsolètes mises en cache, la configuration du fournisseur inactif, la mauvaise route sortante et l'authentification non alignée. Corrigez le moindre défaut démontré et testez à nouveau. N'affaiblissez pas DMARC et ne supprimez pas les enregistrements d'autres expéditeurs simplement pour réussir un test. Si une modification endommage le courrier existant, utilisez le plan de récupération approuvé et la configuration capturée avant la modification, en coordonnant toute modification d'expéditeur côté fournisseur ainsi que DNS . Conservez les anciennes clés pendant que les messages en file d'attente ou un chevauchement approuvé en ont encore besoin.
Aucun locataire client, aucun changement faisant autorité avant/après ou aucun message réellement reçu n'était disponible pour ce manuscrit. Les sources retenues soutiennent le flux de travail documentaire ; ils ne satisfont pas au portail des preuves en direct commandé. L’examen par un vérificateur indépendant et l’approbation des PME humaines restent en attente. Ne décrivez pas ce guide comme étant validé sur le terrain et ne le publiez pas comme ayant franchi ces portes.
Résoudre l'expéditeur en attente sans affaiblir la politique
Le cas écrit SQ-01 suppose que hello@example.com a terminé la vérification du code de la boîte de réception, mais son domaine tiers apparaît toujours non authentifié et dispose d'une politique p=reject existante. L'enregistrement DKIM généré n'a pas été publié ; Les résultats actuels SPF et des messages reçus sont inconnus. Le propriétaire de la campagne doit garder la publication en attente pendant que le propriétaire DNS complète et vérifie l'ensemble d'enregistrements approuvé. Ne remplacez pas p=reject par une politique de surveillance pour contourner le problème d’activation. L'exigence SPF supprimée de Squarespace concerne ce flux de travail de vérification, et non l'autorisation de supprimer une politique utilisée par d'autres expéditeurs. Aucun compte, modification DNS ou campagne n'a été exécuté.
Pour un domaine Squarespace connecté à un autre site, son guide des détails de l'expéditeur ordonne d'abord la vérification sur ce site ou l'utilisation de la route du domaine tiers. La vérification automatique n’est donc pas une raison pour ignorer l’association réelle du site ou le statut en attente.
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.