Portée et configuration spécifique au fournisseur
Atlassian Statuspage sépare un domaine Web de page d'état personnalisé d'une adresse de notification personnalisée De. Un site Web fonctionnel CNAME n'authentifie pas le courrier. Le flux de travail de courrier électronique comporte également plusieurs fournisseurs de livraison. Complétez donc tous les enregistrements de fournisseur affichés plutôt que de vous arrêter au premier succès. DKIM installation.
Accédez à Votre page, Personnaliser la page et l'e-mail, puis Personnaliser l'e-mail. Définissez Envoyer depuis l'e-mail, configurez éventuellement Répondre à l'e-mail et enregistrez les personnalisations de l'e-mail. Suivez le nouveau lien ou ouvrez Votre page, Configuration DNS . Capturez les valeurs dans la section Notification par e-mail. Le TXT de propriété utilise le format status-page-domain-verification=<ORGANIZATION_CODE> ; le code d'organisation réel doit provenir du compte.
Le guide DNS actuel exige SPF autorisation incluant stspg-customer.com . Incorporez include:stspg-customer.com dans la politique existante applicable, pas une seconde Enregistrement SPF. Son exemple Mailgun est illustratif et ne constitue pas une autorisation d'ajouter des services non liés. Publiez l'enregistrement DKIM pour le fournisseur n°1, Mailgun et les trois enregistrements CNAME pour le fournisseur n°2, SendGrid , en utilisant les valeurs actuelles du compte. Le guide propose un chemin de migration distinct des anciennes clés DKIM vers les CNAME ; n’invalidez pas un dossier de travail à moins d’effectuer intentionnellement cette migration approuvée.
Une limite importante est l'utilisation existante Mailgun : Statuspage indique qu'il ne peut pas ajouter le même domaine une deuxième fois lorsqu'un autre service utilise déjà Mailgun . La solution de contournement recommandée est un sous-domaine From dédié, tel que notifications.example.com . Ce sous-domaine illustratif nécessite toujours sa propre configuration affichée et appropriée DMARC évaluation.
Utilisez Revalider tous les enregistrements après publication. Atlassian indique que l'envoi authentifié et signé commence dans les 24 heures suivant la validation, et que les enregistrements sont vérifiés toutes les heures et doivent rester présents. Avec un seul fournisseur configuré, un basculement à l’échelle du système peut amener les messages à utiliser noreply@statuspage.io . Les deux configurations de fournisseur constituent donc une mesure de continuité et non un encombrement redondant.
La décision qui compte
Testez l’état de préparation du fournisseur et la continuité de l’expéditeur de marque ; un partenaire de livraison configuré ne représente pas la configuration complète.
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. Boîte aux lettres MX existante, vérification sans rapport Enregistrements TXT 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 alignement identités. 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.
Utiliser un grand livre de continuité fournisseur par fournisseur
Le cas écrit SP-01 suppose que la configuration From status@notifications.example.com est personnalisée, que la configuration Mailgun est terminée et que le jeu d'enregistrements SendGrid est manquant. Un échantillon stipulé fourni par Mailgun a fait confiance au passage DKIM d=notifications.example.com, s=demo1; SPF est inconnu. Cet exemple fournit un alignement DKIM exact mais n'établit pas de continuité de marque via SendGrid . Le propriétaire des communications sur incident doit résoudre la configuration du fournisseur manquant ou accepter explicitement le risque de repli de l'expéditeur par défaut documenté avant de revendiquer la continuité. Ne provoquez pas de panne et n'informez pas les vrais abonnés pour tester ce cas pédagogique. Effectuer la validation du compte et utiliser un test contrôlé autorisé lorsqu'il est pris en charge ; un basculement non observé reste inobservé. Aucun incident ni basculement n'a été exécuté.
Préserver la limite d’application
La section 7.4 RFC 9989 nécessite DKIM valide, et non SPF seul, pour la publication de domaines. 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.