WordPress est souvent l'application qui crée un message, et non le service qui l'envoie finalement au destinataire. Un nom de plugin ou une notification « envoyée » n’identifie pas l’IP évaluée par SPF ou le domaine dans un Signature DKIM. Suivez un événement d’application réel au-delà de la frontière entre WordPress, son transport et la boîte aux lettres de réception.
Identifiez à qui appartient chaque étape
Commencez par l'événement : une demande de réinitialisation de mot de passe, une notification de commande ou la soumission d'un formulaire de contact. Enregistrez le plugin ou le chemin du code qui crée le message, l'adresse De configurée, le plugin de transport s'il est présent et s'il utilise la messagerie PHP locale, SMTP distant ou une API de fournisseur. Le manuel de messagerie de WordPress explique que les plugins peuvent remplacer la route d'envoi par défaut par des services tiers.
Inspectez la configuration via une administration autorisée sans copier les informations d’identification dans un ticket. Enregistrez le nom du service, l'étiquette du compte ou du projet et le domaine d'envoi, mais conservez les secrets d'API et les mots de passe SMTP hors du fichier de preuve. Vérifiez également le comportement de repli. Un plugin peut être configuré correctement pour sa route principale tandis qu'une tâche distincte ou une solution de secours utilise le serveur d'hébergement.
Ne confondez pas succès de candidature et livraison
WordPress documente qu'une vraie valeur de retour wp_mail() signifie que la méthode d'envoi a traité la demande sans erreur, et non que le destinataire a reçu le message. De même, un fournisseur acceptant un appel API établit une étape différente de la livraison finale.
Corrélez l'événement d'application avec un identifiant de transport ou de fournisseur et, le cas échéant, un événement de livraison ou de rebond. Conservez les horodatages dans un fuseau horaire cohérent. Si le fournisseur n'a aucune trace de l'événement, recherchez le chemin de l'application et du plug-in avant de modifier le DNS du fournisseur. S'il a accepté l'événement mais que le destinataire l'a rejeté, collectez la preuve complète de diagnostic et d'authentification SMTP .
Configurer l'authentification chez l'expéditeur réel
Pour un service SMTP ou API distant, utilisez le flux d'authentification de domaine actuel de ce service. Publier son généré DKIM TXT ou CNAME enregistre exactement et active le domaine si nécessaire. Déterminez le domaine de l'enveloppe et si le produit prend en charge un rebond personnalisé ou chemin de retour domaine. N’inventez pas une inclusion SPF à l’échelle de WordPress ; WordPress n’est pas un réseau de messagerie sortant universel.
Pour une route vers un serveur d'hébergement, travaillez avec l'hôte ou l'administrateur de messagerie pour identifier la véritable infrastructure d'envoi publique et le signataire DKIM pris en charge. Ajouter l'adresse IP du site Web au SPF sans prouver qu'il envoie le courrier peut autoriser le mauvais système. Maintenez une stratégie SPF appropriée sur le domaine d’enveloppe évalué et tenez compte de la limite de recherche.
Pour DMARC, choisissez une adresse De sous un domaine pour lequel l'organisation est autorisée à envoyer. L'adresse d'un visiteur d'un formulaire de contact appartient normalement à Répondre à, pas comme une fausse identité From. Configurez un chemin authentifié aligné pour le domaine De l'organisation et coordonnez la politique avec d'autres expéditeurs légitimes. Répondre à n'établit pas DMARC alignement.
Travailler sur une trace d'événement synthétique
Illustration uniquement, pas un test WordPress ou un fournisseur exécuté :
- Étape : Événement de commande ; Exemple d'étiquette de preuve : order-test-42 ; Ce qu'il établit : La demande a demandé une notification.
- Étape : Soumission du plugin ; Exemple d'étiquette de preuve : transport-event-42 ; Ce qu'il établit : Le transport sélectionné a traité la demande.
- Étape : Acceptation du fournisseur ; Exemple d'étiquette de preuve : supplier-message-42 ; Ce qu'il établit : Le fournisseur d'envoi a accepté l'événement.
- Étape : Réception externe ; Exemple d'étiquette de preuve : en-têtes bruts expurgés ; Ce qu'il établit : Final From, enveloppe, résultats DKIM et DMARC .
Supposons que le message transmis utilise orders@example.com , un domaine d'enveloppe appartenant au fournisseur et une signature d=example.com transmise. DKIM peut fournir une authentification DMARC alignée même si SPF n'est pas aligné. Si la solution de secours envoie à la place du courrier non signé à partir d'une adresse IP d'hébergement non autorisée pour le domaine de l'enveloppe, le même événement d'application peut produire un résultat différent. Testez délibérément la solution de secours uniquement dans une portée approuvée.
Laisser un transfert maintenable
Attribuez des propriétaires distincts d’application, de transport et DNS . Stockez la version de configuration, les enregistrements publics générés et les preuves de test réussies et échouées. Effectuez la réinitialisation du mot de passe et d'autres événements critiques après les mises à niveau du plugin, la migration de l'hébergement, les changements de fournisseur, les changements d'adresse d'expéditeur ou la rotation des clés. Surveillez les rebonds et les échecs réels au lieu de vous fier à un statut WordPress vert.
Lors du retrait, désactivez l'accès au transport inutilisé et supprimez l'autorisation DNS obsolète uniquement après avoir vérifié les dépendances partagées. Ne supprimez pas les enregistrements d'un fournisseur uniquement parce qu'un plugin a été remplacé si d'autres applications utilisent toujours cet expéditeur.
Séparez quatre emplacements de défaillance
Utilisez la trace des événements pour distinguer l'absence d'événement d'application, l'absence de soumission de transport, le rejet du fournisseur et l'échec du destinataire final. Enregistrement inconnu lorsqu'une étape n'a pas de journal fiable. Ne déduisez pas le rejet du fournisseur à partir d’un message de boîte de réception absent ou la réception finale d’un retour de méthode réussi. Conservez les identifiants d'origine tout au long du transfert afin que les propriétaires d'applications et de messagerie enquêtent sur le même événement.