Postmark Integration : installation et aide

• Mise en route. Un jeton de serveur Postmark connecte un serveur d’envoi existant.
• Contrôles DNS. Les requêtes DNS examinent la politique DMARC du domaine expéditeur et le CNAME Return-Path.
• Autre prestataire DNS. Recopiez les enregistrements du domaine depuis Postmark chez votre prestataire DNS.
• E-mails de la boutique. PrestaShop conserve la préparation des messages de commande et de compte, Postmark assure l’envoi.
• Retours d’échec. Le back-office conserve les rejets et signalements comme spam.
• Test et maîtrise. Un test par la messagerie native et la restauration des réglages concernés accompagnent la bascule.

Identifiants et domaine expéditeur

La connexion demande le jeton API d’un serveur Postmark existant. Le domaine utilisé pour les contrôles DNS provient de la valeur effective de PS_SHOP_EMAIL pour la boutique sélectionnée. Un site shop.example.com qui envoie depuis commandes@example.com utilise donc example.com. Une adresse d’envoi valide fait partie des prérequis.

Recopiez vous-même le jeton du serveur dans le formulaire. L’authentification du retour d’événements est générée lors de la configuration du webhook. Remplacer ou supprimer le jeton enregistré restaure d’abord les réglages natifs encore gérés par le module et réinitialise les états de vérification et du webhook ; vérifiez et activez de nouveau la connexion. Modifier le domaine de l’adresse de la boutique ne désactive pas automatiquement SMTP.

Publication et activation

La publication DNS est manuelle chez tous les prestataires, y compris Cloudflare. Récupérez les enregistrements du domaine expéditeur dans Postmark et publiez-les chez votre prestataire DNS. Le module n’a pas de connexion Cloudflare et ne modifie pas les DNS.

La vérification contrôle la disponibilité SMTP et le flux outbound transactionnel actif. Les contrôles DNS lisent DMARC et Return-Path, sans interroger le statut de vérification du domaine dans Postmark. Une politique DMARC quarantine ou reject sans Return-Path correspondant impose votre confirmation de la vérification du domaine dans Postmark avant l’activation. Le webhook se configure séparément.

La désactivation rétablit les valeurs d’envoi encore détenues par l’intégration et préserve vos modifications ultérieures. Elle ne ferme pas le compte et ne supprime pas les ressources distantes de Postmark. Le rapport présente les événements de la boutique sélectionnée et les totaux conservés. Il ne propose ni sélection de campagne, ni choix d’un flux personnalisé, ni réactivation automatique d’un destinataire bloqué.

Domaine géré ailleurs que sur Cloudflare

Voici la forme des deux enregistrements attendus. Les valeurs réelles proviennent de votre configuration du domaine dans Postmark :

TXT   <selecteur>._domainkey.example.com   <valeur DKIM fournie par Postmark>
CNAME pm-bounces.example.com              pm.mtasv.net

Le sélecteur et la valeur DKIM de cet exemple sont des indications, pas des données utilisables. Le format du nom dépend de votre éditeur DNS. Le CNAME Return-Path doit rester en DNS seul, sans proxy. Le module ne génère pas de politique SPF ou DMARC et cet exemple ne remplace pas vos enregistrements existants.

Prérequis

• Plage générale : PS 1.6 – 9.x. Le minimum exact déclaré est PrestaShop 1.6.1.0.
• PHP 7.1 ou ultérieur, dans une version adaptée à votre PrestaShop.
• Extensions PHP cURL et JSON. Les appels API ont un délai de connexion de 5 secondes et une durée totale maximale de 20 secondes.
• Compte Postmark, serveur existant avec SMTP et flux outbound transactionnel actif, et jeton de ce serveur. Le service Postmark est payant, avec ses propres offres ; le module est gratuit.
• Adresse d’envoi valide, accès à la gestion DNS du domaine et retour d’événements accessible publiquement en HTTPS.
• Publiez manuellement les enregistrements d’authentification chez votre prestataire DNS, y compris Cloudflare.

L’employé doit avoir accès à cette boutique et disposer du droit de consultation ; la modification exige aussi le droit d’édition. Les secrets ne doivent pas apparaître dans les captures. En multiboutique, la configuration d’une boutique ne prouve pas celle des autres.

Enregistrer le jeton du serveur, vérifier le serveur et le flux outbound, activer SMTP natif, configurer le webhook et envoyer le test sont des actions séparées. Le module réutilise l’envoi de la boutique et son récepteur d’événements authentifié.

Comment Postmark Integration répond-il aux e-mails de commande manquants ?

Postmark Integration relie les messages déjà préparés par votre boutique au service d’envoi transactionnel de Postmark. Configurez vous-même l’authentification de l’expéditeur dans Postmark, puis connectez la boutique avec le jeton du serveur existant. Vous conservez les contenus produits par PrestaShop et retrouvez dans le back-office les retours de Postmark lorsqu’un message est rejeté ou signalé comme spam.

Comment le domaine expéditeur est-il configuré sur Cloudflare ?

Publiez manuellement dans Cloudflare les enregistrements du domaine fournis par Postmark, avec le CNAME Return-Path en DNS seul. Le module ne modifie pas les DNS Cloudflare et n’interroge pas Postmark pour vérifier le domaine. Ses contrôles DNS utilisent le domaine de l’adresse d’envoi de la boutique, qui peut différer de l’adresse du site.

Et si mon domaine est géré chez un autre prestataire ?

Utilisez les enregistrements de votre configuration du domaine dans Postmark dans l’éditeur DNS de votre prestataire. La publication est manuelle chez tous les prestataires. Le module ne fournit pas les valeurs DKIM et ne publie pas les enregistrements.

Mes e-mails actuels gardent-ils leur présentation ?

PrestaShop continue de préparer le contenu, la présentation et les pièces jointes des messages. Le module modifie les réglages d’envoi vers Postmark, sans vous demander de reconstruire vos modèles. Les notifications d’autres modules suivent ce circuit lorsqu’elles utilisent la messagerie native de PrestaShop.

Où retrouver les rejets et les signalements comme spam ?

Le rapport du back-office présente les rejets et les signalements transmis par Postmark, avec le destinataire, la date et la référence du message. Votre équipe dispose d’une trace à consulter lorsqu’un client attend une confirmation de commande introuvable. Une réponse positive à l’envoi ne constitue pas, à elle seule, une preuve de réception.

Que confirme l’e-mail de test ?

Le test utilise la messagerie native de PrestaShop et le modèle de test du module. Il est adressé à l’employé qui lance le test et emprunte donc le circuit d’envoi de la boutique. Le résultat d’envoi et la présence du message dans la boîte du destinataire sont deux vérifications distinctes.

Envoi natif et absence de suivi des lectures

L’activation écrit PS_MAIL_METHOD=2, PS_MAIL_SERVER=smtp.postmarkapp.com et le port 587. Le jeton serveur enregistré sert d’identifiant et de mot de passe. PrestaShop 1.6 à 8 utilise tls ; PrestaShop 9 utilise off dans son réglage natif pour permettre STARTTLS automatique. Cette différence ne signifie pas que l’envoi doit rester sans chiffrement.

À partir de PrestaShop 1.7.6, le module ajoute les en-têtes absents X-PM-KeepID: true, X-PM-TrackOpens: false et X-PM-TrackLinks: None. Les valeurs explicites déjà présentes sont conservées. Les versions antérieures dépendent des réglages du serveur Postmark. La vérification avertit si le suivi est activé sur le serveur, sans modifier ces réglages.

Événements et expéditeur

Le retour authentifié doit correspondre au serveur mémorisé et au flux outbound. Le module conserve des événements normalisés Bounce et SpamComplaint, déduplique leurs références et affiche les 30 plus récents avec les totaux conservés. La date est en UTC ; le rapport expose le destinataire, la référence d’événement et le Message-ID.

À partir de PrestaShop 1.7.6, le hook final d’envoi vérifie que la connexion est enregistrée comme active et que la méthode et le serveur natifs utilisent Postmark avant d’ajouter les en-têtes. Il ne valide pas le domaine From et ne revérifie pas la disponibilité du serveur ni les identifiants SMTP pour chaque message. Vérifiez vous-même l’autorisation de l’expéditeur dans Postmark.

Prise en charge, réception et boîte de réception

Un résultat d’envoi positif indique une prise en charge. Il ne prouve ni la réception finale ni le classement hors spam. L’authentification du domaine ne neutralise pas les filtres du destinataire. Aucun taux de délivrabilité ni certification Gmail ou Outlook n’est annoncé.

Le test appelle la fonction native Mail::Send de façon synchrone et s’adresse à l’employé qui le déclenche. Il n’y a ni processus CLI séparé, ni limite de durée d’envoi imposée par le module, ni renvoi automatique. En cas d’échec, contrôlez les réglages natifs et les diagnostics. L’envoi ordinaire utilise toujours la messagerie native.

Périmètre et données personnelles

L’intégration couvre le flux transactionnel outbound par défaut. Elle ne fournit ni outil de newsletter, ni envoi de masse, ni flux personnalisé, ni éditeur de modèles, ni renvoi automatique des messages rejetés. Les systèmes d’envoi indépendants des autres modules restent hors de ce circuit.

Les retours d’échec contiennent des données personnelles, notamment les adresses des destinataires et les références des messages. Le retour exclut le contenu de l’e-mail ; seuls les champs d’événement normalisés sont conservés. Le webhook configuré n’a pas de déclencheurs Open ou Click. Le suivi peut néanmoins dépendre des réglages du serveur ou des en-têtes existants. Cela ne signifie pas qu’aucune donnée ne quitte la boutique : Postmark reçoit les e-mails à envoyer.

Les secrets sont conservés côté serveur et absents de la vue de configuration sécurisée. Aucun chiffrement applicatif des identifiants n’est annoncé. Le module ne modifie pas les abonnements à la newsletter et ne réactive pas automatiquement un destinataire bloqué chez Postmark.

• Avertissement DNS : vérifiez l’authentification de l’expéditeur dans Postmark et publiez ses enregistrements exacts chez votre prestataire DNS. Le CNAME Return-Path reste en DNS seul.
• Expéditeur refusé : vérifiez que l’expéditeur réel de la boutique ou du module est autorisé dans Postmark. Le nom du site ne détermine pas à lui seul l’expéditeur.
• Test accepté mais message introuvable : consultez la boîte et le dossier spam de l’employé, puis les rejets disponibles. Un rapport vide ne prouve pas la réception.
• Aucun retour d’échec : contrôlez l’accès HTTPS public et la transmission de l’en-tête d’authentification. Une ouverture dans le navigateur ne simule pas un événement valide.
• Réglage modifié manuellement : confrontez l’état de la connexion aux réglages natifs. La restauration conserve les modifications du marchand.
• Erreur de compte ou de permission : corrigez le problème signalé de jeton de serveur, de SMTP ou de flux outbound avant de réessayer. La désactivation locale ne nécessite pas une réponse de Postmark.