Les questions que l'on nous pose réellement — par les développeurs qui intègrent l'API et par les équipes qui doivent répondre d'un fournisseur par écrit. Les réponses décrivent la plateforme telle qu'elle fonctionne, y compris là où cela ne joue pas en notre faveur.
Les deux, et par le même chemin. Le point de terminaison REST accepte du JSON ; le relais SMTP s’authentifie avec une clé d’API puis soumet par le même code. Tout ce que la clé détermine — l’identité d’expédition, la politique de chiffrement, le comportement de désabonnement — s’applique de façon identique dans les deux cas. Il n’y a aucune configuration propre au SMTP à maintenir en parallèle.
| Hôte | mail.zedmail.com |
|---|---|
| Port | 465 (TLS implicite) ou 2587 (STARTTLS) |
| Utilisateur | votre clé d’API |
| Mot de passe | la même clé d’API |
Nous n’utilisons pas le port 25. Si votre hébergeur bloque le port 25 en sortie, ce n’est pas un obstacle à régler avant de pouvoir envoyer : un client a attendu un mois un déblocage dont il n’avait pas besoin. Utilisez le 465 ou le 2587.
Deux CNAME pour DKIM et une inclusion SPF, à ajouter une seule fois par domaine d’envoi. Les CNAME pointent vers les mêmes cibles pour tous les clients : une rotation de clé de notre côté ne vous demande donc jamais de retoucher votre DNS.
Nous vous indiquons les enregistrements exacts lors de l’ajout du domaine, et nous les vérifions avec vous ensuite plutôt que de vous laisser interpréter un délai de propagation.
Oui, et pour du courriel applicatif c’est généralement préférable. Un sous-domaine s’ajoute exactement comme un domaine, et DKIM signe avec ce sous-domaine : DMARC passe par l’alignement DKIM et votre domaine organisationnel conserve sa propre politique stricte.
Oui, sans plafond fixe — un client exploite neuf domaines sur un seul compte. Les agences et les produits multilocataires préfèrent généralement une clé par client ou par environnement, ce qui rend aussi chaque configuration indépendante : la politique de chiffrement et le comportement de désabonnement sont des propriétés de la clé, non du compte.
Non. Rattacher une clé à une seule adresse est une option, pas une règle, et elle est active par défaut parce que la plupart des gens veulent un identifiant qui ne puisse jamais envoyer sous une autre identité. Laissez ce champ vide et la clé peut envoyer depuis n’importe quelle adresse d’un domaine que vous avez vérifié ; toute autre adresse est refusée plutôt que réécrite silencieusement.
Les 200 premiers messages de chaque jour sont inclus sans frais et sans moyen de paiement. Cette tranche ne s’accumule pas — une journée creuse ne prête pas son reste à une journée chargée — et elle continue de s’appliquer une fois une carte enregistrée : seul le volume supérieur est facturé. Les tarifs courants figurent sur la page d’accueil.
Rien, à condition de transmettre votre propre idempotency_key à l’envoi — un
numéro de commande, un identifiant de tâche, tout ce qui est unique à ce message. Une reprise
identique dans les 24 heures renvoie la première réponse, avec le code 200 et un
en-tête Idempotent-Replay: true au lieu du 202 habituel, et aucun
deuxième message ne part.
Les cas limites sont délibérés. Une reprise pendant que la première tentative est encore en
cours répond 409 — la seule réponse qui ne puisse pas envoyer deux fois. La même
clé avec un message différent est refusée avec un 422 : rendre
discrètement l’identifiant du premier message signifierait que le second n’est jamais parti et
que personne ne l’a su. Et un envoi que nous refusons libère sa clé : une adresse invalide ou un
domaine non vérifié se corrige et se reprend avec la même clé, sans impasse.
Sans clé, le comportement est inchangé : aucune intégration existante n’est affectée.
L’en-tête Idempotency-Key fonctionne aussi, s’il convient mieux à votre client
HTTP.
Une clé déclare à quoi elle sert. Transactionnel signifie que c’est le geste du destinataire qui a provoqué le message — un reçu, une réinitialisation de mot de passe, un avis d’expédition. Diffusion signifie que c’est vous qui avez choisi le moment, vers plusieurs personnes à la fois — une infolettre, une annonce, une campagne. Le flux se choisit à la création de la clé.
Le flux appartient à la clé, pas à la requête. C’est voulu, et c’est ce qui le fait fonctionner en SMTP : notre relais s’authentifie avec votre clé d’API et soumet par le même code que le point de terminaison REST, donc un flux porté par la clé n’exige aucun en-tête particulier. Les fournisseurs qui ont mis le flux dans un champ de requête ont dû ajouter ensuite des identifiants SMTP propres à chaque flux, parce que certains clients SMTP ne peuvent pas poser d’en-tête personnalisé du tout.
Trois conséquences découlent de ce choix :
Les rejets et les plaintes restent à l’échelle du compte sur les deux flux, et c’est voulu. Une boîte morte est morte quel que soit le flux qui la réessaie, et une plainte pour pourriel est une affirmation sur vous et ce destinataire plutôt que sur un flux. La clientèle partage des adresses d’envoi : une adresse réessayée sans fin sur l’autre flux dépense la réputation de tout le monde, pas seulement la vôtre.
Lequel choisir ? Si c’est le geste du destinataire qui a provoqué le message, transactionnel. Si c’est vous qui avez décidé du moment, diffusion. L’obligation de désabonnement de la LCAP porte sur les messages électroniques commerciaux, et un reçu n’en est pas un — c’est précisément pourquoi les deux flux sont traités différemment. Les clés créées avant l’existence des flux n’en portent aucun et se comportent exactement comme avant : rien n’a été réécrit sous elles.
Par défaut, oui — la LCAP exige un mécanisme de désabonnement dans les messages électroniques commerciaux, et le pied de page est la façon la plus sûre de garantir sa présence. Il est ajouté à la construction du message, dans la langue définie sur la clé.
C’est une petite ligne sous votre contenu : une phrase rappelant le consentement, et un lien de désabonnement. Sur une clé de diffusion, il est toujours ajouté ; sur une clé transactionnelle, jamais.
Avant d’ajouter quoi que ce soit, nous cherchons un désabonnement que vous auriez déjà, dans plusieurs langues, et nous laissons le nôtre de côté si vous en avez un. Nous examinons la partie en texte riche et la partie en texte brut séparément, parce qu’un désabonnement présent dans l’une ne l’est pas dans l’autre. Cette vérification lit cependant la formulation : un lien disant « Gérer mes préférences » ou « Arrêter ces courriels » peut lui échapper. Les deux réponses suivantes sont les deux façons d’être explicite plutôt que de s’y fier.
Oui. Placez {{unsubscribe_url}} n’importe où dans votre corps HTML ou texte et nous
le remplaçons par l’adresse de désabonnement propre à ce destinataire :
<a href="{{unsubscribe_url}}">Ne plus recevoir ces courriels</a>
Cela fonctionne dans les deux parties du message, avec l’échappement correct pour chacune, et les accolades tolèrent les espaces. La substitution se fait à l’envoi et non à l’acceptation par l’API, parce que le jeton désigne un destinataire précis et n’existe pas avant.
L’usage de la balise tient lieu de votre désabonnement : notre pied de page n’est donc pas accolé en dessous — y compris quand votre formulation est dans une langue que notre détection ne reconnaîtrait pas.
Pourquoi ceci plutôt qu’un lien vers votre propre système. Ce que la plupart des expéditeurs veulent maîtriser, c’est la formulation et l’emplacement, pas la plomberie. Un lien vers votre propre point de terminaison fait sortir ce destinataire de notre liste de suppression, du point de terminaison de désabonnement en un clic qu’exigent Gmail et Yahoo des expéditeurs de masse, et du court sondage que nous présentons au moment du départ. La balise vous donne la formulation et conserve les trois.
Oui, par clé ou pour tout le compte. Vous constaterez peut-être qu’il s’efface déjà : avant d’ajouter quoi que ce soit, nous examinons les parties HTML et texte de votre message à la recherche d’un mécanisme existant, dans plusieurs langues, et nous supprimons notre pied de page lorsque vous en avez un. Il n’a jamais été conçu pour s’ajouter sous le vôtre.
Pour le courrier de diffusion, non — ils restent sur chaque message, parce que Gmail et Yahoo exigent le désabonnement en un clic des expéditeurs de masse et que les retirer nuirait à votre placement plutôt que de protéger votre flux.
Pour le courrier transactionnel, ils ne sont pas envoyés du tout, et c’est
voulu. Une réinitialisation de mot de passe n’est pas du courrier de masse : l’exigence
ne l’a jamais visée, mais l’en-tête affichait quand même le bouton de désabonnement du
fournisseur, et ce bouton ne demande aucune confirmation. Un destinataire qui l’utilisait sur
une facture cessait de recevoir toutes vos factures, sans que rien à l’écran ne le lui dise.
Activez le désabonnement par clé sur une clé transactionnelle et les en-têtes reviennent, limités à
cette seule clé — une conséquence assez petite pour valoir la peine d’être offerte. Dans
les deux cas, la balise {{unsubscribe_url}} fonctionne sur les deux flux, et elle mène à
une page qui annonce ce qu’elle fera avant de le faire.
La conséquence mérite d’être prévue. Un destinataire qui utilise le bouton
de désabonnement de son fournisseur est enregistré comme désabonné chez nous, et votre
système l’ignorera à moins de consommer le webhook unsubscribed. En le consommant,
les deux restent alignés et votre propre mécanisme demeure celui que vos utilisateurs voient.
Par ailleurs, chaque message porte un en-tête List-Help qui mène à
une page écrite pour vos destinataires plutôt que pour vous. Elle indique que
c’est vous qui avez envoyé le message et que nous n’avons fait que le transporter, que vous seul
détenez la trace de la façon dont leur adresse vous est parvenue, et ce qu’ils peuvent faire sur le
flux d’où vient le message. Elle nomme votre domaine d’envoi et rien du destinataire.
Un destinataire qui se désabonne, une boîte qui rebondit de façon définitive, et une adresse qui signale un message comme indésirable. La suppression est appliquée à l’envoi : une tentative ultérieure vers cette adresse est refusée plutôt que livrée puis regrettée.
Les refus de réputation et les échecs temporaires ne sont délibérément pas traités comme des boîtes mortes : un fournisseur qui nous ralentit, ou une plainte d’authentification, ne dit rien de l’existence de l’adresse.
Un désabonnement peut être rattaché à une seule clé d’API plutôt qu’à tout le compte, ce qui compte si vous envoyez des types de courriels réellement distincts : refuser une infolettre ne devrait pas refuser du même geste ses propres réinitialisations de mot de passe. Les plaintes pour indésirable et les rebonds définitifs valent pour tout le compte et ne sont pas réductibles : une plainte est une déclaration sur vous et ce destinataire, et une boîte inexistante l’est pour toutes vos clés.
Pas par nous. Seuls les rebonds définitifs déclenchent le webhook bounced ; boîte
pleine, listes grises et reports de réputation mettent à jour la fiche du message sans émettre
d’événement. Les gestionnaires de listes ont tendance à traiter tout événement de rebond comme
définitif, et ce comportement retirait discrètement des centaines de contacts valides des listes
de nos clients.
delivered, bounced, blocked, complained,
unsubscribed, opened et clicked. Chaque charge utile porte
event, un identifiant de message et un horodatage ; les événements qui ont du détail
ajoutent un objet data, et ceux qui n’en ont pas l’omettent — traitez-le donc
comme optionnel.
unsubscribed est l’exception à lire deux fois : il ne porte pas d’identifiant de
message, parce qu’un désabonnement est une action contre une adresse et non le rebond d’un
message précis, et parce que le lien reste valide longtemps après que ce message a quitté votre
fenêtre de conservation. Lisez l’adresse dans data.
Oui. Un point de terminaison peut être rattaché à une clé, de sorte que les événements d’un environnement de préproduction atteignent un récepteur de préproduction et ceux de production atteignent la production, sans démultiplexage intermédiaire. Laissez-le non rattaché et il reçoit tout ce qui concerne le compte, comme c’était le cas avant l’existence de l’option.
Une URL fournie avec chaque message n’est pas proposée, et ce n’est pas un oubli : cela reviendrait à publier vers le point de terminaison que la requête indique, avec un état de reprise pour des adresses qui n’ont peut-être jamais existé.
Chaque événement que nous pouvons rattacher à une clé porte l’identifiant propre de cette clé. Ce n’est pas le secret et il n’en dérive pas, il survit à une rotation, et il peut être journalisé et conservé sans risque — ce qui en fait une bonne valeur de routage si vous préférez un seul point de terminaison partagé à plusieurs rattachés.
Oui, de deux manières, et le choix dépend d’une seule question : quelque chose à la réception doit-il lire votre identifiant ?
Si non, utilisez les étiquettes (tags) : jusqu’à dix par
message, cinquante caractères chacune, conservées avec le message et retournées dans les
événements de livraison et d’échec. Elles ne quittent jamais notre côté, donc le destinataire ne
les voit pas. Deux limites à prévoir : elles sont ramenées à ces bornes plutôt que refusées,
de sorte qu’un identifiant composite long peut arriver tronqué ; et comme
unsubscribed ne porte pas de message, il ne porte pas d’étiquettes non plus
— utilisez l’identifiant de clé pour rattacher un désabonnement.
Si oui, utilisez des en-têtes personnalisés (headers) : ils
partent avec le message, là où un système à la réception peut les lire, et reviennent dans
chaque événement webhook. Un seul champ fait les deux ; ailleurs il faut généralement un
en-tête pour le message et un champ de métadonnées distinct pour le retour.
"headers": { "X-Survey-ID": "survey-8842" }Jusqu’à dix en-têtes, 64 octets par nom, 200 octets par valeur, 2 Ko au total.
Contrairement aux étiquettes, un en-tête invalide fait échouer l’envoi avec un
code 422 qui le nomme : rien n’est tronqué ni échappé, vous n’aurez donc jamais un en-tête
que vous croyez avoir défini sans l’avoir fait. Les en-têtes que nous définissons nous-mêmes
(From, Subject, Message-ID, Content-*,
List-* et le reste) sont refusés plutôt que remplacés.
Deux points de jugement. Un en-tête voyage avec le message : il est visible par le destinataire, par son fournisseur de messagerie et par toute personne à qui le courriel est transféré — gardez donc la valeur opaque. Et un en-tête personnalisé n’est pas couvert par la signature DKIM, ce qui convient à un identifiant de corrélation mais ne doit pas être traité comme une preuve d’origine.
Chaque point de terminaison a son propre secret, affiché une seule fois à la création, et les livraisons sont signées avec celui-ci afin que votre récepteur puisse rejeter ce qu’il ne peut pas vérifier. Les échecs sont repris avec un délai croissant ; un point de terminaison que vous désactivez cesse de recevoir plutôt que d’accumuler un arriéré.
Au Canada. L’infrastructure d’envoi et la base de données se trouvent dans la région de Beauharnois, au Québec, et les sauvegardes chiffrées hors site sont également au Québec. Le service est administré depuis Ottawa, en Ontario.
Si vous ou votre client êtes assujettis à la Loi 25 du Québec, notez que l’administration depuis l’extérieur du Québec est un facteur de votre propre évaluation des facteurs relatifs à la vie privée. Nous vous fournirons ce qu’il vous faut pour la mener plutôt que de vous laisser le déduire.
Ozonagram Ltd, une société canadienne constituée au fédéral. Aucune société mère, aucun investisseur exerçant le contrôle, et aucun bureau ni personnel hors du Canada.
Selon notre lecture, non, et le raisonnement porte sur la structure des sociétés plutôt que sur des assurances. Le CLOUD Act atteint les fournisseurs soumis au droit américain — les sociétés américaines et les filiales de groupes américains. Il descend depuis une société mère américaine ; il ne remonte pas depuis une société mère étrangère.
Notre hébergement est assuré par un groupe français, par l’entremise de sa société canadienne, et l’activité américaine de ce groupe est une filiale à gouvernance distincte. Le groupe déclare dans son document d’enregistrement universel que seule sa filiale américaine est assujettie à ces règles, parce que les activités hors États-Unis en sont séparées, et son analyse publiée dit la même chose de la société canadienne : hors de portée, l’entraide judiciaire étant la voie qu’une autorité américaine devrait emprunter.
Cinq, et un seul peut lire vos courriels : l’hébergement. Les adresses des destinataires, le contenu des messages et les journaux de livraison sont stockés au Canada, dans des centres de données OVHcloud au Québec, auprès d’OVH Hébergement Inc. Aucun sous-traitant n’est autorisé à stocker ou à consulter ces renseignements hors du Canada.
Une seconde copie des sauvegardes chiffrées est conservée par CanHost Inc. à Kelowna, en Colombie-Britannique, afin qu’une défaillance chez un fournisseur ne puisse emporter à la fois le service et les moyens de le reconstruire. Cette copie est du texte chiffré : la clé de déchiffrement n’est jamais remise à CanHost, elle est gardée hors ligne et n’a jamais été déposée sur un serveur. Ajouté le 1er novembre 2026.
Les trois autres n’en reçoivent rien. Paddle (Royaume-Uni) est notre marchand officiel et ne reçoit que les données de compte et de facturation — jamais d’adresses de destinataires, de contenu de message ni de journaux de livraison. Bunny.net et Hostinger publient le DNS autoritatif de nos propres domaines; les enregistrements DNS sont publics par nature et ne contiennent aucun renseignement personnel.
Aucun service d’envoi, de relais ou de filtrage antispam tiers ne figure dans le chemin. Les serveurs de messagerie sont nos propres logiciels sur nos propres machines, et l’analytique est auto-hébergée. La liste autoritative est l’annexe C de notre entente de traitement des données, qui prévaut si ce résumé et l’entente diffèrent.
Non — y compris les sous-traitants indépendants.
Il en existe une, publiée à zedmail.com/dpa.php. Elle fait partie des conditions et est acceptée avec elles sans signature, et nous en signerons un exemplaire si votre processus en exige un au dossier.
C’est vous qui choisissez : de 7 à 365 jours, réglé sur le compte et, si vous le souhaitez, séparément pour chaque flux — une fenêtre courte sur la diffusion et une plus longue sur les reçus que vous pourriez avoir à produire plus tard. Au terme de la fenêtre, toute la fiche disparaît d’un bloc : destinataire, objet, corps et statut de livraison.
Le plancher est de sept jours et non d’un seul, pour une raison qui mérite d’être connue : en dessous, un rejet peut arriver après la disparition de la fiche du message auquel il se rattache, et l’adresse ne serait alors jamais mise en suppression.
Trois exceptions, parce qu’une réponse complète est plus utile qu’une réponse courte :
Chaque message est chiffré en transit dès que le serveur destinataire le permet. Vous pouvez aussi l’exiger par clé : un message destiné à un serveur incapable d’offrir un chiffrement vérifié n’est pas envoyé plutôt qu’envoyé en clair, et nous vous indiquons quels destinataires sont concernés.
Pour les grands fournisseurs grand public, c’est appliqué de toute façon, parce qu’ils publient des politiques selon lesquelles leurs serveurs ne devraient jamais accepter de courriel non chiffré, et nous les y tenons.
Nous ne communiquons aucune donnée à un gouvernement étranger. Lorsqu’un tribunal ou une autorité publique canadienne nous contraint à la communication, nous ne communiquons que ce à quoi nous sommes légalement contraints, nous vous en informons au préalable sauf interdiction légale, et nous renvoyons l’autorité vers vous lorsque c’est possible.
Dans les 72 heures suivant la prise de connaissance, engagement inscrit aux conditions : ce que nous savons et ce que nous faisons. C’est à vous de décider si les autorités ou les personnes concernées doivent être avisées, et notre rôle est de vous donner de quoi en décider.
99,5 % par mois sur les points de soumission, mesurés par intervalles de cinq minutes, avec crédits de service en cas de manquement et exclusions énoncées. C’est l’article 6 des conditions, et non quelque chose fourni sur demande ; vous pouvez le confronter à une surveillance exploitée par un tiers à status.zedmail.com.
Les comptes touchés reçoivent un courriel et la page d’état est mise à jour. Par ailleurs, et automatiquement : si l’envoi est un jour suspendu sur votre compte — pour un taux de rebond ou de plainte au-dessus du seuil, par exemple — vous recevez immédiatement un courriel indiquant la raison, plutôt que de le découvrir par des appels d’API en échec.
Au moins 90 jours par écrit, au contact de facturation et par un avis dans le tableau de bord. C’est l’article 7 des conditions, et l’engagement dépasse le préavis : le service fonctionne normalement pendant toute cette période, y compris l’engagement de disponibilité ; rien n’est facturé pour une période postérieure à l’arrêt ; tout crédit prépayé non utilisé est remboursé ; et vous pouvez exporter vos données d’envoi, vos journaux de livraison et vos listes de suppression tout du long.
Ce dernier point mérite d’être vérifié chez tout fournisseur que vous évaluez. Vos obligations de conformité survivent au contrat, et vous ne pouvez pas respecter des désabonnements que vous n’avez pas pu emporter.
Il y a des limites, mais ce sont des réglages par compte et non des paliers de forfait : un plafond quotidien et un débit par minute, tous deux relevés sur demande. Un message est refusé si vous dépassez le plafond : à la mise en service, il vaut donc mieux le fixer confortablement au-dessus de votre pointe prévue plutôt qu’à son niveau — dites-nous la journée la plus chargée que vous pouvez imaginer et nous le placerons au-dessus.
Écrivez à hello@zedmail.com. Si la réponse mérite de figurer sur cette page, elle y sera ajoutée — la plupart des questions ci-dessus sont arrivées exactement comme ça.