Notifications d'inventaire avant de changer DNS
Un formulaire peut produire une notification interne, un répondeur automatique et un e-mail de workflow. Attribuez à chacun une ligne dans le plan de modification : nom du formulaire ou du flux de travail, événement déclencheur, destinataire prévu, adresse de l'expéditeur, réponse à, propriétaire de l'entreprise et transport prévu. Ne présumez pas qu’un test d’un formulaire établit l’identité de chaque étape de production d’e-mails.
Utilisez un domaine d'envoi contrôlé par votre organisation. L'adresse d'un répondant peut être utile pour diriger les réponses, mais la configuration de votre domaine ne vous autorise pas à authentifier un domaine de répondant non lié. Décidez explicitement si le formulaire doit être envoyé en tant que votre organisation et dirigez les réponses ailleurs. Testez avec des adresses contrôlées et des données de réponse fictives plutôt que des soumissions personnelles.
Répondre aux exigences d'expéditeur de FormAssembly
Le guide d'authentification de FormAssembly exige que les domaines d'expéditeur personnalisés incluent son SPF autorisation, include:spf1.formassembly.com. Les domaines dépourvus de cette autorisation reviennent à no-reply@formassembly.com jusqu'à ce qu'ils soient vérifiés. DKIM est pris en charge pour les forfaits Essentials et supérieurs : fournissez l'URL de l'instance, le domaine et un seul caractère alphanumérique. sélecteur nom. Consultez Support/E-mail de rebond sous Général et E-mail/Expéditeur de notification par défaut sous Divers dans le tableau de bord d'administration. Source : FormAssembly, sécurité et authentification des notifications par courrier électronique.
Avant de modifier SPF , récupérez la stratégie existante et inventoriez tous les services légitimes à l'aide de ce nom de propriétaire. Ajoutez l'autorisation nécessaire à une stratégie, pas à une seconde v=spf1 Enregistrement TXT. Préservez les autres expéditeurs et vérifiez le total des termes dépendant de la recherche DNS, y compris les inclusions imbriquées. Ne copiez pas un exemple complet de politique provenant d'une autre organisation et ne modifiez pas son qualificatif final sans examiner les conséquences pour tous les courriers.
Une demande de sélecteur n'est pas la clé publique elle-même. Obtenez le type d'enregistrement final, le propriétaire complet, la valeur et les instructions d'activation auprès du support FormAssembly pour cette instance. Conserver leur réponse en tant qu'autorité de configuration ; n’inventez jamais de clé publique et n’en copiez jamais une à partir d’un didacticiel tiers. Donnez au propriétaire DNS uniquement les enregistrements nécessaires à cette modification et enregistrez qui confirmera l'activation. La configuration du support et la mise en cache DNS ont des timings distincts, donc ni l'un ni l'autre ne doivent être masqués par une attente de propagation générique.
Valider le choix de l'expéditeur et signer séparément
Après la publication, interrogez les serveurs faisant autorité pour connaître le propriétaire et le type réels de l'enregistrement. Confirmez que l'éditeur DNS n'a pas ajouté la zone deux fois, n'a pas perdu une partie d'une clé ou n'a pas introduit un alias conflictuel. Comparez la réponse finale avec les instructions spécifiques à l'instance. Si la réponse faisant autorité est fausse, attendre plus longtemps ne résoudra pas le problème.
Déclenchez une soumission contrôlée et inspectez la notification reçue et le répondeur automatique de manière indépendante. Enregistrez les messages originaux et les résultats d'authentification du destinataire de confiance. Enregistrez les informations visibles De, Répondre à, l'identité de l'enveloppe et le domaine/sélecteur de signature DKIM . Répondre à achemine les réponses ; ce n'est pas le domaine DMARC utilise pour alignement. Confirmez que tout expéditeur de secours est acceptable pour le propriétaire de l'entreprise plutôt que de considérer silencieusement la livraison comme un succès.
Cas d'acceptation synthétique : la notification interne a From forms@example.com et une signature valide avec d=example.com. Son récepteur signale la réussite DKIM , donnant un chemin DKIM exactement aligné. Un répondeur automatique différent utilisant From visitor@another.example n'est pas authentifié pour ce domaine non lié simplement parce que le même formulaire l'a généré. La réponse correcte consiste à revoir la configuration de l’expéditeur, et non à ajouter d’autres inclusions SPF à example.com .
Séparer les prérequis du produit des résultats du protocole
L'exigence du fournisseur concernant SPF est une condition de configuration du produit. SPF lui-même authentifie le expéditeur d'enveloppe identité, tandis que DKIM vérifie une signature associée à d=. DMARC compare l'identité d'authentification réussie avec visible From sous son mode d'alignement. La réussite d'un contrôle de vérification du produit ne remplace donc pas l'enregistrement des domaines à partir d'un message délivré. Évitez de décrire un Signature DKIM car le cryptage ou la revendication d'authentification garantit le placement dans la boîte de réception.
Si un flux de travail échoue toujours, comparez ses paramètres et les en-têtes reçus avec un flux de travail fonctionnel. Une signature absente suggère un problème d'activation ou de route ; une signature qui échoue à la vérification nécessite une enquête sur l’intégrité de la clé et du message. Si l'authentification réussit, inspectez l'erreur de livraison réelle et la gestion du destinataire avant de modifier DNS . Ne répétez pas les soumissions en direct sans discernement et ne renvoyez pas d'informations client authentiques sous forme de données de test.
Conserver un chemin de récupération et un enregistrement d'acceptation
Enregistrez les paramètres de l'expéditeur précédents et la politique DNS avant les modifications. Si une identité personnalisée n’est pas prête, utilisez un accord d’expéditeur approuvé et fonctionnel pendant que l’assistance résout le problème. Ne supprimez pas les enregistrements d'autres services et n'affaiblissez pas la politique DMARC de l'ensemble du domaine pour masquer un problème spécifique au formulaire. Testez la gestion des réponses après tout changement d’expéditeur.
Acceptez le travail uniquement lorsque les formulaires et les étapes de flux de travail prévus affichent les identités de provenance et de réponse approuvées, DNS faisant autorité correspond aux valeurs fournies et que les messages reçus affichent un chemin aligné de transmission. Cet article fournit des instructions documentaires et un raisonnement synthétique, et non des preuves de tests en direct. Son exigence initiale de catalogue en matière de vérification de messages réels ou DNS reste ouverte jusqu'à ce qu'un opérateur agréé fournisse ces résultats ; l’examen humain et la publication ne sont pas implicites.
Gardez le propriétaire du formulaire séparé du répondant
Le cas écrit FA-02 suppose qu'un formulaire doit être envoyé sous la forme forms@example.com et des réponses directes à une adresse contrôlée visitor@other.example . La notification interne stipulée a fait confiance au passage DKIM avec d=example.com et s=forms1, donnant un alignement exact pour son De. Un deuxième itinéraire a à la place visible From visitor@other.example ; son enveloppe et toutes les signatures sont inconnues. Cette seconde route n'a pas de verdict d'authentification établi et ne peut pas emprunter le résultat de la première route. Le propriétaire du formulaire doit vérifier ses paramètres d'expéditeur et de réponse avant une soumission fictive autorisée. Aucune donnée du répondant, soumission de formulaire, modification DNS ou demande d'assistance n'a été utilisée.
Préserver la limite d’application
RFC 9989 La section 7.4 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.