Confirmer le produit proposé et l'itinéraire de l'expéditeur
Ce guide s'applique à l'application de devis Quotient sur quotientapp.com et à ses e-mails de devis clients. Il ne décrit pas les produits non liés portant le même nom. Enregistrez le compte professionnel, le flux de travail du devis, l'adresse d'expéditeur prévue, le membre de l'équipe et le propriétaire DNS avant d'effectuer une modification. La propre configuration du compte fait autorité pour les enregistrements qui doivent être publiés.
Quotient prend en charge l'envoi à partir d'une adresse e-mail appartenant à un domaine détenu via des domaines personnalisés pour la messagerie. Son chemin d'aide actuel est Paramètres du compte, E-mails, Domaines personnalisés pour l'e-mail. Le service fournit les instructions DNS . Le documenté SPF et les entrées MX utilisent un sous-domaine distinct, avec un exemple tel que quotient-mail.yourdomain.com , et le MX prend en charge le traitement des rebonds et des réclamations. Ne remplacez pas la boîte aux lettres existante Enregistrements MX. Aide sur le domaine personnalisé Quotient
Un exemple de sous-domaine n'est pas une valeur littérale à coller dans DNS de chaque client. Copiez le propriétaire réel et la cible affichés dans le compte. Avant le changement, expliquez quels e-mails clients doivent porter le domaine détenu et quels itinéraires sortent de cette portée. Un e-mail de devis, un message de boîte aux lettres d'un employé et une campagne marketing sans rapport peuvent partager une marque visible tout en utilisant différents systèmes d'authentification.
L'annonce 2021 de Quotient décrit également un expéditeur de domaine fournisseur par défaut et CNAME, TXT et MX pour l'authentification de domaine personnalisé. Utilisez cette annonce comme contexte historique du produit, et non comme une garantie actuelle de prix ou de menu ; la page d'aide actuelle et le compte réel devraient déterminer la configuration. Annonce de domaine personnalisé Quotient
Rassemblez l'ensemble d'enregistrements actuel sans modifier la réception du courrier
Ouvrez les instructions actuelles sur les domaines personnalisés pour les e-mails du compte et capturez chaque type d'enregistrement émis, propriétaire et valeur ou cible publique. Désignez un administrateur qui peut modifier la zone faisant autorité. La page de facturation d'un registraire ou un ancien panneau d'hébergement ne constitue pas une preuve de l'endroit où DNS est servi.
Exportez les enregistrements existants avant de les modifier. Indiquez si chaque entrée proposée est nouvelle, une modification ou un conflit avec un service existant. Vérifiez le sous-domaine généré pour une utilisation préexistante. Un record peut être « nouveau » dans la notice du produit alors qu'il est déjà occupé dans l'environnement du client. Résolvez cette collision avec le propriétaire du service concerné au lieu de l'écraser.
Conservez les enregistrements MX du domaine de boîte aux lettres distincts du sous-domaine dédié à la gestion des rebonds. Écrivez les deux noms sur le ticket de monnaie, pas seulement « MX ». L'opérateur doit être en mesure d'expliquer quel enregistrement affecte le courrier des employés et lequel appartient à la livraison du devis. Si les instructions semblent nécessiter la modification de la boîte aux lettres principale MX , arrêtez et clarifiez la configuration actuelle du client avant de continuer.
Après la publication, interrogez chaque nom complet de propriétaire auprès du service faisant autorité actif et auprès d’un résolveur indépendant. Vérifiez qu'un éditeur DNS n'a pas dupliqué le suffixe de zone. Suivez les cibles CNAME lors de l'inspection des enregistrements de clé publique déléguée et conservez la cible exacte plutôt que de la remplacer par une clé devinée. Enregistrez les durées de vie et les heures de collecte afin que les tests ultérieurs puissent être comparés à l'état publié.
Examinez l'inclusion du SPF retiré en tant que migration
L'article dédié au SPF hérité de Quotient indique include:_spf.quotientapp.com n'est plus requis et pointe les utilisateurs vers des domaines personnalisés pour la messagerie. Il conseille de ne pas supprimer les autorisations requises par d'autres services. Il s'agit d'un avis de mise hors service explicite de première partie, donc un nouveau déploiement ne devrait pas rétablir cette ancienne inclusion en tant que configuration actuelle. Avis SPF hérité du quotient
Pour un domaine existant, traitez la suppression comme une étape de migration révisée et non comme un nettoyage automatique. Enregistrez d’abord la politique SPF existante, identifiez toute dépendance héritée approuvée et obtenez la confirmation de la route d’envoi de devis actuellement utilisée. Validez les nouveaux enregistrements de domaine personnalisé et un message reçu par le représentant avant de planifier la suppression. Si une dépendance spécifique au client n'est pas résolue, conservez la question dans le ticket de modification et demandez au prestataire de la rapprocher de l'avis de retrait.
Une fois la suppression approuvée, supprimez uniquement le mécanisme obsolète de la stratégie SPF unique applicable. Conservez les autorisations non liées et le reste de la stratégie prévue. Revérifiez le résultat complet plutôt que de juger le fragment édité de manière isolée. Un enregistrement de restauration doit contenir la valeur antérieure exacte, le propriétaire, l'heure et l'opérateur responsable.
SPF autorise une stratégie chez un propriétaire et impose une limite à l'évaluation dépendante du DNS. L’ajout d’un deuxième enregistrement ou d’une liste croissante d’inclusions historiques ne constitue pas une stratégie de migration sûre. L'identité évaluée est l'identité SMTP du message, il faut donc distinguer les principales domaine organisationnel du sous-domaine de l'enveloppe dédié lors de l'évaluation de la politique réellement utilisée. SPF RFC 7208
Confirmer les adresses des expéditeurs et les messages de devis réels
Quotient note que la vérification de l'adresse e-mail peut également être nécessaire après l'authentification du domaine. Enregistrez les adresses des membres de l'équipe qui sont confirmées et quelle adresse est réellement sélectionnée pour l'offre contrôlée. Les modifications DNS du domaine n'établissent pas automatiquement le contrôle de chaque boîte aux lettres. Aide sur le domaine personnalisé Quotient
Envoyez du contenu de test inoffensif via le flux de travail de devis réel aux destinataires approuvés. Si l'entreprise utilise des suivis ou d'autres chemins de messagerie client, incluez-les dans une ligne de test distincte plutôt que de supposer qu'ils héritent d'un envoi initial réussi. Capturez l'adresse de livraison, la réponse à, le domaine de l'enveloppe, DKIM les domaines et sélecteurs de signature, ainsi que les résultats d'authentification approuvés du destinataire.
DKIM utilise le domaine de signature de la signature et sélecteur pour localiser une clé publique. DMARC nécessite un mécanisme SPF ou DKIM aligné en passant par rapport au domaine visible From. Un message signé par un fournisseur peut transmettre DKIM sans prouver que l’identité From personnalisée de l’organisation est alignée. Vérifiez les domaines réels et alignement paramètres. DKIM RFC 6376 DMARC RFC 9989
Séparez les résultats d’authentification des résultats de livraison commerciale. Un message peut s'authentifier et néanmoins rencontrer une règle de destinataire, une mauvaise réputation ou une adresse invalide. Un test réussi ne permet pas non plus d'établir que chaque devis passé ou suivi programmé a utilisé le nouvel itinéraire. Documentez l’heure de basculement de la configuration et conservez les preuves représentatives après ce point.
Feuille de travail d'acceptation du quotient
Utilisez cette feuille de travail proposée pour l'itinéraire actuel de devis-e-mail. Aucune configuration client n'a été observée.
- Produit et compte : compte quotientapp.com , administrateur autorisé, membre de l'équipe, flux de travail et identité de l'expéditeur souhaité.
- Configuration du domaine : disponibilité des fonctionnalités en direct, jeu d'enregistrements générés, état de vérification actuel et confirmations de l'adresse de l'expéditeur.
- Séparation DNS : propriétaire et valeurs MX de la boîte aux lettres principale, sous-domaine de rebond généré, ses enregistrements SPF et MX et tous les enregistrements de signature délégués.
- Vérifications publiques : noms complets des propriétaires, réponses réelles ou chaînes CNAME , faisant autorité serveurs de noms, TTL, horodatages et collisions d'enregistrement.
- Examen de l'héritage : présence du retraité, évaluation des dépendances approuvée, clarification du fournisseur si nécessaire, approbation de la suppression et politique antérieure préservée.
- Tests de messages : devis ou suivi, destinataire, horodatage, De, enveloppe, domaines et sélecteurs DKIM , résultats fiables et mécanisme aligné.
- Décision : routes non testées, déclencheur de restauration, opérateur DNS , propriétaire de l'entreprise et approbation humaine restante.
Diagnostic fictif d'un changement MX dangereux
Cet exemple est fictif. Une entreprise souhaite que les devis proviennent de son propre domaine. Un opérateur voit une instruction MX et se prépare à remplacer les enregistrements MX de boîte aux lettres existants du domaine. Le réviseur des modifications remarque que l'instruction appartient à un sous-domaine généré utilisé pour le traitement des rebonds.
La correction proposée consiste à publier l'enregistrement chez son propriétaire exact tout en préservant l'acheminement du courrier des employés. L'équipe vérifie ensuite le domaine personnalisé et envoie un devis contrôlé. Une ancienne inclusion de Quotient SPF est découverte lors de l'inventaire, mais sa suppression est planifiée séparément après vérification de l'itinéraire existant et des dépendances approuvées. Ce scénario illustre deux risques différents ; il ne s'agit pas d'une migration effectuée ou d'une assurance concernant un compte réel.
Portes de preuve et de libération
Les pages d'aide actuelles prennent en charge le flux de travail du domaine personnalisé et l'avis de retrait. Ils ne fournissent pas le sélecteur, les cibles ou le comportement de signature générés par le client réel. Il s’agit toujours d’exigences en matière de preuves spécifiques aux locataires. La disponibilité actuelle des fonctionnalités et tout engagement commercial doivent être confirmés dans le compte avant l'activation. DNS en direct, les en-têtes reçus, l'examen des dépendances héritées, l'examen visuel, l'approbation humaine de la PME et l'approbation de la publication restent en attente.
Séparez les deux décisions DNS
Utilisez des lignes d'approbation distinctes pour ajouter les enregistrements de sous-domaine de rebond générés et supprimer l'inclusion de stratégie racine historique. La première décision nécessite une vérification de collision chez le propriétaire exact généré. La seconde nécessite l’inventaire de l’expéditeur existant et la valeur de récupération. Un devis réussi ne peut pas établir toutes les identités de suivi planifiées ni autoriser les suppressions SPF sans rapport.
Séparer l’acceptation des messages du déploiement de la politique
Un résultat SPF aligné peut satisfaire une évaluation de message, mais ne justifie pas à lui seul le déplacement d'un domaine entier vers le rejet. RFC 9989 La section 7.4 nécessite DKIM valide pour la publication de domaines p=reject et met en garde contre l'interopérabilité du courrier indirect. Inventoriez tous les expéditeurs légitimes et les itinéraires indirects avant que le propriétaire de la politique n’approuve l’application. Aucune modification DNS , opération de locataire ou test de message reçu n’a été exécuté pour cet article.