Un reçu confirme un achat. Une offre en propose un autre. Les deux peuvent arriver automatiquement après le paiement, mais ils remplissent des fonctions différentes.
Cette différence détermine quels mécanismes de désinscription s'appliquent. Elle détermine aussi quels messages partagent une réputation d'envoi. Le type de message décide s'il doit inclure un mécanisme de désinscription.
Qu'est-ce qui rend un e-mail transactionnel ou marketing ?
L'objectif du message détermine sa catégorie. L'automatisation, la personnalisation et le nombre de destinataires ne définissent pas cet objectif.
Les consignes de Google sur les abonnements distinguent les réinitialisations de mot de passe, les reçus d'achat et les mots de passe à usage unique des messages d'abonnement. Les listes marketing et les newsletters relèvent de la catégorie abonnement.
| Question | E-mail transactionnel | E-mail marketing |
|---|---|---|
| Pourquoi est-il envoyé ? | Pour compléter ou signaler une transaction, une demande ou un événement de compte | Pour promouvoir quelque chose ou envoyer du contenu par abonnement |
| Qu'est-ce qui le déclenche ? | Un achat, une demande de réinitialisation ou un événement de compte pertinent | Un calendrier de campagne ou un déclencheur promotionnel automatisé |
| Qu'attend le destinataire ? | Les informations nécessaires à cette transaction ou à ce compte | Du contenu qu'il a accepté de recevoir par abonnement |
| Exemples | Reçu, lien de réinitialisation, alerte de sécurité | Newsletter, offre produit, relance promotionnelle |
La demande de reçu d'un client et son autorisation de recevoir une newsletter sont deux choses différentes. Google demande aux expéditeurs d'abonnements de confirmer l'adresse e-mail du destinataire avant l'envoi.
Les exigences de consentement dépendent aussi de la loi applicable. CAN-SPAM réglemente les e-mails commerciaux aux États-Unis selon un modèle d'opt-out.
Pourquoi utiliser des adresses d'envoi, des domaines et des pools d'IP distincts ?
La séparation maintient le trafic identifiable et réduit l'exposition à une réputation partagée. Les consignes d'envoi de Yahoo identifient les adresses IP et les domaines de signature DKIM comme signaux de réputation.
Google recommande des adresses d'envoi différentes pour les messages d'abonnement et les messages non liés à un abonnement. Yahoo recommande de séparer le courrier marketing de masse du courrier transactionnel par IP ou par domaine DKIM.
Par exemple, les reçus peuvent utiliser un sous-domaine receipts.example.com authentifié et les offres peuvent utiliser news.example.com. Chaque flux peut aussi utiliser son propre pool d'IP, un groupe d'adresses IP d'envoi.
Ces contrôles sont distincts. Une adresse From différente peut toujours utiliser le même domaine de signature et les mêmes IP d'envoi.
Que se passe-t-il quand les flux sont mélangés ?
Du marketing indésirable peut affecter la réputation utilisée par le courrier opérationnel. La FAQ de Yahoo met en garde contre le partage d'IP entre courrier commercial non sollicité et messages transactionnels.
Une campagne et une réinitialisation de mot de passe utilisant ces IP partagent cette exposition.
Mélanger les objectifs dans un même message pose un autre problème. Une offre promotionnelle dans un reçu peut modifier la classification du message au regard de CAN-SPAM.
En quoi les exigences de Gmail et Yahoo diffèrent-elles selon le type de message ?
Les messages transactionnels nécessitent tout de même une authentification et une infrastructure d'envoi conforme. La distinction liée à la désinscription ne les exempte pas des autres exigences des fournisseurs.
Les exigences d'envoi de Gmail imposent SPF ou DKIM à tous les expéditeurs vers les comptes Gmail personnels. Les expéditeurs dépassant 5 000 messages par jour vers les comptes Gmail personnels doivent utiliser SPF, DKIM et DMARC. Leurs messages marketing et d'abonnement doivent aussi proposer une désinscription en un clic et un lien visible dans le corps du message.
Les consignes de Google sur les abonnements demandent aux expéditeurs de traiter les demandes de désinscription sous 48 heures. Un changement de préférence doit donc arrêter les envois d'abonnement suivants dans ce délai.
Les exigences de Yahoo imposent aussi SPF, DKIM et DMARC aux expéditeurs en masse. Son exigence de désinscription en un clic s'applique aux messages promotionnels et marketing. Sa FAQ exclut explicitement les exemples transactionnels tels que les confirmations de commande et les réinitialisations de mot de passe.
Comment CAN-SPAM traite-t-il les deux catégories ?
CAN-SPAM impose des obligations différentes selon l'objectif principal du message. La FTC, le régulateur américain de la protection des consommateurs, définit le contenu transactionnel ou relationnel de manière restrictive.
Les messages commerciaux doivent contenir des informations d'expéditeur véridiques, des lignes d'objet exactes, une identification publicitaire, une adresse postale et un mécanisme d'opt-out. Les messages purement transactionnels ou relationnels restent soumis à l'interdiction des informations de routage fausses ou trompeuses.
Une relation client existante ne rend pas chaque message transactionnel. Pour un contenu mixte, un objet promotionnel peut rendre le message commercial. Placer le contenu transactionnel principalement après la promotion peut produire le même effet.
Un e-mail promotionnel ne peut donc pas échapper à ces obligations en utilisant une adresse d'envoi transactionnelle ou une catégorie API.
Comment séparer les deux dans Bird ?
Vous définissez la catégorie du message sur transactional ou marketing selon son contenu. Un envoi inline utilise par défaut marketing. Un envoi utilisant un modèle enregistré hérite de la catégorie du modèle, sauf si vous la remplacez.
Bird ajoute des en-têtes de désinscription en un clic et un lien dans le corps HTML aux envois marketing. Un opt-out limité au marketing bloque le courrier marketing tout en autorisant le courrier transactionnel. Les rebonds définitifs, les suppressions manuelles et un opt-out couvrant tous les messages bloquent les deux catégories.
Vous choisissez l'infrastructure séparément. Utilisez des sous-domaines d'envoi vérifiés et sélectionnez un pool d'envoi avec ip_pool_id. Omettre ce champ utilise le pool par défaut de votre organisation. Définir category ne sélectionne pas un pool différent.
Le guide d'e-mail transactionnel API relie cette configuration à votre application. La checklist du service d'e-mail transactionnel couvre l'évaluation des fournisseurs.