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.
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é.
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.
Non — ils restent sur chaque message, parce que Gmail et Yahoo les exigent des expéditeurs de masse et que les retirer nuirait à votre placement plutôt que de protéger votre flux.
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.
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.
Trois, et aucun ne touche à vos courriels : le DNS autoritatif de nos propres domaines est assuré par deux exploitants européens, et la facturation par une société britannique. Ils ne reçoivent aucun contenu de message, aucune adresse de destinataire et aucune donnée de compte.
Précisément : 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.
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, par flux, jusqu’à un plancher de sept jours. Au terme de la fenêtre, toute la fiche disparaît d’un bloc : destinataire, objet, corps et statut de livraison.
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.