Distinguer l'hébergement, DNS et le courrier sortant
Ce guide couvre un domaine dont le courrier est réellement envoyé via le service de messagerie hébergé de xneelo. Un site Web ou un domaine hébergé sur ce site peut envoyer des messages via une boîte aux lettres externe, un système de comptabilité ou un service marketing. Enregistrez la boîte aux lettres et l'itinéraire SMTP , le package xneelo et le panneau de contrôle, l'autorité faisant autorité serveurs de noms, et le domaine From prévu. Enregistrez DNS existant et un message original de base avant de modifier quoi que ce soit.
Le panneau de configuration xneelo DKIM L'article indique que les nouveaux forfaits d'hébergement incluent DKIM par défaut, tandis que DNS hébergé en externe nécessite que son enregistrement correspondant soit ajouté ou modifié chez le fournisseur DNS . Cela n'établit pas l'état d'un ancien compte, d'un serveur autogéré ou d'un service SMTP non lié. Obtenez l'enregistrement actuel spécifique au package et l'état de signature plutôt que d'étendre la revendication par défaut à tous les produits xneelo. xneelo DKIM.
Examiner la politique SPF existante
Xneelo SPF L'article donne un exemple utilisant a, mx et include:spf.host-h.net, se terminant par un qualificatif d'échec logiciel. Il demande aux clients disposant d' DNS externe de modifier la politique de ce fournisseur et met en garde contre plusieurs Enregistrements SPF. Traitez l'exemple complet comme une configuration à évaluer, et non comme une commande visant à écraser chaque stratégie existante. xneelo SPF.
Identifiez le domaine d'enveloppe réel utilisé par un message de test direct. Inventoriez les autres systèmes autorisés sur ce domaine avant de fusionner quoi que ce soit. Conservez chaque autorisation nécessaire et vérifiez si les mécanismes larges a ou mx appartiennent à votre propre politique. Confirmez la syntaxe et le budget de recherche complet. Une politique peut être syntaxiquement présente mais produire des résultats neutres, softfail , fail ou permerror plutôt que de passer ; n’assimile pas l’existence au succès. Protocole SPF.
Maintenez la stabilité du routage MX entrant lors d’une modification d’authentification uniquement. N'ajoutez pas d'inclusions de fournisseurs non liées simplement parce qu'un article tiers les répertorie pour une marque d'hébergement similaire. Les noms et la marque historique n'établissent pas quel service actuel soumet votre message.
Confirmez l'enregistrement DKIM réel et le signataire
Obtenez la clé publique et sélecteur pour le package et le domaine à partir de sa configuration ou de son support actuel. Sur DNS externe, vérifiez le nom exact du propriétaire et le type d'enregistrement, en prenant soin de ne pas ajouter le domaine deux fois. Ne créez pas de sélecteur par défaut deviné et ne copiez pas la clé d'un autre client. Confirmez la réponse faisant autorité obtenue avant de tester le flux de travail d'envoi.
Une clé DNS correcte est nécessaire pour la vérification mais ne démontre pas que le service sortant utilise la clé privée correspondante. Envoyez un message contrôlé via le client normal et inspectez le réel DKIM-Signature. Interrogez le sélecteur sous son domaine d=, puis comparez le résultat de validation du récepteur de confiance. DKIM.
Comparez le publipostage, le courrier de sites Web et le transfert
Utilisez des lignes de preuves distinctes pour les chemins qui peuvent se comporter différemment. Ce qui suit est un plan de test synthétique, et non un ensemble de livraisons xneelo observées.
- Chemin : envoi direct de la boîte aux lettres hébergée ; Preuve : cible SMTP , en-têtes originaux et résultats du récepteur ; Décision : établir la référence de messagerie hébergée
- Chemin : notification du site Web ; Preuve : transport d’application et identités observées ; Décision : Déterminez si xneelo mail ou un autre service l'envoie
- Chemin : message transféré ; Preuve : résultats post-transfert et signatures préservées ; Décision : diagnostiquer le transfert séparément de l'envoi initial
Pour chaque échantillon, enregistrez le visible From, le domaine de l'enveloppe, chaque valeur d= et s= ainsi que le SPF , DKIM et le DMARC résultats. Pour un From synthétique de user@example.com , une signature passante d=example.com est une signature exacte alignement cas. Un domaine de signature appartenant à un fournisseur n'est pas aligné simplement parce que xneelo héberge le site Web. Appliquez la politique d’alignement efficace aux identités réelles. DMARC.
Réparation avec un plan spécifique au package
Si les enregistrements sont visibles uniquement dans un panneau ne faisant pas autorité, publiez-les via le propriétaire DNS réel. Si DKIM est manquant, confirmez si la signature de ce package et de cette route est activée au lieu de supposer qu'une valeur par défaut du nouveau package les couvre. Si SPF échoue, inspectez le domaine et le service évalués avant de modifier le domaine From visible. Si seul le transfert échoue, conservez la ligne de base d’envoi direct de passage et étudiez le relais séparément.
Restaurez la précédente valeur DNS connue si une fusion perturbe d'autres expéditeurs, et répétez les tests d'envoi direct et de service concerné. Coordonnez les modifications de clé avec le fournisseur plutôt que de supprimer un sélecteur nécessaire aux messages en file d'attente. Conservez les instantanés DNS , l’identité du package, les horodatages de test et les originaux reçus. Revérifiez après une migration de package, un déplacement DNS ou une modification SMTP . Ce manuscrit utilise uniquement de la documentation et ne revendique aucune vérification du locataire en direct ou de la livraison.
Confirmer la limite du fournisseur
L'historique de politique neutre de l'article SPF de 2019 ne prouve aucune politique ou résultat de réussite d'un domaine actuel. Ses descriptions de livraison simplifiées ne constituent pas des garanties du destinataire. La page publique DKIM établit un nouveau package par défaut mais ne fournit aucun sélecteur universel ni procédure d'activation ; obtenez les détails spécifiques au package et conservez cette limite au lieu d'inventer des étapes de panneau.
Travailler sur un cas de diagnostic fictif
Cas écrit fictif uniquement : XN-01 suppose que le courrier hébergé direct de help@shop.example passe d=shop.example, tandis qu'une notification de site Web provenant de la même adresse visible utilise un service SMTP externe. Son enveloppe et ses signatures sont inconnues. Le propriétaire du courrier conserve la ligne de base directe et charge le propriétaire du site Web de vérifier le service externe. Une clé DNS xneelo ou un nouveau package par défaut ne peut pas établir l'état de signature de cette route externe. Aucun compte, DNS , CRM, facture, campagne ou livraison n'a été testé pour ce cas.
Séparez un message qui passe de la préparation à l'application
RFC 9989 La section 7.4 nécessite DKIM valide pour une publication de domaine p=reject et met en garde contre l'interopérabilité du courrier indirect. Un seul résultat SPF aligné ne justifie pas en soi le déploiement d’une politique de rejet. Examinez tous les itinéraires légitimes et la propriété des politiques séparément de la configuration de ce fournisseur.