E-mails d’authentification
Réinitialisations, codes à usage unique et liens magiques : un appel API chacun
Les e-mails de connexion sont ceux que les utilisateurs attendent devant leur écran. MailLand vous apporte des modèles qui ne partent jamais avec un espace réservé brut, des clés d’idempotence qui transforment une requête renvoyée en simple rejeu plutôt qu’en deuxième e-mail, et des événements de livraison que vous pouvez afficher dans votre propre interface.
Pourquoi les e-mails d’authentification demandent plus de soin
Quelqu’un attend
Un utilisateur est sur votre écran de connexion. Un code qui n’arrive jamais, ou qui arrive deux fois, se transforme en ticket de support ou en inscription perdue.
Les destinataires vérifient l’expéditeur
Les fournisseurs de messagerie vérifient SPF, DKIM et DMARC. MailLand affiche les enregistrements à publier et signe chaque message avec la clé DKIM de votre domaine.
Une faute de frappe casse le parcours
Une adresse mal saisie à l’inscription, et tous les codes suivants partent dans le vide. Détectez l’erreur au moment où l’adresse est saisie, pas après la première connexion ratée.
Un code à usage unique, envoyé depuis un modèle enregistré
Le code est transmis comme variable par destinataire. La clé d’idempotence sécurise une nouvelle tentative après un délai d’attente dépassé.
curl -X POST https://api.mail.land/v1/transactional/send \
-H "X-API-Key: ml_pet_..." \
-H "X-Idempotency-Key: signin-7f3a9c-1" \
-H "Content-Type: application/json" \
-d '{
"from": { "email": "[email protected]", "name": "Your App" },
"to": [{
"email": "[email protected]",
"variables": { "code": "482913" }
}],
"templateId": "t8x2m4q9zk7wpr",
"variables": { "expiresInMinutes": "10" },
"tags": ["sign-in-code"]
}'Ce que MailLand vous apporte pour les e-mails de connexion
Des modèles qui refusent d’envoyer un message défectueux
Conservez les modèles de réinitialisation, de code et de lien magique dans MailLand et remplissez les {{placeholders}} à chaque requête. Une valeur manquante bloque l’envoi avec un 422 qui nomme la variable.
Des nouvelles tentatives sans doublons
Joignez un X-Idempotency-Key à chaque code. Si votre requête expire et que vous réessayez avec la même clé dans les 24 heures, MailLand renvoie la réponse d’origine et n’envoie rien.
Protection contre les fautes de frappe et les domaines jetables
Activez la protection pour votre flux transactionnel : MailLand refuse les adresses chez des fournisseurs jetables ou dont le domaine contient une faute de frappe probable, et suggère l’adresse corrigée.
Validation à l’inscription
Appelez l’API de validation lorsqu’un utilisateur s’inscrit. Elle vérifie la syntaxe, les fautes de frappe probables, les domaines jetables, les adresses génériques comme info@ et le serveur de messagerie destinataire.
Des événements de livraison pour votre interface
Les événements délivré, différé, rebond et échec parviennent à votre webhook : votre application peut ainsi demander à l’utilisateur de vérifier son adresse ou de réessayer.
Des liens laissés tels que vous les avez écrits
Le suivi des ouvertures et des clics est désactivé par défaut pour les e-mails transactionnels : tant que vous ne l’activez pas, les liens de réinitialisation et les liens magiques parviennent aux utilisateurs exactement tels que vous les avez écrits.
Envoyé depuis votre propre domaine
Ajoutez votre domaine, publiez les enregistrements SPF, DKIM et DMARC affichés dans le panneau, et MailLand les vérifie avant que vous puissiez envoyer. Chaque domaine reçoit automatiquement sa propre clé DKIM RSA de 2048 bits.
Ce que nous ne promettons pas
Nous ne publions aucun chiffre de délai de livraison : c’est le serveur de messagerie destinataire qui décide quand il accepte un message. Ce que MailLand vous apporte, c’est un historique complet de ce qui est arrivé à chaque message, et quand.
Questions sur les e-mails d’authentification
En combien de temps un code arrive-t-il ?
Nous ne publions aucune promesse de délai de livraison. L’API répond une fois le message mis en file d’attente, et la réponse en indique l’heure. L’événement délivré ou différé vous indique ensuite quand le serveur destinataire a accepté le message ou a demandé une nouvelle tentative.
Comment gérer un utilisateur qui clique sur « Renvoyer » ?
Traitez chaque nouveau code comme une nouvelle requête avec une nouvelle clé d’idempotence. Ne réutilisez une clé que lorsque vous renvoyez la même requête après un délai d’attente dépassé : dans les 24 heures, cette nouvelle tentative renvoie la réponse d’origine et n’envoie rien.
Puis-je bloquer les adresses jetables à l’inscription ?
Oui, de deux façons. Activez la protection contre les domaines jetables pour le flux transactionnel, ou appelez l’API de validation avant de créer le compte.
Puis-je tester le parcours sans envoyer d’e-mails à de vrais utilisateurs ?
Oui. Une clé sandbox accepte et enregistre chaque requête sans la livrer, ou ne livre qu’aux adresses d’une liste d’autorisation que vous choisissez.
Un désabonnement marketing peut-il bloquer les réinitialisations de mot de passe ?
Non. Un désabonnement s’applique aux e-mails marketing ou à une liste, et ne bloque pas les e-mails transactionnels envoyés à cette adresse.
Envoyez votre premier code de connexion dès aujourd’hui
Créez un compte gratuit, vérifiez votre domaine et enregistrez votre premier modèle. 1 000 e-mails par mois sont gratuits.