On-Demand SMTP & IMAP Credentials: Give Every User Their Own Email Inbox

Some products need to give users their own real email address. Not a forwarding alias, not a webhook endpoint — a real inbox with SMTP and IMAP credentials that works with any email client. This is a surprisingly common requirement that cuts across many SaaS categories, and the traditional solution of running your own mail server is one of the most expensive infrastructure decisions a team can make.

Ticketing systems need to receive customer emails at support-{id}@domain.com. Project management tools need per-project inboxes. Customer service platforms need agents to send and receive as themselves. CRM tools need to track email conversations natively. Marketplace platforms need communication channels that protect both parties' real email addresses.

The traditional solution is running your own mail server — Postfix, Dovecot, DNS configuration, and ongoing operational burden. The modern alternative is creating inboxes on demand through a service that handles the infrastructure, giving you standard IMAP and SMTP credentials for each inbox without any server management.

The Traditional Approach: Run Your Own Mail Server

Setting up Postfix, Dovecot, and the supporting infrastructure for multi-tenant email is a serious undertaking. According to the Postfix documentation, configuring virtual mailbox hosting alone requires understanding transport maps, virtual alias domains, and mailbox storage layouts. And that is just the mail transfer agent — you still need everything else.

Here is what a self-hosted email stack requires:

• DNS configuration: MX records, SPF, DKIM, DMARC — per domain. Each domain needs its own set of DNS records, and misconfiguring any of them degrades deliverability for every user on that domain.
• Server management: Postfix for SMTP, Dovecot for IMAP, SpamAssassin or rspamd for filtering. Each component has its own configuration language, its own update cadence, and its own failure modes.
• Storage: Email storage grows unpredictably. A single user forwarding large attachments can consume gigabytes. You need monitoring, quotas, and cleanup policies.
• Deliverability: IP reputation management, feedback loops, bounce handling. Getting off email blocklists is a specialized skill that takes days of effort.
• Security: TLS certificates for all services, authentication hardening, rate limiting, abuse prevention. Email servers are constant targets for spam relay attempts and credential stuffing attacks.
• Monitoring: Queue depth, delivery rates, bounce rates, storage usage. When email stops flowing, your users find out before you do unless you have comprehensive monitoring.

This is a full-time job for an operations team. For most SaaS products, email infrastructure is not the product — it is a supporting feature. Investing engineering time in mail server ops is a distraction from building what your users actually pay for.

The total cost of ownership for self-hosted email extends far beyond server costs. A senior engineer spending even 10% of their time on mail server maintenance represents thousands of dollars in monthly opportunity cost. When something breaks at 3 AM — and it will — the incident response cost is even higher.

The On-Demand Credentials Approach

Instead of running mail servers, create managed inboxes through Reusable.Email. Each managed inbox is a complete email account with standard protocol access:

• IMAP: imap.reusable.email:993 (SSL/TLS) — read email programmatically
• SMTP: smtp.reusable.email:587 (STARTTLS) — send email as the inbox address
• POP3 — for clients that prefer it
• 365-day retention
• Custom folders, spam filtering, forwarding

Cost: $3 per inbox, one-time. No monthly per-user fees. No overage charges.

For products that need programmatic inbox creation at scale, the whitelabel tier ($30/month) adds:

• REST API for creating and managing inboxes
• Webhooks for real-time email events
• Unlimited managed inboxes
• Your own domain, zero Reusable.Email branding
• Admin panel and usage analytics

The key architectural difference from self-hosting is that you consume email infrastructure as a service rather than operating it. Your application makes API calls to create inboxes and uses standard protocols to interact with them. The complexity of mail server operations — queue management, spam filtering, deliverability, storage — is entirely abstracted away.

Architecture: How This Fits in a SaaS Product

Here is how a typical integration works, from user signup through email sending and receiving. Each step uses standard protocols and patterns that your team likely already knows.

1. User Signs Up for Your Product

When a new user (or project, or ticket queue) needs an email address, your backend creates a managed inbox via the whitelabel API.

import requests

def create_user_inbox(user_id, display_name):
    """Create a managed inbox for a new user."""
    response = requests.post(
        "https://api.reusable.email/v1/inboxes",
        headers={"Authorization": f"Bearer {API_KEY}"},
        json={
            "address": f"user-{user_id}@yourdomain.com",
            "display_name": display_name,
        },
    )

    data = response.json()
    return {
        "address": data["address"],
        "imap_user": data["imap_user"],
        "imap_pass": data["imap_pass"],
        "smtp_user": data["smtp_user"],
        "smtp_pass": data["smtp_pass"],
    }

The API returns IMAP/SMTP credentials for the new inbox. These credentials are standard — they work with imaplib, nodemailer, Thunderbird, or any other tool that speaks IMAP and SMTP.

2. Store Credentials in Your Database

Map the inbox credentials to the user in your database. Encrypt the passwords at rest — treat them with the same care as any other sensitive credential.

from cryptography.fernet import Fernet

cipher = Fernet(os.environ["ENCRYPTION_KEY"])

def store_inbox_credentials(db, user_id, credentials):
    """Store encrypted inbox credentials for a user."""
    db.execute(
        """
        INSERT INTO user_inboxes (user_id, address, imap_user, imap_pass, smtp_user, smtp_pass)
        VALUES (?, ?, ?, ?, ?, ?)
        """,
        (
            user_id,
            credentials["address"],
            credentials["imap_user"],
            cipher.encrypt(credentials["imap_pass"].encode()).decode(),
            credentials["smtp_user"],
            cipher.encrypt(credentials["smtp_pass"].encode()).decode(),
        ),
    )

3. Receive Email — Two Options

Option A: IMAP polling. Your backend connects to IMAP periodically and pulls new messages into your application. This works for batch processing or situations where a few seconds of latency is acceptable.

import imaplib
import email
from email.header import decode_header

def fetch_new_emails(credentials):
    """Fetch unread emails from a user's managed inbox."""
    imap = imaplib.IMAP4_SSL("imap.reusable.email", 993)
    imap.login(credentials["imap_user"], credentials["imap_pass"])
    imap.select("INBOX")

    status, messages = imap.search(None, "UNSEEN")
    emails = []

    for msg_id in messages[0].split():
        status, msg_data = imap.fetch(msg_id, "(RFC822)")
        msg = email.message_from_bytes(msg_data[0][1])

        subject = decode_header(msg["Subject"])[0][0]
        if isinstance(subject, bytes):
            subject = subject.decode()

        body = ""
        if msg.is_multipart():
            for part in msg.walk():
                if part.get_content_type() == "text/plain":
                    body = part.get_payload(decode=True).decode()
                    break
        else:
            body = msg.get_payload(decode=True).decode()

        emails.append({
            "from": msg["From"],
            "subject": subject,
            "body": body,
            "date": msg["Date"],
        })

    imap.logout()
    return emails

Option B: Webhooks. The whitelabel tier sends an HTTP POST to your endpoint when email arrives. This is real-time and requires no polling. See How to Receive Emails via API for implementation details on both approaches.

from flask import Flask, request

app = Flask(__name__)

@app.route("/webhook/email", methods=["POST"])
def handle_inbound_email():
    data = request.json
    recipient = data["to"]

    # Look up the user who owns this inbox
    user = db.query("SELECT * FROM users WHERE inbox_address = ?", (recipient,))
    if user:
        # Create a notification or message in your app
        create_inbox_message(user.id, data)

    return "", 200

4. Send Email

When the user needs to send email from your product (reply to a customer, send an update), your backend sends via SMTP using the inbox's credentials:

import smtplib
from email.mime.text import MIMEText
from email.mime.multipart import MIMEMultipart

def send_as_user(user, to_address, subject, body, html_body=None):
    """Send an email on behalf of a user using their managed inbox."""
    msg = MIMEMultipart("alternative")
    msg["Subject"] = subject
    msg["From"] = user.inbox_address
    msg["To"] = to_address

    msg.attach(MIMEText(body, "plain"))
    if html_body:
        msg.attach(MIMEText(html_body, "html"))

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

The recipient sees the email coming from [email protected] — your domain, your branding. Because the SMTP credentials belong to that specific inbox, email authentication (SPF, DKIM) is handled correctly by the provider's infrastructure.

5. Display in Your UI

Pull messages from IMAP (or receive via webhook) and display them in your product's interface. Your users interact with email inside your app — they never need to open Thunderbird or Outlook, though they could if they wanted to. This flexibility is a significant advantage: users who prefer their own email client can use it, while users who prefer the in-app experience get that too.

// React component for displaying inbox messages
function InboxView({ userId }) {
  const [messages, setMessages] = useState([]);

  useEffect(() => {
    fetch(`/api/users/${userId}/messages`)
      .then((res) => res.json())
      .then(setMessages);
  }, [userId]);

  return (
    <div className="inbox">
      {messages.map((msg) => (
        <div key={msg.id} className="message">
          <div className="from">{msg.from}</div>
          <div className="subject">{msg.subject}</div>
          <div className="date">{msg.date}</div>
        </div>
      ))}
    </div>
  );
}

Cost at Scale

The per-inbox pricing is straightforward and predictable:

Users	One-Time Cost (Managed)	Monthly Cost
10	$30	$0
100	$300	$0
1,000	$3,000	$0

For the whitelabel tier (recommended at scale), it is $30/month flat with unlimited inbox creation. The break-even point between individual managed inboxes and the whitelabel tier is around 10 inboxes — beyond that, the whitelabel tier is more cost-effective.

Comparison with Alternatives

Approach	Cost for 100 Users/Year	Ongoing Ops	Vendor Lock-in
Self-hosted (Postfix/Dovecot)	$200-500/mo server + engineer time	Heavy	None
Google Workspace	$700/mo ($7/user)	Light	Moderate
Microsoft 365	$600/mo ($6/user)	Light	Moderate
Per-seat email APIs	$500-2,000/mo	None	High
Reusable.Email Managed	$300 once	None	Low
Reusable.Email Whitelabel	$30/mo	None	Low

At 1,000 users with a per-seat email API charging $0.50-2.00 per user per month, your cost is $500-2,000/month instead of $30/month on the whitelabel tier. Over a year, that difference is $5,640-23,640 in savings. The standard protocol access (IMAP/SMTP) also means minimal vendor lock-in — you can migrate to any other provider that supports standard protocols without rewriting your integration code.

Considerations

Email Retention

Managed inboxes retain email for 365 days. For products that need longer retention, pull messages into your own database via IMAP and store them in your application's storage layer. This is a common pattern — use the managed inbox as the real-time mailbox and your own database as the long-term archive.

def archive_old_emails(user, db, age_days=30):
    """Archive emails older than age_days from IMAP to local storage."""
    imap = imaplib.IMAP4_SSL("imap.reusable.email", 993)
    imap.login(user.imap_user, user.imap_pass)
    imap.select("INBOX")

    # Search for emails older than threshold
    cutoff = (datetime.now() - timedelta(days=age_days)).strftime("%d-%b-%Y")
    status, messages = imap.search(None, f"BEFORE {cutoff}")

    for msg_id in messages[0].split():
        status, msg_data = imap.fetch(msg_id, "(RFC822)")
        raw = msg_data[0][1]

        # Store in your database
        db.execute(
            "INSERT INTO archived_emails (user_id, raw_email, archived_at) VALUES (?, ?, NOW())",
            (user.id, raw),
        )

        # Optionally delete from IMAP to free space
        imap.store(msg_id, "+FLAGS", "\\Deleted")

    imap.expunge()
    imap.logout()

User Offboarding

When a user leaves your product, their managed inbox still exists until the retention period expires. For proper data handling, delete the messages via IMAP or use the whitelabel API to delete the inbox entirely. This is important for compliance with data protection regulations like GDPR, which require data deletion upon user request.

Custom Domains

The whitelabel tier supports custom domains with auto-configured MX, SPF, DKIM, and DMARC. Your users' inboxes live at [email protected] — no visible connection to Reusable.Email. This is essential for maintaining brand consistency. For DNS setup details, see the custom domain email guide.

Multi-domain support is also available, which is critical for SaaS products serving multiple organizations. Each organization can have inboxes on their own domain: [email protected] and [email protected] coexist under a single whitelabel account.

Deliverability

Because managed inboxes use Reusable.Email's infrastructure, you benefit from their established IP reputation and properly configured authentication (SPF, DKIM, DMARC). This is one of the hardest parts of running your own mail server, and it is handled for you. According to Google's email sender guidelines, proper authentication is mandatory for bulk senders — failing to configure SPF, DKIM, and DMARC can result in emails being silently rejected.

Rate Limits and Sending Policies

Each managed inbox has standard sending limits to prevent abuse. For high-volume sending (newsletters, marketing), you should still use a dedicated sending service like SendGrid or Postmark. Managed inboxes are designed for conversational email — replies, notifications, and per-user communication — not bulk delivery.

Who This Is For

This architecture works for any product where email is a feature, not the product itself:

• Ticketing systems — each queue gets its own address for receiving and routing customer inquiries
• CRM platforms — each sales rep sends and receives from the product, with full conversation tracking
• Project management tools — per-project email addresses for capturing related communications
• Customer service software — agents communicate through the platform with customers
• Marketplace platforms — buyers and sellers communicate without exposing personal addresses
• Recruitment platforms — each job listing gets an inbox for receiving applications
• Legal tech — matter-specific inboxes for organizing client communications

If email is the core of your product — if you are building the next Gmail or a dedicated temp mail service — the white-label email service guide covers the full whitelabel architecture for that use case. For a higher-level view of adding email inboxes to a SaaS product, see How to Add Email Inboxes to Your SaaS Product.

Security Best Practices

When your application manages email credentials on behalf of users, security is paramount:

• Encrypt credentials at rest. Use envelope encryption or a dedicated secrets manager (AWS Secrets Manager, HashiCorp Vault) rather than storing plaintext passwords in your database.
• Minimize credential exposure. Your application should connect to IMAP/SMTP on behalf of users rather than exposing credentials to the frontend. The browser should never see inbox passwords.
• Audit access. Log when credentials are used and by whom. This helps detect unauthorized access and supports compliance requirements.
• Use TLS exclusively. Both IMAP (port 993, SSL/TLS) and SMTP (port 587, STARTTLS) encrypt all communication. Never connect on unencrypted ports.
• Rotate compromised credentials. If a credential leak is detected, change the affected inbox passwords immediately through the API.

Getting Started

For prototyping, create a few managed inboxes through the Reusable.Email web interface ($3 each) and integrate via IMAP/SMTP. This validates the architecture without committing to the whitelabel tier. You can build the full user-facing experience with just a handful of test inboxes.

When you are ready for production, the whitelabel tier gives you the API, webhooks, and admin tools to manage inboxes at scale. The underlying IMAP/SMTP credentials work the same way — your integration code does not change.

For the full developer overview, including testing workflows and webhook integration, see Email API for Developers. For teams focused on automated testing rather than user-facing inboxes, the disposable email API testing guide covers that use case specifically.

FAQ

How long does it take to create an inbox via the API?

Inbox creation via the whitelabel API typically completes in under 2 seconds. The inbox is immediately available for sending and receiving email. There is no provisioning delay — the IMAP and SMTP credentials work as soon as the API response returns.

Can users connect their own email client (Thunderbird, Outlook) to their managed inbox?

Yes. Because managed inboxes use standard IMAP and SMTP, any email client can connect. Provide users with the server settings (imap.reusable.email:993 for IMAP, smtp.reusable.email:587 for SMTP) and their credentials. This is useful for power users who prefer their existing email workflow while still having messages appear in your application.

What happens if the whitelabel API is temporarily unavailable?

Existing inboxes continue to function normally. IMAP and SMTP are separate infrastructure from the management API. Users can still send and receive email even if the API is down. Only inbox creation and management operations require the API. For receiving, IMAP polling and webhooks operate independently.

Can I migrate away from Reusable.Email if needed?

Yes. Because all communication uses standard IMAP and SMTP, migrating to another provider involves creating new inboxes on the new provider and transferring messages via IMAP. Your application code only needs updated server addresses and credentials — the protocol-level code remains identical. This is the core advantage of building on standards rather than proprietary APIs.

How do I handle bounce notifications for sent emails?

When an email sent through a managed inbox bounces, the bounce notification arrives in that same inbox as a delivery status notification (DSN). Your IMAP polling or webhook integration detects the bounce message, and your application can take appropriate action — marking the recipient as invalid, notifying the user, or retrying with a corrected address.