A fake SMTP server that catches every email — so nothing ever hits a real inbox
Maildog gives you a hosted fake SMTP server that accepts mail over real STARTTLS and AUTH connections, then captures it in a web inbox and API instead of delivering it. Point your app at mail.maildog.io:2525, hit send, and inspect exactly what your code produced — headers, HTML, attachments, SPF/DKIM/DMARC, and all.
Testing email from real environments is dangerous
Your staging database is full of real-looking addresses, and one misconfigured loop or forgotten to: field can blast hundreds of real people — racking up bounces that quietly damage your sending domain.
They don't scale to CI/CD
A binary running on localhost:1025 isn't reachable from your hosted pipeline, your preview environments, or your QA team's browsers. Local dummy servers stop the moment a team needs the same view.
They're invisible to teammates
When a tester finds a broken email, they can't share a link — the captured message lives on one developer's machine, so reproducing the issue means screen shares and guesswork.
They skip authentication
Most local dummy servers ignore SMTP AUTH entirely, so you never validate that your credentials, TLS handshake, and secure flags are configured the way production actually expects.
They lose history
Restart the process and every captured email is gone. You can't go back to compare last week's broken template against today's fix, and CI runs leave nothing behind to inspect.
What a fake SMTP server does
A fake SMTP server speaks the real SMTP protocol — it greets your client, accepts MAIL FROM, RCPT TO, and DATA, and returns standard response codes — but stores the message for inspection instead of relaying it. Maildog runs one for you, so there's nothing to install or keep alive.
Indistinguishable on the wire. To your application's email library it behaves exactly like a real SMTP server, negotiating TLS and validating credentials before returning 250 OK.
A live endpoint per inbox. Every sandbox inbox gets host mail.maildog.io on port 2525 (STARTTLS), 587 (submission), or 465 (implicit TLS), with a unique username and password.
Catch-all by design. Send to anyone@anything.com and Maildog accepts it, authenticates the connection, and captures the full message — no allowlists or pre-registered addresses.
Captured in two places at once. Each message surfaces in a real-time web inbox you can share with your team and a REST API your automated tests can poll and assert against.
Key features
Catch-all SMTP capture
The endpoint accepts mail addressed to any recipient and stores it instead of delivering it. No allowlists, no verified-sender setup, no risk of a stray send reaching a real person — whatever your app puts in To, Cc, or Bcc is captured intact.
Real STARTTLS and implicit TLS
This isn't a plaintext toy. Ports 2525 and 587 use STARTTLS (secure: false) and port 465 uses implicit TLS (secure: true), so you test the exact encryption path production uses and catch handshake bugs before they ship.
Per-inbox SMTP authentication
Each sandbox inbox has its own username and password on the Integration tab, and the server validates AUTH on every connection — so you confirm credentials, env vars, and secure flags are wired correctly, something local dummy servers silently skip.
Web inbox + REST API
Every captured email lands in a shareable web inbox and is available over the API. Humans inspect rendered HTML, headers, and attachments in the browser; automated tests fetch the same message via API and assert on its contents.
SPF, DKIM & DMARC inspection
Maildog inspects each captured message's authentication results, so you validate SPF, DKIM, and DMARC alignment in a sandbox before pointing the same app at a production sender.
Full message inspection
Drill into raw source, parsed headers, HTML and plain-text bodies, embedded images, and attachments — the visibility a real SMTP server's bare 250 OK will never give you.
Connecting to the fake SMTP server
Connecting is identical to any production SMTP server — you just use the Maildog host, port, and your per-inbox credentials. The message is captured, not delivered.
import smtplib
from email.message import EmailMessage
# Credentials come from your sandbox inbox's Integration tab.
SMTP_HOST = "mail.maildog.io"
SMTP_PORT = 2525 # STARTTLS, secure: false
SMTP_USER = "your_username"
SMTP_PASS = "your_password"
msg = EmailMessage()
msg["From"] = "app@example.com"
msg["To"] = "any-recipient@anything.com" # catch-all: never actually delivered
msg["Subject"] = "Password reset"
msg.set_content("Click here to reset your password: https://example.com/reset/abc123")
with smtplib.SMTP(SMTP_HOST, SMTP_PORT) as server:
server.starttls() # upgrade the plaintext connection to TLS
server.login(SMTP_USER, SMTP_PASS)
server.send_message(msg)
# Server returns 250 OK — but the message is CAPTURED in your Maildog
# web inbox and API, not delivered to any-recipient@anything.com.
print("Email captured by the fake SMTP server. Open your Maildog inbox to inspect it.")curl --url 'smtp://mail.maildog.io:2525' \
--ssl-reqd \
--user 'your_username:your_password' \
--mail-from 'app@example.com' \
--mail-rcpt 'any-recipient@anything.com' \
--upload-file message.eml
# --ssl-reqd forces STARTTLS. The message is captured, never delivered.Why developers choose Maildog
Faster email debugging
Stop guessing what your code emitted. Every send is captured with raw source, parsed headers, and rendered HTML, so you find the broken merge tag or missing attachment in seconds instead of pestering a teammate to check their inbox.
Safe email testing
Because the fake SMTP server captures instead of delivers, you can run your full email suite — signups, receipts, password resets, digest jobs — against realistic data with zero chance of spamming real people or leaking customer data.
Better deliverability
Keeping test traffic off your production sender means no test-driven bounces or spam complaints dragging down your domain reputation. Validate SPF, DKIM, and DMARC in the sandbox first, then ship a clean sender to production.
Improved team workflow
One hosted endpoint replaces a dummy binary on every laptop and CI runner. Developers, QA, and CI all point at the same mail.maildog.io host, and anyone can open or share a captured message by link.
Local dummy SMTP vs hosted fake SMTP
A local dummy server is great for a quick check on one laptop. A hosted fake SMTP server is what you want the moment CI, QA, and teammates need the same view.
| Capability | Self-hosted dummy / Mailhog | Maildog hosted |
|---|---|---|
| Setup | Install a binary per machine | Nothing to install |
| Reachable from CI / cloud | ||
| TLS support | Often plaintext only | STARTTLS + implicit TLS |
| SMTP AUTH validation | ||
| Catch-all recipients | ||
| Web inbox | Local-only | Shareable, team-wide |
| REST API for tests | Limited / varies | |
| SPF / DKIM / DMARC inspection | ||
| History persists on restart | ||
| Team sharing |
Frequently asked questions
What is a fake SMTP server?
A fake SMTP server is a mail server that accepts email over the standard SMTP protocol exactly like a real one — handling the connection, TLS, authentication, and DATA commands — but captures each message for inspection instead of delivering it. It's used to test and debug application email safely, because nothing it accepts ever reaches a real recipient's inbox.
How is a fake SMTP server different from a real SMTP server?
On the wire they're identical: both return standard SMTP response codes like 250 OK. The difference is the final step. A real SMTP server relays the message toward its destination; a fake SMTP server stores it so you can inspect it. Your email library can't tell the difference, which is exactly why fake SMTP servers are reliable for testing.
Is a fake SMTP server safe to use with real email addresses?
Yes — that's the point. Because the server captures instead of delivers, you can send to real-looking addresses in your test data without anyone receiving the mail. Maildog's fake SMTP server is catch-all, so any-recipient@anything.com is accepted and stored, never relayed.
How do I connect to Maildog's fake SMTP server?
Point your SMTP client at host mail.maildog.io on port 2525 (STARTTLS, secure: false) or 587, or port 465 for implicit TLS (secure: true). Use the unique username and password shown on your sandbox inbox's Integration tab. See the SMTP setup guide for framework-specific examples.
Does the fake SMTP server require authentication?
Yes. Each sandbox inbox has its own username and password, and the server validates AUTH on every connection. This is a feature, not a chore — it lets you confirm your credentials and secure flags are configured the way production expects, which local dummy servers usually skip.
Can I use a fake SMTP server in CI/CD pipelines?
Absolutely. Because Maildog's fake SMTP server is hosted at mail.maildog.io rather than localhost, it's reachable from any CI runner, preview environment, or QA machine. Send during a test, then use the API to fetch and assert on the captured message.
What's the difference between a fake SMTP server and an email sandbox?
A fake SMTP server is the capture endpoint — the protocol-level piece that accepts and stores mail. An email sandbox is the broader environment around it: the web inbox, API, message inspection, and authentication checks. Maildog provides both together, so the fake SMTP server feeds directly into a full email sandbox.
Can I inspect headers, HTML, and SPF/DKIM/DMARC on captured email?
Yes. Every captured message exposes raw source, parsed headers, rendered HTML and plain-text bodies, attachments, and SPF/DKIM/DMARC authentication results — in the web inbox for humans and over the API for automated tests.
Keep exploring
Start capturing email the safe way
Spin up a hosted fake SMTP server and capture your first message in seconds — nothing ever reaches a real inbox.
Start capturing email free