What is Reusable.Email?

Reusable.Email is a disposable email service that lets you create temporary email addresses instantly — no signup, no forms, no verification required. Unlike traditional temp mail services that auto-delete after minutes, Reusable.Email offers reusable addresses with retention from 90 to 365 days. Use public inboxes for quick verifications, private inboxes with password protection for sensitive signups, or managed inboxes with full IMAP/SMTP support for a permanent disposable address that works with any email client.

Is Reusable.Email free?

Public and private inboxes are completely free with no limits on usage. You can create unlimited free inboxes without any account or payment. For advanced features, managed inboxes cost a one-time $3 payment (not a subscription) and include IMAP/SMTP access, send capability, and 365-day retention. Custom domains are free to add with DNS verification — $10/year unlocks unlimited aliases and catch-all routing. Whitelabel plans at $30/month are available for businesses needing their own branded email infrastructure. There are no hidden fees, ads, or subscription traps.

How long are emails retained?

Email retention depends on your inbox type. Public inboxes retain emails for 90 days from receipt — enough for most verification and signup workflows. Private (password-protected) inboxes extend retention to 180 days, giving you more time to access important emails. Managed inboxes offer the longest retention at 365 days with unlimited storage, plus the ability to organize emails into custom folders. All inbox types allow you to export your data at any time. Emails are automatically and permanently deleted after the retention period expires.

Can I send emails from Reusable.Email?

Yes — sending is available with managed inboxes ($3 one-time payment). Managed inboxes include full SMTP access via smtp.reusable.email on port 587 with STARTTLS encryption, allowing you to send email to any address worldwide from any standard email client including Apple Mail, Thunderbird, Outlook, and Gmail. Free public and private inboxes support sending only to other Reusable.Email addresses. Custom domain users can also send as their domain aliases, with SPF, DKIM, and DMARC authentication configured automatically.

How does custom domain support work?

Adding a custom domain to Reusable.Email is free — you configure the DNS records we provide (MX, SPF, DKIM, and DMARC) and we verify your domain automatically. Once verified, all email sent to any address at your domain is routed to your managed inbox. Subscribe for $10/year to unlock unlimited aliases (sales@, support@, info@ etc.), catch-all routing that captures email to any address at your domain, and send-as capability from any alias. Custom domains eliminate blocklist issues entirely since you control the domain reputation.

What is a managed inbox?

A managed inbox is a permanent, full-featured email address on Reusable.Email. For a one-time $3 payment (no subscription), you get IMAP access via imap.reusable.email:993 and SMTP access via smtp.reusable.email:587, enabling use with any standard email client — Apple Mail, Thunderbird, Outlook, or any app that supports email account setup. Managed inboxes include the ability to send email to any address worldwide, 365-day email retention, unlimited storage, spam filtering, custom folder organization, and the ability to toggle between public and private visibility modes.

Privacy depends on your inbox type. Public inboxes are visible to anyone who knows the address — they are designed for non-sensitive use like quick verifications. Private inboxes add password protection so only people with the password can access the emails. Managed inboxes are password-protected and offer additional security through standard email authentication protocols. Reusable.Email does not sell user data, does not serve advertisements, and does not track users across websites. Analytics are privacy-focused with IP tracking disabled and email addresses sanitized from all tracking data. Payments are processed securely through Stripe.

Can I use my own email client?

Yes. Managed inboxes support standard IMAP and SMTP protocols, making them compatible with virtually any email client. Connect using imap.reusable.email on port 993 for receiving and smtp.reusable.email on port 587 for sending, both with STARTTLS encryption. This works with Apple Mail, Mozilla Thunderbird, Microsoft Outlook, Gmail (via 'add account'), K-9 Mail on Android, and any other application that supports standard email account setup. Your managed inbox credentials are generated automatically when you upgrade.

Test SMTP : tester les e-mails sortants sans envoyer à de vraies boîtes de réception

Name: Reusable.Email
Brand: Reusable.Email
Availability: InStock

Chaque application qui envoie des e-mails a besoin d'un moyen de tester cet e-mail sans l'envoyer aux vrais utilisateurs. Un environnement de staging mal configuré qui envoie 10 000 notifications de test à des clients réels n'est pas hypothétique — c'est un rite de passage pour suffisamment d'équipes que l'industrie a construit plusieurs catégories d'outils pour le prévenir.

La question n'est pas si vous avez besoin du test SMTP. C'est quelle approche correspond à votre situation.

Pourquoi le test SMTP compte

Les e-mails sortants se trompent de manière prévisible :

Le staging envoie aux adresses de production. Un développeur oublie de mettre à jour la liste des destinataires et les données de test atteignent les vraies boîtes de réception.
Les modèles se rendent mal. L'e-mail HTML est sa propre discipline. Ce qui semble correct dans un navigateur peut se casser dans Outlook, Gmail ou Apple Mail.
Les e-mails transactionnels contiennent des données incorrectes. Les liens de réinitialisation de mot de passe pointent vers localhost. Les montants des factures affichent les valeurs de test. Les codes de vérification sont des chaînes codées en dur.
L'e-mail n'est pas envoyé du tout. Les erreurs de configuration SMTP échouent silencieusement dans de nombreux cadres.

Le test capture tout cela avant qu'il n'atteigne les utilisateurs. Les trois approches principales traitent chacune différentes parties du problème.

Approche 1 : Serveurs SMTP faux

Un faux serveur SMTP accepte les e-mails sur SMTP mais ne les envoie nulle part. Il stocke les messages localement et fournit une interface utilisateur pour les inspecter.

Mailhog

Mailhog est le serveur SMTP faux open-source le plus largement utilisé. Vous l'exécutez localement (généralement via Docker), pointez la configuration SMTP de votre application vers lui et tous les e-mails sortants sont capturés dans l'interface Web de Mailhog.

# docker-compose.yml
services:
  mailhog:
    image: mailhog/mailhog
    ports:
      - "1025:1025"   # SMTP
      - "8025:8025"   # Interface Web

Configurez votre application pour envoyer à localhost:1025 et chaque e-mail apparaît à http://localhost:8025.

Avantages : Gratuit, open source, zéro dépendances externes, excellente pour le développement local.

Inconvénients : Auto-hébergé (nécessite Docker), pas de vraie livraison, pas facilement disponible dans les environnements CI, pas d'accès IMAP, la maintenance a stoppé. Voir notre guide des alternatives Mailhog pour plus d'options.

smtp4dev

Similaire à Mailhog mais construit sur .NET. Offre une interface légèrement plus poli et est activement maintenu. Même concept — faux SMTP, capture locale, pas de livraison.

Meilleur pour : Les équipes lourdes sur .NET qui veulent un outil de capture SMTP local qui s'intègre à leur stack existant.

Quand le faux SMTP est le bon outil

Utilisez un faux serveur SMTP quand :

Vous développez localement et voulez voir quels e-mails votre application envoie
Vous devez inspecter les modèles HTML visuellement
Vous n'avez pas besoin de tester la vraie livraison ou la récupération IMAP
Votre équipe est à l'aise avec Docker et l'auto-hébergement

Approche 2 : Bacs à sable d'e-mail

Un bac à sable d'e-mail est un service hébergé qui capture les e-mails sortants, similaire à un faux serveur SMTP mais sans la surcharge de l'auto-hébergement. Mailtrap est le plus connu.

Comment fonctionnent les bacs à sable

Vous configurez votre application pour envoyer les e-mails par le serveur SMTP du bac à sable. Le bac à sable capture chaque message, l'affiche dans un tableau de bord Web et fournit des outils pour inspecter les en-têtes, le rendu HTML, les scores de spam, et plus.

Aucun e-mail n'est réellement livré. Le bac à sable est une impasse par conception — c'est là pour prévenir exactement le type d'envois accidentels que le test SMTP existe pour arrêter.

Mailtrap

Mailtrap fournit des boîtes de réception basées sur des projets, des fonctionnalités de collaboration d'équipe, des aperçus de rendu HTML et une API pour les vérifications automatisées. La couche gratuite a des limites ; les plans payants coûtent 15-35 $/mois.

Avantages : Hébergé (pas de Docker), bonne interface, fonctionnalités d'équipe, aperçu HTML, analyse du spam.

Inconvénients : Tarification d'abonnement, pas de vraie livraison en mode bac à sable, pas d'accès IMAP, overkill pour le simple test « cet e-mail arrive-t-il ? ». Voir Alternatives Mailtrap pour une comparaison complète.

Email Ethereal

Construit par l'équipe Nodemailer, Ethereal fournit des comptes SMTP faux gratuits. Vous créez des identifiants jetables, envoyez l'e-mail vers eux et consultez les messages dans l'interface Web d'Ethereal.

Avantages : Gratuit, aucune inscription requise, parfait pour les tests rapides.

Inconvénients : Pas de persistance (les messages expirent), pas de fonctionnalités d'équipe, pas d'API.

Quand les bacs à sable sont le bon outil

Utilisez un bac à sable d'e-mail quand :

Votre équipe a besoin d'une vue partagée des e-mails de test
Vous voulez les aperçus de rendu HTML et le vérification du score de spam
Vous ne voulez rien auto-héberger
Vous n'avez pas besoin de tester la vraie livraison d'e-mail ou la récupération IMAP

Approche 3 : Vraies boîtes de réception à la demande

La troisième approche consiste à utiliser de vraies boîtes de réception e-mail avec de vrais identifiants SMTP et IMAP. Vous envoyez un e-mail via SMTP réel, il est livré à une vraie boîte de réception et vous le relisez via IMAP réel. De bout en bout.

Boîtes de réception gérées Reusable.Email

Une boîte de réception gérée sur Reusable.Email est un compte e-mail complet. Elle a des identifiants SMTP pour l'envoi (smtp.reusable.email:587, STARTTLS) et des identifiants IMAP pour la lecture (imap.reusable.email:993, SSL/TLS).

La différence clé avec les bacs à sable : l'e-mail est réellement livré. Vos tests vérifient la pipeline d'e-mail entière, pas seulement la moitié de l'envoi.

Coût : 3 $ par boîte de réception, une seule fois. Pas d'abonnement.

Exemple de configuration rapide

Configurez votre application pour envoyer via les identifiants SMTP d'une boîte de réception gérée :

# Django settings.py
EMAIL_HOST = "smtp.reusable.email"
EMAIL_PORT = 587
EMAIL_USE_TLS = True
EMAIL_HOST_USER = "[email protected]"
EMAIL_HOST_PASSWORD = "votre-mot-de-passe-boîte"

// Node.js avec nodemailer
const transporter = nodemailer.createTransport({
  host: "smtp.reusable.email",
  port: 587,
  secure: false, // STARTTLS
  auth: {
    user: "[email protected]",
    pass: "votre-mot-de-passe-boîte",
  },
});

Maintenant votre environnement de staging ou de test envoie de vrais e-mails via le serveur SMTP de Reusable.Email. Vous pouvez lire ces e-mails via IMAP dans vos assertions de test ou simplement les vérifier dans n'importe quel client e-mail.

Quand les vraies boîtes de réception sont le bon outil

Utilisez les vraies boîtes de réception à la demande quand :

Vous devez tester la livraison d'e-mail de bout en bout, pas seulement l'envoi
Vos tests ont besoin de lire les e-mails via IMAP (analyser les codes de vérification, vérifier les liens)
Vous voulez des e-mails de staging isolés mais réels
Vous avez besoin des identifiants SMTP pour l'intégration avec des services externes
Vous voulez un coût unique au lieu d'un abonnement mensuel

Choisir la bonne approche

Besoin	Faux SMTP	Bac à sable	Vraie boîte
Aperçu e-mail dev local	Oui	Oui	Overkill
Inspection du modèle HTML	Basique	Meilleur	Via client
Assertions d'e-mail CI/CD	Difficile	Via API	Via IMAP
Test de livraison de bout en bout	Non	Non	Oui
Test de récupération IMAP/POP3	Non	Non	Oui
Collaboration d'équipe	Non	Oui	Identifiants partagés
Zéro ops	Non (Docker)	Oui	Oui
Coût	Gratuit	15-35 $/mo	3 $ une fois

De nombreuses équipes utilisent plus d'une approche. Mailhog pour le développement local, de vraies boîtes de réception pour CI et staging. Les approches ne s'excluent pas mutuellement.

Erreurs courantes du test SMTP

Coder en dur les identifiants SMTP de production dans les configs de test. Si votre suite de test utilise accidentellement les identifiants SendGrid ou SES de production, les e-mails de test vont aux adresses réelles. Utilisez les fichiers de configuration spécifiques à l'environnement et ne partagez jamais les identifiants entre les environnements.

Ne pas tester la boucle complète. Vérifier que sendmail() n'a pas levé une exception n'est pas un test d'e-mail. L'e-mail peut toujours être mal formé, manquer d'en-têtes ou être capturé par les filtres anti-spam. Relisez-le via IMAP pour vérifier le contenu réel.

Ignorer les problèmes d'encodage. Les e-mails HTML avec des caractères spéciaux, des noms Unicode ou des sujets non-ASCII échouent dans des clients e-mail spécifiques. Testez avec des données réalistes, pas seulement des chaînes ASCII.

Partager une seule boîte de réception sur plusieurs exécutions de test en parallèle. Si deux jobs CI envoient à la même boîte de réception de test simultanément, leurs e-mails s'entrelacent et les tests deviennent flaky. Utilisez une boîte de réception par suite de test ou filtrez sur des ID de message uniques.

Tester uniquement le chemin heureux. Testez également ce qui se passe quand les identifiants SMTP sont mal, quand le serveur est inaccessible et quand l'adresse du destinataire est invalide. Votre application doit gérer ces défaillances avec élégance.

Configuration du test SMTP dans les cadres courants

La plupart des cadres Web ont un fichier de configuration ou une variable d'environnement pour les paramètres SMTP. Voici comment pointer les cadres courants vers une boîte de réception gérée :

Rails (config/environments/staging.rb) :

config.action_mailer.smtp_settings = {
  address: "smtp.reusable.email",
  port: 587,
  user_name: "[email protected]",
  password: ENV["SMTP_PASSWORD"],
  authentication: :plain,
  enable_starttls_auto: true,
}

Laravel (.env) :

MAIL_MAILER=smtp
MAIL_HOST=smtp.reusable.email
MAIL_PORT=587
[email protected]
MAIL_PASSWORD=votre-mot-de-passe-boîte
MAIL_ENCRYPTION=tls

Spring Boot (application-staging.properties) :

spring.mail.host=smtp.reusable.email
spring.mail.port=587
[email protected]
spring.mail.password=${SMTP_PASSWORD}
spring.mail.properties.mail.smtp.starttls.enable=true

Le modèle est le même dans tous les cas : pointez l'hôte SMTP vers smtp.reusable.email, port 587, STARTTLS activé et fournissez les identifiants de boîte de réception gérée.

Et ensuite ?

Pour une plongée plus profonde dans la création de tests d'e-mail automatisés, voir Comment construire un environnement de test d'e-mail avec une API de courrier jetable. Pour l'aperçu complet du développement des capacités de Reusable.Email, commencez par le guide API e-mail pour les développeurs.