Les reçus personnalisés USAePay nécessitent un domaine que vous contrôlez. Le choix Email From de la passerelle modifie ce que voient les destinataires, de sorte qu'ils stockent séparément les reçus des commerçants, les factures et tout flux de courrier partenaire. N'utilisez pas la transaction réelle d'un client comme test d'authentification et ne mettez pas les détails de paiement dans les services de diagnostic.
Configurer l'authentification de domaine personnalisé
Les documents du fournisseur include:spf.usaepay.com pour SPF. Ajoutez-le à la politique SPF applicable existante, avant le mécanisme du terminal, plutôt que d'en publier une autre. Enregistrement SPF. Le guide officiel déconseille de conserver une liste IP copiée, car les adresses des fournisseurs peuvent changer.
Pour DKIM, créez trois CNAME enregistrements sous votre domaine d'envoi : gps1. _domainkey pointe vers gps1._default.dkim.safewebservices.com ; gps2 et gps3 suivent le même modèle numéroté. Remplacez uniquement votre propre partie de domaine d'envoi, pas les cibles du fournisseur. Le guide indique que les clés publiques gps2 et gps3 sont des réserves intentionnellement vides pour la rotation. Publier leurs délégations même si un validateur clé signale les cibles vides ; l'acceptation du message d'aujourd'hui dépend de sélecteur effectivement utilisé. Référence de configuration USAePay
Le portail propose la validation SPF et DKIM . Utilisez-le comme contrôle de configuration, puis inspectez un reçu de test livré. La documentation indique qu'une marque personnalisée non authentifiée peut revenir à safewebservices.com . Enregistrez l’adresse d’expéditeur observée au lieu de supposer qu’un reçu livré porte toujours votre marque. Si vous ne pouvez pas contrôler le domaine souhaité, convenez d'une identité d'expéditeur approuvée plutôt que de falsifier une adresse de messagerie Web publique.
Le fournisseur exige désormais ces enregistrements d'authentification pour tous les domaines d'envoi personnalisés, et pas seulement pour les campagnes groupées. Traitez l'échantillon d'adresse IP publique utilisé dans un ancien exemple de validation comme une illustration de diagnostic, et non comme une preuve de l'adresse IP de sortie actuelle ou de l'identité de l'enveloppe réellement émise.
Vérifiez DNS et un résultat de réception réel
Avant de modifier les paramètres du reçu du commerçant et de l'expéditeur de la facture, exportez les valeurs DNS existantes, enregistrez la différence approuvée et nommez le propriétaire de la restauration. Confirmez si l'éditeur DNS attend un label relatif ou un nom complet ; doubler le suffixe de domaine crée un enregistrement qu'aucun vérificateur prévu ne trouvera. Recherchez le nom réel du propriétaire après l'enregistrement, y compris toute cible CNAME , plutôt que de vous fier à la bannière de réussite de l'éditeur.
SPF doit rester une seule stratégie sur le domaine concerné et rester dans les limites de la durée de requête DNS dans RFC 7208. L'ajout d'une inclusion n'établit pas lui-même alignement. Sous RFC 9989, DMARC réussit lorsqu’au moins un résultat SPF ou DKIM réussi s’aligne sur le domaine From visible sous le mode applicable. N'exigez pas que les deux mécanismes s'alignent en tant que condition imposée par la norme, et ne confondez pas un laissez-passer de domaine fournisseur avec un laissez-passer de domaine client aligné.
Envoyez un reçu test inoffensif généré par le flux de travail réel du commerçant à une boîte aux lettres que vous contrôlez. Enregistrez les résultats d'authentification fiables du système de réception, visible depuis, l'identité de l'enveloppe, les valeurs DKIM d= et s=, l'horodatage et l'état du fournisseur. Une recherche DNS affiche uniquement la clé disponible ; RFC 6376 la vérification évalue également la signature sur le message reçu. Utilisez du contenu non sensible et évitez d’exposer l’intégralité des messages clients aux contrôleurs publics.
Utiliser une décision d'acceptation et de restauration limitée
Cas de diagnostic écrit fictif uniquement : UP-01 suppose qu'un reçu inoffensif était destiné à utiliser receipts@shop.example mais que son From visible est noreply@safewebservices.com . SPF et toutes les identités/résultats DKIM sont inconnus. La livraison ne répond pas aux exigences de marque personnalisée. Le propriétaire du commerçant doit vérifier l'identité de la passerelle et le statut de validation, et le propriétaire DNS doit comparer les trois délégations documentées avant un nouveau test approuvé. Les clés de réserve vides ne suffisent pas à établir une défaillance du sélecteur actif. Aucun compte, DNS , relais ou message n'a été testé pour cet exemple.
Si le test échoue, séparez DNS manquants, le mauvais sélecteur, la configuration du fournisseur inactif, le routage inattendu et la modification du message avant d'effectuer une autre modification. Testez à nouveau le même flux de travail après chaque correction approuvée. N'affaiblissez pas la politique DMARC de l'ensemble du domaine pour masquer un seul problème d'expéditeur. Lorsqu'une restauration est nécessaire, restaurez la configuration de routage ou d'expéditeur précédente approuvée et conservez les enregistrements clés pendant que les messages signés en file d'attente en ont encore besoin. Conservez les preuves de test et les exceptions non résolues avec l'inventaire du domaine. Aucun accès locataire, changement DNS ou envoi réel n'a été effectué lors de la préparation de ce guide.
Tenir un registre d’acceptation responsable
Créez une ligne par compte, domaine et itinéraire sensiblement différent. Enregistrez le propriétaire de l'entreprise, le propriétaire DNS , la référence de modification, le De prévu, le De observé, le domaine d'enveloppe et le résultat SPF , chaque DKIM d= et s= avec son résultat, le mode d'alignement applicable, le récepteur de confiance et l'horodatage, l'état d'activation du fournisseur, l'observation du placement, la question non résolue et l'action suivante. Marquez les valeurs manquantes comme inconnues plutôt que de les traiter comme une réussite ou un échec. Le propriétaire n'accepte que l'itinéraire prévu et l'identité appuyée par les preuves enregistrées ; sinon, maintenez cet itinéraire et suivez le plan de rétablissement approuvé.
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.