Identifiants SMTP & IMAP à la demande : donnez à chaque utilisateur sa propre boîte de réception e-mail

Certains produits ont besoin de donner aux utilisateurs leur propre vrai adresse e-mail. Pas un alias de redirection, pas un point de terminaison webhook — une vraie boîte de réception avec des identifiants SMTP et IMAP qui fonctionne avec n'importe quel client e-mail.

Les systèmes de tickets ont besoin de recevoir les e-mails des clients à support-{id}@domaine.com. Les outils de gestion de projet ont besoin de boîtes de réception par projet. Les plates-formes de service client ont besoin que les agents envoient et reçoivent en tant que eux-mêmes. Les outils CRM ont besoin de tracker les conversations e-mail nativement.

La solution traditionnelle consiste à exécuter votre propre serveur de courrier. L'alternative moderne est la création de boîtes de réception à la demande via un service qui gère l'infrastructure.

L'approche traditionnelle : exécutez votre propre serveur de courrier

La configuration de Postfix, Dovecot et l'infrastructure de support pour le courrier multi-locataires est une tâche sérieuse :

• Configuration DNS : Enregistrements MX, SPF, DKIM, DMARC — par domaine
• Gestion du serveur : Postfix pour SMTP, Dovecot pour IMAP, SpamAssassin ou rspamd pour le filtrage
• Stockage : Le stockage des e-mails croît de manière imprévisible ; vous avez besoin de surveillance et de politiques de nettoyage
• Livraison : Gestion de la réputation IP, boucles de rétroaction, gestion des rebonds
• Sécurité : Certificats TLS, authentification, limitation de débit, prévention des abus
• Surveillance : Profondeur de file d'attente, taux de livraison, taux de rebond, utilisation du stockage

C'est un travail à temps plein pour une équipe d'opérations. Pour la plupart des produits SaaS, l'infrastructure e-mail n'est pas le produit — c'est une fonctionnalité de soutien. Investir du temps d'ingénierie dans les opérations du serveur de courrier distrait de la construction de ce que vos utilisateurs paient réellement.

L'approche Reusable.Email

Au lieu d'exécuter les serveurs de courrier, créez des boîtes de réception gérées via Reusable.Email. Chaque boîte de réception gérée est un compte e-mail complet avec :

• IMAP : imap.reusable.email:993 (SSL/TLS) — lire l'e-mail par programme
• SMTP : smtp.reusable.email:587 (STARTTLS) — envoyer un e-mail comme l'adresse de boîte de réception
• POP3 — pour les clients qui le préfèrent
• Conservation de 365 jours
• Dossiers personnalisés, filtrage du spam, redirection

Coût : 3 $ par boîte de réception, une seule fois. Pas de frais mensuels par utilisateur.

Pour les produits qui ont besoin de la création de boîte de réception par programme à grande échelle, la couche white-label (30 $/mois) ajoute :

• API REST pour créer et gérer les boîtes de réception
• Webhooks pour les événements e-mail en temps réel
• Boîtes de réception gérées illimitées
• Votre propre domaine, zéro marque Reusable.Email
• Panneau d'administration et analytique d'utilisation

Architecture : comment cela s'intègre dans un produit SaaS

Voici comment une intégration typique fonctionne :

1. L'utilisateur s'inscrit à votre produit

Quand un nouvel utilisateur (ou projet, ou file d'attente de ticket) a besoin d'une adresse e-mail, votre backend crée une boîte de réception gérée via l'API white-label.

POST /api/inboxes
{
  "address": "user-12345@votredomaine.com",
  "display_name": "Support - Acme Corp"
}

L'API retourne les identifiants IMAP/SMTP pour la nouvelle boîte de réception.

2. Stocker les identifiants dans votre base de données

Mappez les identifiants de boîte de réception à l'utilisateur dans votre base de données :

table users:
  id: 12345
  name: "Acme Corp"
  inbox_address: "user-12345@votredomaine.com"
  imap_user: "user-12345@votredomaine.com"
  imap_pass: (crypté)
  smtp_user: "user-12345@votredomaine.com"
  smtp_pass: (crypté)

3. Recevoir un e-mail — deux options

Option A : Interrogation IMAP. Votre backend se connecte à IMAP périodiquement et extrait les nouveaux messages dans votre application. Cela fonctionne pour le traitement par batch ou les situations où une latence de quelques secondes est acceptable.

Option B : Webhooks. La couche white-label envoie une requête POST HTTP à votre point de terminaison quand l'e-mail arrive. C'est temps réel et ne nécessite pas d'interrogation. Voir Comment recevoir les e-mails via API pour les détails d'implémentation.

4. Envoyer un e-mail

Quand l'utilisateur doit envoyer un e-mail depuis votre produit (répondre à un client, envoyer une mise à jour), votre backend envoie via SMTP en utilisant les identifiants de boîte de réception :

import smtplib
from email.mime.text import MIMEText

def send_as_user(user, to_address, subject, body):
    msg = MIMEText(body)
    msg["Subject"] = subject
    msg["From"] = user.inbox_address
    msg["To"] = to_address

    with smtplib.SMTP("smtp.reusable.email", 587) as server:
        server.starttls()
        server.login(user.smtp_user, user.smtp_pass)
        server.send_message(msg)

Le destinataire voit l'e-mail provenant de user-12345@votredomaine.com — votre domaine, votre marque.

5. Afficher dans votre interface utilisateur

Tirez les messages d'IMAP (ou recevez via webhook) et affichez-les dans l'interface de votre produit. Vos utilisateurs interagissent avec l'e-mail à l'intérieur de votre application — ils n'ont jamais besoin d'ouvrir Thunderbird ou Outlook, bien qu'ils pourraient le faire s'ils le voulaient.

Coût à l'échelle

La tarification par boîte de réception est directe :

Utilisateurs	Coût unique	Coût mensuel
10	30 $	0 $
100	300 $	0 $
1 000	3 000 $	0 $

Pour la couche white-label (recommandée pour ce cas d'usage), c'est 30 $/mois forfaitaire avec création de boîte de réception illimitée. À 100+ utilisateurs, la couche white-label est plus rentable que les boîtes de réception gérées individuelles.

Comparez cela à l'exécution de votre propre serveur de courrier : temps d'ingénierie, coûts du serveur, outils de surveillance et la charge des opérations en cours. Ou comparez aux services API d'e-mail par siège qui facturent 0,50 $ à 2,00 $ par utilisateur par mois — à 1 000 utilisateurs, c'est 500 $ à 2 000 $/mois au lieu de 30 $.

Considérations

Conservation des e-mails

Les boîtes de réception gérées conservent l'e-mail pendant 365 jours. Pour les produits qui ont besoin d'une conservation plus longue, tirez les messages d'IMAP dans votre propre base de données et stockez-les dans la couche de stockage de votre application.

Départ de l'utilisateur

Quand un utilisateur quitte votre produit, sa boîte de réception gérée existe toujours jusqu'à l'expiration de la période de conservation. Si la boîte de réception contient des données sensibles, supprimez les messages via IMAP ou arrêtez d'acheminer les messages vers elle.

Domaines personnalisés

La couche white-label prend en charge les domaines personnalisés avec MX, SPF, DKIM et DMARC auto-configurés. Les boîtes de réception de vos utilisateurs vivent à anything@votredomaine.com — aucune connexion visible à Reusable.Email. Voir le guide de domaine personnalisé e-mail pour les détails de configuration DNS.

Livraison

Parce que les boîtes de réception gérées utilisent l'infrastructure de Reusable.Email, vous bénéficiez de leur réputation IP établie et de l'authentification correctement configurée (SPF, DKIM, DMARC). C'est l'une des parties les plus difficiles d'exécuter votre propre serveur de courrier, et c'est géré pour vous.

Pour qui cela s'adresse

Cette architecture fonctionne pour tout produit où l'e-mail est une fonctionnalité, pas le produit :

• Systèmes de tickets — chaque file d'attente obtient sa propre adresse
• Plates-formes CRM — chaque représentant commercial envoie/reçoit du produit
• Outils de gestion de projet — adresses e-mail par projet
• Logiciel de service client — les agents communiquent via la plateforme
• Plates-formes de marché — les acheteurs et les vendeurs communiquent sans exposer les adresses personnelles

Si l'e-mail est le cœur de votre produit — si vous construisez le prochain Gmail ou un service de courrier temporaire dédié — le guide service d'e-mail white-label couvre l'architecture white-label complète.

Commencer

Pour le prototypage, créez quelques boîtes de réception gérées via l'interface Web Reusable.Email (3 $ chacun) et intégrez via IMAP/SMTP. Cela valide l'architecture sans s'engager à la couche white-label.

Quand vous êtes prêt pour la production, la couche white-label vous donne l'API, les webhooks et les outils d'administration pour gérer les boîtes de réception à grande échelle. Les identifiants IMAP/SMTP sous-jacents fonctionnent de la même manière — votre code d'intégration ne change pas.

Pour l'aperçu complet du développement, y compris les flux de travail de test et l'intégration webhook, voir API e-mail pour les développeurs.