Adresses et usages
- E-mail temporaire / jetable
- Adresse qui reçoit des e-mails pendant une durée limitée, souvent utilisée pour tester une inscription ou vérifier la réception d’un code. « Temporaire » désigne la durée de conservation : cela ne garantit pas que tous les services tiers acceptent l’adresse et ne signifie pas qu’elle convient aux informations sensibles.
- Alias de transfert
- Adresse distincte qui redirige les messages reçus vers l’adresse e-mail de votre choix. Vous pouvez créer des alias selon leur origine et les désactiver. La désactivation ne supprime pas les copies déjà reçues dans la boîte de destination, et un alias ne remplace pas une adresse que vous contrôlez sur le long terme.
- Bac à sable e-mail
- Service de test qui intercepte, dans un environnement de développement, les e-mails qu’une application aurait dû envoyer, afin de vérifier les modèles et les variables. Le fait que l’application ait transmis un e-mail au bac à sable ne prouve pas que le même message puisse être distribué à un destinataire réel sur Internet.
- Enregistrement MX
- Enregistrement DNS qui indique les serveurs chargés de recevoir les e-mails d’un domaine. Une configuration MX correcte participe à l’acheminement, mais ne prouve pas à elle seule que l’adresse du destinataire existe, que le serveur a accepté le message ou que celui-ci est visible dans la boîte de réception.
Distribution et statuts
- SMTP
- Protocole couramment utilisé pour transférer des e-mails entre serveurs, ainsi qu’entre une application et un serveur d’envoi. Une réponse SMTP positive indique généralement que le serveur de l’étape en cours a accepté le message ; ce n’est pas une confirmation de sa réception finale.
- En file d’attente / Queued
- La tâche d’envoi a été placée dans une file d’attente en attente de traitement. Le serveur destinataire n’a peut-être pas encore été contacté. En cas d’attente prolongée, vérifiez l’engorgement de la file, les tentatives prévues et l’état du fournisseur au lieu de simplement actualiser la boîte de réception.
- Accepté / Accepted
- Un service a reçu une requête ou un e-mail. Pour interpréter ce statut, identifiez qui a accepté le message : l’application qui a reçu la requête, la plateforme d’envoi qui a pris en charge la tâche et le serveur destinataire qui a accepté l’e-mail apportent trois preuves différentes.
- Rebond / Bounce
- Notification ou statut signalant l’échec de la distribution d’un e-mail. Il peut être causé par une adresse inexistante, un refus lié à une politique ou un autre problème. Consultez le code et le détail de l’erreur, distinguez d’abord les échecs définitifs des échecs temporaires, puis décidez s’il faut réessayer.
- Refus temporaire / Deferral
- Le serveur refuse provisoirement l’e-mail, par exemple par manque de ressources ou en raison d’une limitation du débit. Les réponses SMTP 4xx sont fréquentes dans ce cas. Le service d’envoi peut réessayer selon sa politique, mais la boîte de réception ne détermine ni la fréquence ni le nombre de tentatives.
- Message-ID et identifiant du fournisseur
- Identifiants servant à relier un e-mail aux journaux. Le Message-ID de l’en-tête peut différer de l’identifiant de tâche renvoyé par l’API d’envoi. En cas de problème, consignez-les séparément et indiquez leur source : ne vous contentez pas de noter « envoi réussi ».
Identité de l’expéditeur
- SPF
- SPF utilise le DNS pour déclarer quels serveurs sont autorisés à envoyer des e-mails pour le domaine d’enveloppe. La réussite de SPF ne prouve pas que l’adresse From affichée est celle d’un expéditeur fiable, ni que le message arrivera dans la boîte de réception.
- DKIM
- DKIM ajoute une signature de domaine à certaines parties du message, que le destinataire vérifie à l’aide d’une clé publique. Une signature valide indique que les parties signées ont passé la vérification ; elle ne garantit ni la sécurité du contenu ni la véracité des engagements commerciaux de l’expéditeur.
- DMARC
- DMARC combine les résultats d’authentification SPF ou DKIM avec l’alignement du domaine visible dans From, puis définit une politique de traitement. Une politique de rejet ne garantit pas la distribution. Les transferts et les envois via des tiers nécessitent toujours une configuration adaptée.
- From et Return-Path
- From désigne l’adresse de l’auteur généralement visible par l’utilisateur ; Return-Path est souvent associé à l’adresse de retour des rebonds. Leur différence ne signifie pas nécessairement que l’e-mail est frauduleux, mais il faut les examiner séparément pour vérifier l’identité et enquêter sur les rebonds.
Contenu et vérification
- OTP / code à usage unique
- Code qui vérifie une identité pour une demande donnée et pendant une durée limitée. Recevoir un OTP prouve uniquement que l’e-mail est arrivé. Sa validité dépend aussi de la demande à laquelle il est associé, de sa durée de validité et de son éventuelle utilisation. Ne partagez jamais un code encore valide dans un ticket d’assistance.
- Corps HTML et texte brut
- Un même e-mail peut contenir une version HTML mise en forme et une version en texte brut. Vérifiez les deux : les liens importants, les codes de vérification et les informations utiles doivent être identiques et ne doivent pas apparaître uniquement dans une image.
- Image intégrée CID
- Image référencée dans le contenu de l’e-mail à l’aide d’un identifiant interne, souvent transmise avec les pièces jointes. Si un service d’e-mail temporaire ne conserve pas ces images, le message peut s’afficher de manière incomplète. Cela ne signifie pas que l’expéditeur n’a pas envoyé le corps du message : vérifiez la structure de l’e-mail d’origine.
- Expiration du code et de l’adresse e-mail
- Le site qui envoie le code détermine sa durée de validité ; le service de réception gère le compte à rebours de l’adresse e-mail. Prolonger la durée de l’adresse ne prolonge pas celle du code, et changer d’adresse ne met pas automatiquement à jour le compte déjà créé sur le site.
Quand vous rencontrez ces termes, demandez-vous d’abord :
« Validé » par qui ?
La validation de l’identité, de la tâche d’envoi et du code de vérification sont trois résultats différents. Notez la source du journal et l’élément vérifié.
« Réussi » à quelle étape ?
La soumission par l’application, l’acceptation par le serveur et la lecture de l’e-mail par l’utilisateur sont des choses différentes. Cherchez une preuve à l’étape suivante avant de conclure sur l’ensemble du parcours.
Quel délai a expiré ?
Distinguez d’abord l’adresse, le code de vérification et la session. Ne renouvelez que ce qui a réellement expiré ; évitez de changer d’adresse ou de demander de nouveaux codes à répétition.
Des délais distincts qui ne se prolongent pas mutuellement
| Élément | Qui définit le délai ? | Limite |
|---|---|---|
| E-mail temporaire | Compte à rebours de l’adresse défini par le service de réception | Prolonger la durée de l’adresse ne prolonge pas celle du code du site |
| OTP | Site qui envoie le code | Recevoir l’e-mail ne signifie pas que le code est encore valide |
| Historique de transfert | Fenêtre d’historique de 30 jours sur notre service | N’affecte pas les copies déjà reçues dans la boîte de destination |