La seule exigence
Votre application doit pouvoir envoyer des e-mails à n’importe quelle adresse. Les fournisseurs d’e-mail en mode sandbox ou test n’envoient qu’aux adresses que vous avez vérifiées : leurs e-mails ne peuvent donc atteindre aucune boîte de réception de test, la nôtre comprise.
Vérifier l’adresse dans l’application
Dans l’application, ouvrez Dépannage depuis le menu du compte et collez l’adresse. Vous voyez si quelque chose nous est parvenu pour elle et ce que nous avons refusé, avec la raison.
Quand nous refusons un e-mail, la ligne de l’adresse dans Comptes l’indique aussi. Une adresse qui attend depuis quelques minutes sans e-mail affiche un lien Rien n’arrive ?.
Rien ne nous est parvenu ? L’e-mail s’est alors arrêté avant de nous atteindre. Passez en revue les causes ci-dessous.
Les e-mails n’arrivent plus sur aucune adresse en même temps, y compris celles qui fonctionnaient avant ? Consultez notre page d’état pour voir s’il y a un incident.
Causes habituelles
- Le fournisseur d’e-mail de l’application n’envoie qu’aux adresses vérifiées. Les modes sandbox et test, comme Amazon SES avant l’accès production ou Resend sans domaine, ignorent sans prévenir toutes les autres adresses. Consultez la liste des fournisseurs ci-dessous.
- L’application ne l’a pas envoyé. Cherchez le message dans les journaux de l’application ou dans le tableau de bord de son fournisseur d’e-mail. Une inscription qui a échoué, un e-mail désactivé dans les paramètres ou une erreur dans une tâche en arrière-plan se présentent tous de la même façon de notre côté.
- Le fournisseur a ignoré l’adresse. Si un e-mail précédent vers l’adresse a été rejeté (par exemple après son expiration), le fournisseur l’a peut-être ajoutée à sa liste de suppression et n’y enverra plus rien. Retirez-la de la liste, ou utilisez une nouvelle adresse.
- L’adresse est mal saisie. Copiez-la depuis sa ligne au lieu de la retaper. Un +tag après le nom ne pose pas de problème : name+run2@ arrive bien à name@.
- L’application est soumise à une limite de débit. Les services d’authentification plafonnent leurs e-mails : l’e-mail intégré de Supabase en envoie 2 par heure (30 par heure par défaut avec votre propre SMTP), et celui de Amazon Cognito 50 par jour par compte AWS. Une suite de tests qui crée souvent des inscriptions atteint le plafond en premier.
- L’adresse a expiré ou son projet est archivé. Les e-mails qui lui sont adressés sont refusés. Prolongez une adresse avant son expiration, ou créez-en une nouvelle.
- Nous l’avons refusé. Les messages de plus de 5 Mo sont refusés, une adresse reçoit au maximum 60 e-mails par heure, et les e-mails de quelques grands services grand public (comme Instagram ou TikTok) sont refusés sauf si le projet bénéficie d’une exception. L’adresse indique quand nous refusons quelque chose, et pourquoi.
Fournisseurs d’e-mail qui n’envoient qu’à certaines adresses
Fréquent quand une application est récente. Chaque cas correspond à un paramètre du fournisseur d’e-mail de l’application ; aucune boîte de réception de test ne peut recevoir un e-mail qu’il n’envoie pas.
Amazon SES
Les nouveaux comptes démarrent en sandbox, qui n’envoie qu’aux adresses et domaines vérifiés. Chaque région AWS a sa propre sandbox. Solution : demandez l’accès production pour la région depuis laquelle votre application envoie. Documentation
E-mail intégré de Supabase Auth
N’envoie qu’aux membres de l’équipe de votre projet Supabase, et seulement 2 e-mails par heure. Solution : configurez un SMTP personnalisé sous Authentication. Augmentez ensuite la limite horaire d’e-mails sous Rate Limits si vos tests créent souvent des inscriptions. Documentation
Resend
Tant que vous n’avez pas vérifié de domaine (en envoyant depuis onboarding@resend.dev), il n’envoie qu’à l’e-mail de votre propre compte Resend. Solution : vérifiez un domaine et envoyez depuis une adresse sur ce domaine. Documentation
Mailgun
Un domaine sandbox n’envoie qu’à 5 destinataires autorisés au maximum, qui doivent chacun confirmer. Solution : envoyez depuis votre propre domaine. Mailgun exige pour cela un forfait payant ou une carte enregistrée. Documentation
Postmark
Tant que Postmark n’a pas approuvé le compte, il n’envoie qu’aux adresses sur des domaines que vous avez vérifiés. Solution : demandez l’approbation dans votre compte Postmark. Documentation
Firebase Authentication, Clerk et SendGrid envoient à n’importe quelle adresse. C’est aussi le cas des expéditeurs intégrés de Auth0 et Amazon Cognito, mais celui de Auth0 n’envoie que 10 e-mails par minute et celui de Cognito seulement 50 par jour par compte AWS (le compteur est réinitialisé à 09:00 UTC) : configurez donc votre propre fournisseur pour les exécutions de tests.
Ce que Proxy Mail QA refuse
Les e-mails adressés à une adresse qui n’existe pas, a été supprimée ou a expiré sont refusés. Pour les adresses actives, nous refusons les e-mails dans les cas suivants :
- Trop volumineux. Le message dépassait 5 Mo, la taille maximale acceptée. L’expéditeur a été informé de ne pas réessayer : il n’arrivera donc pas.
- Limite horaire. L’adresse avait déjà reçu 60 e-mails au cours de la dernière heure. L’expéditeur a été invité à réessayer plus tard : il peut donc encore arriver.
- Limite quotidienne. Votre espace avait atteint sa limite quotidienne d’e-mails. L’expéditeur a été invité à réessayer plus tard : il peut donc arriver après la réinitialisation de la limite à minuit UTC.
- Site bloqué. Proxy Mail QA ne fonctionne pas avec ce site : ses e-mails sont donc refusés et n’arriveront pas. Si vous le testez avec autorisation, un responsable de projet peut demander une exception dans les paramètres du projet.
Chacun de ces refus apparaît sur l’adresse avec son heure. Nous ne conservons que la raison, l’heure et la taille, jamais l’expéditeur ni le message, et ces informations sont supprimées avec l’adresse.
Refusé avant de nous parvenir
Nos serveurs de messagerie sont ceux de Cloudflare. Ils refusent certains e-mails avant que Proxy Mail QA ne les voie : le plus souvent parce qu’ils échouent à SPF, DKIM ou DMARC pour le domaine d’envoi, et parfois parce qu’ils sont abandonnés ou ne peuvent pas être distribués. Chacun apparaît sur l’adresse comme bloqué, avec le domaine de l’expéditeur, ses résultats SPF, DKIM et DMARC et la raison, et l’indice affiché quand une attente ne trouve rien le précise. Corriger les enregistrements du domaine d’envoi suffit généralement, et cela compte au-delà des tests : les vraies boîtes de réception refusent les mêmes e-mails.
Toujours bloqué ?
Écrivez à hello@proxymail.qa en indiquant l’adresse de test, le moment où l’application a envoyé l’e-mail (avec votre fuseau horaire) et le fournisseur d’e-mail utilisé par l’application. Merci de ne pas envoyer de mots de passe ni de clés d’API.