Notre recommandation, d’emblée. Nous développons Proxy Mail QA, nous ne sommes donc pas neutres. Pour tester un formulaire d’inscription, nous le recommandons quand vous avez besoin d’une nouvelle adresse e-mail réelle à chaque essai, à laquelle votre application écrit via son vrai fournisseur d’e-mail, et que vous voulez le code ou le lien de vérification sans fouiller votre propre boîte de réception. Si vous voulez seulement voir les e-mails envoyés par votre application pendant le développement sur votre machine, sans qu’ils partent nulle part, un capteur d’e-mails local comme Mailpit, ou la boîte de réception de test de Mailtrap, convient mieux. Si vous avez aussi besoin de codes SMS, regardez Mailosaur ou MailSlurp. Proxy Mail QA ne gère que l’e-mail, et ses adresses expirent après 1 à 30 jours : il ne convient donc pas aux comptes que vous voulez garder.
Pourquoi chaque essai demande une nouvelle adresse
- Une inscription ne fonctionne qu’une fois par adresse. Le deuxième essai avec la même adresse teste « Vous avez déjà un compte », pas l’inscription.
- Les boîtes de réception partagées mélangent les codes. Quand deux personnes ou deux tests utilisent une même boîte, l’un récupère le code de l’autre, et le test échoue sans raison liée à votre application.
- Votre propre adresse n’est pas une donnée de test. Elle mélange e-mails de test et vrais e-mails, ne peut pas être confiée à un collègue ou à une suite de tests, et finit dans la base de données de votre application comme un faux client.
Les options, honnêtement
| Option | Utile pour | Points d’attention |
|---|---|---|
Votre propre Gmail avec des alias plus (you+test1@gmail.com) |
Une ou deux vérifications rapides | Chaque essai arrive dans votre boîte personnelle. Certains formulaires refusent les alias plus. Difficile à automatiser |
| Une boîte de réception d’équipe partagée | Quelques vérifications manuelles | Les codes de différents tests se mélangent. Pourquoi cela casse les tests |
| Un capteur d’e-mails local (Mailpit) ou la boîte de réception de test de Mailtrap | Voir les e-mails de votre application pendant le développement, sans les envoyer | Les e-mails ne passent jamais par votre vrai fournisseur : le mode sandbox, SPF, DKIM et DMARC ne sont pas testés. Votre application doit être configurée pour l’utiliser |
| Sites publics de boîtes jetables | Rien dans un vrai projet | N’importe qui peut lire la boîte, et beaucoup de formulaires bloquent leurs domaines |
| Proxy Mail QA | Une nouvelle adresse privée à chaque essai, en préproduction ou en local, à la main ou depuis un test ou un agent | E-mail uniquement. Votre fournisseur doit être sorti du mode sandbox. Les adresses expirent |
Ce que Proxy Mail QA vous apporte
- Une nouvelle adresse en un clic, dans l’application, depuis Proxy Mail QA for Chrome dans le champ e-mail du formulaire, ou depuis le API, le paquet npm ou un agent IA. Les adresses sont sur
mailclub.dev. Si un formulaire bloque ce domaine, utilisezenable.liouvalida.te.it. - Un persona de test associé : un prénom et un nom fictifs, un nom d’utilisateur, une date de naissance pour l’âge choisi, un pays, et un mot de passe si vous en demandez un.
- Le code ou le lien, extrait. Il s’affiche sur la ligne de l’adresse dans l’application, dans une carte sur la page avec l’extension, ou est renvoyé par
wait_for_codeetwait_for_link. Proxy Mail QA n’ouvre jamais les liens : les liens à usage unique restent donc valides. - Privée et en réception seule. Personne en dehors de votre projet ne peut lire la boîte, et elle ne peut pas envoyer. Quand une adresse expire, les e-mails qui lui sont adressés sont refusés, tout est supprimé dans l’heure, et le nom n’est jamais réutilisé.
- Des vérifications sur l’e-mail (
check_email) : SPF, DKIM et DMARC, liens verslocalhostou vers duhttpsimple, destination du lien, mention ou non de sa date d’expiration, et présence d’une partie en texte brut.
Tester le champ e-mail lui-même
Chaque adresse est fournie avec des variantes qui arrivent toujours dans sa boîte de réception, pour vérifier que votre formulaire ne refuse pas des adresses valides :
| Votre formulaire doit | Exemples |
|---|---|
| Accepter, et l’e-mail arrive | Majuscules, +signup, +o'brien, +r&d, +team/50%, le maximum de 64 caractères avant le @ |
| Accepter, même si aucune boîte ne peut les recevoir | "john doe"@mailclub.dev, josé@mailclub.dev (utile pour vérifier ce que fait votre application quand la livraison échoue) |
| Refuser avant tout envoi | Pas de @, deux @, une espace, deux points à la suite |
Obtenez-les avec get_address_variants depuis un agent, GET /v1/addresses/{address}/variants depuis le REST API, ou qa.variants(address) dans un test. La liste complète se trouve dans adresses e-mail inhabituelles. Pour vérifier qu’un formulaire accepte un domaine en trois parties, créez l’adresse sur valida.te.it.
Quand l’e-mail n’arrive pas
En général, le problème vient de l’envoi, pas du formulaire :
- Le fournisseur d’e-mail est en mode sandbox ou test et n’envoie qu’aux adresses que vous avez vérifiées : Amazon SES avant l’accès production, Resend sans domaine vérifié, une sandbox Mailgun, Postmark avant approbation, ou l’e-mail intégré de Supabase, qui n’envoie qu’à votre équipe, et seulement 2 e-mails par heure.
- L’e-mail a été refusé, par exemple pour échec de DMARC. La ligne de l’adresse affiche les e-mails refusés par Proxy Mail QA, avec la raison, et
check_deliveryexplique la cause probable. - Il provient d’un site bloqué. Les e-mails de quelques grands services grand public, comme Google, Instagram et Amazon, sont refusés : Proxy Mail QA sert à tester votre propre application.
La compétence email-delivery-troubleshooting du plugin Proxy Mail QA pour Qoder passe ces points en revue avec votre agent et corrige la cause. Plus d’informations dans dépannage.
Combien ça coûte
L’offre Free couvre 500 adresses au total (jusqu’à 50 par jour) et environ 500 e-mails entrants par jour, avec l’extension, le API et le MCP server inclus. L’offre Team coûte US$5 par mois pour toute une organisation, sans limite d’adresses.
À quoi il ne sert pas
- Les comptes que vous voulez garder. Les adresses durent de 1 à 30 jours.
- Les données de vraies personnes. Les personas de test sont fictifs ; gardez-les ainsi.
- Votre propre domaine. La réception sur une adresse du domaine de votre entreprise n’est pas encore disponible.
- L’envoi d’e-mails ou de SMS. Il reçoit uniquement des e-mails.