The Anatomy of an Email: What Actually Happens When You Hit Send
You hit send. A fraction of a second later, your message appears in someone's inbox across the world. But between those two moments lies one of the most fascinating relay races in all of computing.
EvilMail TeamApril 6, 202620 min read
# The Anatomy of an Email: What Actually Happens When You Hit Send
You hit send. Then what?
The answer involves more hops than a rabbit on espresso.
Seriously — that little email you just fired off to your coworker ("hey, did you push that commit?") is about to embark on one of the most intricate journeys in modern computing. It will be sliced apart, inspected by algorithms with trust issues, cryptographically verified, bounced between servers that have never met each other, reassembled, and — if it survives the gauntlet — deposited neatly into an inbox where it will sit unread for three days.
I've spent years working on email infrastructure. Building mail servers. Debugging delivery failures at 2 AM. Staring at SMTP logs until the text started swimming. And the thing that never stops amazing me is this: email is a 50-year-old technology that still powers the internet, and almost nobody understands how it actually works.
This is not a tutorial. This is not a product pitch. This is a love letter to one of the most underappreciated systems ever built — written by someone who has seen its guts and finds them beautiful.
Let's open the hood.
• • •
The SMTP Handshake: A Polite Conversation Between Strangers
SMTP — Simple Mail Transfer Protocol — is the backbone of email delivery. It was formalized in RFC 821 back in 1982, which means it predates the World Wide Web by nearly a decade. And here's the wild part: the modern version isn't fundamentally different from the original. We've bolted on encryption, authentication, and various extensions, but the core conversation is still recognizably the same.
Let me show you what actually happens when your mail client talks to an SMTP server. Imagine two servers meeting at a party:
Client: EHLO mail.example.com
Server: 250-mail.recipient.com Hello mail.example.com
250-STARTTLS
250-AUTH PLAIN LOGIN
250 OK
Client: STARTTLS
Server: 220 Ready to start TLS
[...TLS handshake happens here...]
Client: MAIL FROM:<[email protected]>
Server: 250 OK
Client: RCPT TO:<[email protected]>
Server: 250 OK
Client: DATA
Server: 354 Start mail input; end with <CRLF>.<CRLF>
Client: Subject: Hey, did you push that commit?
From: [email protected]
To: [email protected]
Seriously, the build is broken.
.
Server: 250 OK: queued as ABC123
Client: QUIT
Server: 221 Bye
That's it. That's the whole conversation. Two machines, being excruciatingly polite to each other, exchanging a message through what is essentially a structured text chat.
A few things to notice here. First, EHLO — that's "Extended HELO," which replaced the original HELO command. It's how the sending server introduces itself and asks what extensions the receiving server supports. Think of it as the handshake before the handshake. "Hi, I'm mail.example.com, and I'd like to know what tricks you can do."
Second, STARTTLS. This is the moment where both servers agree to upgrade from plaintext to an encrypted connection. Before this command, everything was being sent in the clear. After it, TLS wraps the entire conversation. It's opportunistic encryption — if the receiving server doesn't support it, many sending servers will shrug and continue in plaintext. This is one of email's fundamental tensions: backward compatibility versus security.
Third — and this is the part that trips up most people — the MAIL FROM and RCPT TO addresses in the SMTP envelope are completely independent from the From: and To: headers inside the message body. The envelope is what the servers use for routing. The headers are what your email client displays. They can be entirely different. This isn't a bug. It's a feature that enables mailing lists, BCC, and forwarding. It's also, unfortunately, a feature that enables spoofing — but we'll get to that.
The whole exchange takes milliseconds on a good day. On a bad day — when servers are overloaded, DNS is being flaky, or greylisting is in play — it can take minutes or even hours. Your email sits in a queue, the sending server periodically retrying like a persistent door-to-door salesman who just knows you're home.
The response codes tell the story. Anything starting with 2 means success. 3 means "keep going, I need more." 4 means "temporary failure, try again later" (this is where greylisting lives — more on that soon). 5 means "permanent failure, don't bother trying again." The dreaded 550 — "User not found" or "Relay denied" — has ruined more developers' afternoons than any segfault ever could.
• • •
DNS Lookups: The Postal System of the Internet (But Actually Good This Time)
Every analogy comparing DNS to a phone book should be taken out back and put out of its misery. Here's a better one.
Imagine you want to send a physical letter to "Engineering Department, Acme Corp." You don't know the street address. You don't even know what city they're in. So you go to a directory service and ask: "Hey, where does Acme Corp receive their mail?"
The directory doesn't give you a street address directly. Instead, it gives you a list of mail rooms, ranked by preference:
That's what MX records are. "Mail eXchanger" records. When your mail server wants to deliver a message to [email protected], it doesn't just guess where to connect. It asks the DNS system: "Who handles mail for acme.com?" And DNS responds with an ordered list of servers, each with a priority number. Lower numbers mean higher priority.
So your server tries mail1.acme.com first (priority 10). If that's down, it moves to mail2.acme.com (priority 20). If that's also down, it falls back to backup.mailprovider.com (priority 30). This is elegant, resilient, and — when it works — completely invisible.
But the lookup chain doesn't stop at MX records. Once your server knows the hostname of the mail server, it needs to resolve that hostname to an actual IP address. That's an A record (or AAAA for IPv6). And before it even gets to the MX lookup, it might need to traverse the DNS hierarchy — root servers, TLD servers, authoritative nameservers — a cascading series of queries that usually completes in under 100 milliseconds thanks to aggressive caching.
Here's where it gets interesting for developers. If your domain doesn't have MX records, SMTP falls back to the A record of the domain itself. So if acme.com has no MX records but has an A record pointing to 203.0.113.5, the sending server will try to deliver mail directly to that IP on port 25. This fallback exists for historical reasons, and it's one of those things that mostly works until it spectacularly doesn't.
There's also the reverse DNS lookup — PTR records. Many receiving servers will check whether the IP address of the connecting server has a valid PTR record that matches the server's hostname. If your mail server at 203.0.113.5 claims to be mail.acme.com, but the PTR record for that IP points to random-vps-12345.cloudprovider.com, the receiving server gets suspicious. Rightfully so. Legitimate mail servers have matching forward and reverse DNS. Spammers operating from throwaway VPS instances usually don't.
This is one of those things that works silently in the background, holding the entire system together with the quiet competence of a structural engineer. Nobody thinks about DNS until it breaks. And when it breaks, email breaks. Every time there's a major DNS outage, half of Twitter rediscovers that email depends on it.
• • •
SPF, DKIM, and DMARC: The Bouncer Trio at the Email Club
Imagine a nightclub. Not a trendy one — a slightly seedy one that's been around since 1982 and has a very lenient door policy. For decades, anyone could walk in claiming to be anyone. "I'm definitely Brad Pitt," says a guy in sweatpants. "Sure, come on in," says the bouncer.
That was email until the early 2000s. No authentication. No verification. Anyone could send an email claiming to be from [email protected], and receiving servers would just... accept it. The From: header is just text. There's nothing in the original SMTP spec that prevents you from putting whatever you want there.
This was, predictably, a disaster. Phishing exploded. Spam became an existential threat to email's usefulness. Something had to be done. So the industry built three bouncers.
SPF: The Guest List
SPF — Sender Policy Framework — is the simplest of the three. It's a DNS TXT record that says: "Here are the IP addresses authorized to send email on behalf of my domain."
Translation: "Mail from acme.com should only come from the 203.0.113.0/24 network or from Google's mail servers. If it comes from anywhere else, reject it."
The receiving server checks: "This email claims to be from acme.com. Did it come from one of the authorized IPs?" If yes, SPF passes. If no, SPF fails. Simple. Beautiful. And limited.
SPF's biggest weakness is that it checks the envelope sender (the MAIL FROM in the SMTP conversation), not the From: header that users actually see. An attacker can use their own domain in the envelope while spoofing the visible From: header, and SPF won't catch it. SPF also breaks when email is forwarded — the forwarding server's IP won't be in the original domain's SPF record.
Still, SPF is the foundation. It's the guest list pinned to the bouncer's clipboard.
DKIM: The Wax Seal
DKIM — DomainKeys Identified Mail — takes a fundamentally different approach. Instead of checking where the email came from, it checks whether the email was tampered with in transit.
When a DKIM-enabled server sends an email, it takes certain headers and the body of the message, computes a cryptographic hash, and signs that hash with a private key. The signature is added as a DKIM-Signature header:
The receiving server sees this signature, looks up the public key in DNS (stored as a TXT record at selector1._domainkey.acme.com), and verifies the signature. If it matches, two things are proven: the email really was authorized by acme.com (because only they have the private key), and the signed parts weren't modified in transit.
DKIM is the wax seal on a medieval letter. It doesn't prevent someone from writing a fake letter, but it lets you verify that a letter bearing the king's seal actually came from the king.
The selector mechanism is clever — it allows domains to rotate keys without breaking everything. You can publish a new key pair under selector2._domainkey.acme.com while the old one is still active under selector1. Graceful key rotation. The kind of engineering decision that makes me want to buy the RFC authors a beer.
DMARC: The Policy Enforcer
SPF and DKIM are detection mechanisms. They tell you whether something looks legitimate. But they don't tell you what to do about it. That's DMARC's job.
DMARC — Domain-based Message Authentication, Reporting, and Conformance — ties SPF and DKIM together with a policy. It's published as a DNS TXT record:
This says: "If an email claims to be from acme.com but fails both SPF and DKIM alignment, reject it. And send me aggregate reports about what you're seeing."
The key word here is "alignment." DMARC doesn't just check whether SPF or DKIM passed — it checks whether the domain that passed SPF or DKIM matches the domain in the visible From: header. This closes the gap that SPF left open. Even if an attacker passes SPF for their own domain, DMARC will catch the mismatch with the spoofed From: header.
The three policies are:
p=none — Monitor mode. Don't do anything, just send reports. Good for starting out.
p=quarantine — Put suspicious messages in spam.
p=reject — Drop them entirely.
Most domains should be working toward p=reject, but getting there requires careful preparation. You need to make sure all your legitimate email sources are properly authenticated first. Nothing quite like accidentally telling the world to reject your own company's invoices.
Together, these three protocols form the authentication backbone of modern email. They're not perfect — nothing built on top of a 1982 protocol ever will be — but they've dramatically reduced the effectiveness of domain spoofing. If you run a domain and haven't set up all three, you're essentially running that nightclub with no bouncer. In 2026. With a phishing epidemic raging outside.
• • •
The Spam Filter Gauntlet: Where Good Emails Go to Die
Your email has authenticated. SPF passed. DKIM verified. DMARC aligned. You might think you're home free.
You are not even close.
The spam filter gauntlet is where the real fun begins, and by "fun" I mean "the reason email deliverability engineers exist as a profession."
Modern spam filtering is a multi-layered beast. Let's walk through the layers.
Reputation Scoring. Before the spam filter even looks at your message content, it checks your reputation. Your sending IP has a reputation score maintained by various blocklists and reputation services (Spamhaus, Barracuda, Sender Score, etc.). Your domain has a reputation. Even your specific email address might have one. If you're sending from a fresh IP with no history, many filters will treat you with suspicion — you haven't earned trust yet. This is called the "IP warming" problem, and it's why companies like EvilMail invest heavily in maintaining clean, well-reputed infrastructure.
Sending 100,000 emails from a brand-new IP on day one? That's not marketing. That's a red flag with a siren attached.
Content Analysis. This is where Bayesian filtering enters the picture. Named after Thomas Bayes (18th-century statistician, involuntary godfather of spam detection), Bayesian filters calculate the probability that a message is spam based on the words it contains. The filter has been trained on millions of messages, and it knows that emails containing "FREE VIAGRA" and "NIGERIAN PRINCE" have a slightly higher spam probability than your average project update.
But modern content analysis goes way beyond naive word counting. Filters examine HTML structure, image-to-text ratio, URL destinations, attachment types, header anomalies, and dozens of other signals. They use machine learning models that would make the original Bayesian approach look like a pocket calculator. Google's spam filters, for instance, process signals from billions of messages to build models that can catch brand-new spam campaigns within minutes of their launch.
URL and Link Analysis. Every URL in your email gets checked against blocklists of known malicious domains. The filter might even follow shortened URLs to see where they actually lead. If you're linking to a domain that's been flagged for phishing, your email is going to spam. Full stop.
Engagement Signals. This one surprises most people. Major mailbox providers like Gmail and Outlook track how recipients interact with your emails. Do they open them? Click links? Reply? Or do they immediately delete them? Mark them as spam? If a significant percentage of your recipients are ignoring or spam-reporting your emails, your sender reputation tanks, and future emails are more likely to be filtered.
This creates a fascinating feedback loop: the better your emails are (relevant, wanted, well-crafted), the better your deliverability becomes. The worse they are, the more they get filtered, which further damages your reputation, which filters even more... it's a death spiral for bad senders and a virtuous cycle for good ones.
Greylisting. This is the clever-but-annoying technique where a receiving server temporarily rejects your email with a 4xx code ("try again later"). Legitimate mail servers will dutifully retry after a delay. Spam bots, which are usually fire-and-forget operations, typically don't bother retrying. So greylisting acts as a natural filter — at the cost of delaying legitimate email delivery by several minutes.
The first time I encountered greylisting, I spent two hours debugging what I thought was a server configuration problem before realizing the receiving server was just... testing my patience. It felt personal.
The Politics of Deliverability. Here's the uncomfortable truth about email deliverability: it's not entirely meritocratic. The big mailbox providers — Google, Microsoft, Yahoo — have enormous power over whose emails reach the inbox. Their filtering decisions are opaque. Their feedback mechanisms are limited. And if you get on their bad side, digging yourself out can take weeks or months.
Small email operators face a particular challenge. Google has been tightening requirements steadily — mandatory SPF, DKIM, and DMARC, one-click unsubscribe headers for bulk senders, engagement-based filtering. These are good things for email as a whole, but they also raise the barrier to entry and consolidate power with the biggest players. It's a tension without an easy resolution.
• • •
IMAP vs POP3: The Eternal Debate, Actually Settled
Let me settle this right now.
Use IMAP.
Okay, fine, I'll elaborate.
POP3 (Post Office Protocol version 3) was designed in 1984 for a world where you had one computer and you wanted to download your email to it. POP3 connects to the server, downloads messages, and — in its default configuration — deletes them from the server. Your email lives on your device. The server is just a temporary holding area.
This made perfect sense in 1984. You had one computer. It was probably a beige box the size of a small refrigerator. All your files lived on it.
This makes almost zero sense in 2026. You have a phone, a laptop, a tablet, possibly a desktop, and a smart fridge that probably has an email client for some reason. With POP3, if you download and read a message on your phone, your laptop has no idea that happened. You'd see the same message as unread. Delete it on your laptop? Still there on your phone. It's chaos.
IMAP (Internet Message Access Protocol) was designed for a multi-device world. Instead of downloading messages and removing them from the server, IMAP synchronizes state between the server and your clients. Read a message on your phone? It's marked as read everywhere. Move it to a folder? That folder exists on the server, visible from all your devices. Delete it? Gone everywhere.
IMAP keeps the server as the source of truth. Your email clients are just windows into that truth. This is fundamentally the right architecture for how we use email today.
The only scenario where POP3 still makes sense is if you genuinely want to download all your email to a local machine and remove it from the server — for archival purposes, or because you're storing sensitive mail and don't trust the server. Some privacy-conscious folks prefer this approach. It's valid but niche.
For literally everyone else: IMAP. This is not a debate. This is a public service announcement.
A few IMAP details that developers should know: IMAP supports server-side search (the SEARCH command), which means your client can search through thousands of messages without downloading all of them. It supports IDLE, which is essentially a push notification mechanism — the server tells the client when new mail arrives, instead of the client polling repeatedly. And modern IMAP implementations support compression, threading, and partial message fetching (so you can download just the first 10KB of a 50MB message to see what it's about before deciding whether to download the rest).
One caveat: IMAP is more demanding on server resources than POP3, because the server has to maintain state and handle concurrent connections from multiple clients. For a mail hosting provider, this means more RAM, more CPU, more careful server tuning. It's worth it. But it's not free.
• • •
Why Email Is Both Ancient and Unkillable
Slack was going to kill email. Then Teams. Then Discord. Then whatever app launched last Tuesday with a $50M Series A and a manifesto about "reimagining workplace communication."
Email is still here. It will outlive all of them.
Why? Because email is an open protocol. Nobody owns it. Nobody can shut it down. Nobody can change the API and break everyone's integrations. Nobody can raise the price by 300% because the board needs to hit revenue targets.
SMTP is a specification, not a product. Anyone can build an email server. Anyone can build an email client. Any two implementations, built by completely unrelated teams on opposite sides of the planet, can communicate with each other because they both follow the same public specification. This is the power of open standards, and it's the reason email has survived every attempt to replace it.
Think about what email gives you:
Universal addressing. Everyone has an email address. Your grandmother has one. Your bank has one. The Nigerian prince has one (several, actually).
Federated architecture. No single point of failure. No single company in control. Gmail could vanish tomorrow and email would keep working.
Interoperability. Send from Outlook to Gmail to ProtonMail to a self-hosted Postfix server. They all just work together.
Persistence. Email is asynchronous by nature. It doesn't demand immediate attention. It waits.
Receipts and paper trails. Email is the de facto legal record of digital communication.
Chat apps give you real-time convenience. Email gives you resilient, interoperable, asynchronous communication that works across every organizational boundary. These are different tools for different jobs, and email's job — official, cross-boundary, persistent communication — isn't going away.
The irony is that most "email killer" apps eventually add email integration. You get Slack notifications via email. You sign up for Discord with an email. Every SaaS product uses email for authentication, billing, and notifications. Email isn't just surviving — it's the identity layer of the internet.
I'll admit, the protocol is showing its age in some areas. SMTP's lack of built-in encryption was a design limitation of its era. The bolt-on authentication mechanisms (SPF, DKIM, DMARC) are necessary band-aids on a protocol that was designed for a trusting network. Header injection attacks exploit the fact that email headers are just freeform text with minimal validation.
But here's the thing about battle-tested infrastructure: its flaws are well-known and well-mitigated. I'd rather build on a protocol with 40+ years of real-world hardening than one that's been production-tested for 18 months.
• • •
The Rise of Disposable Email: Privacy as a Feature, Not a Hack
Somewhere along the way, the internet decided that your email address was your universal identifier. Sign up for anything — a social network, a food delivery app, a newsletter about artisanal cheese — and you hand over your email address. Which then gets sold to data brokers, leaked in breaches, and buried under an avalanche of marketing emails you never asked for.
Disposable email addresses are the natural immune response to this reality.
The concept is simple: instead of giving every website your real email address, you use a temporary one. Read the confirmation email, get what you need, and the address disappears. No spam follow-up. No data broker trails. No breach exposure.
But disposable email has evolved beyond "burner address for sketchy signups." It's becoming a legitimate privacy tool. Services like EvilMail provide disposable addresses that are actually functional — you can receive mail, read it through a clean interface, and let it expire when you're done. It's not about being shady. It's about controlling your digital footprint.
Developers, in particular, find disposable email indispensable (pun intended, no regrets). Testing email flows in development and staging environments requires dozens of unique addresses. Running integration tests against email verification systems means generating and reading hundreds of test emails. You can't use your personal Gmail for that. And setting up a full mail server just for testing is like buying a restaurant because you want a sandwich.
The privacy angle is becoming more important every year. GDPR, CCPA, and similar regulations have made people more aware of how their data is used. Email addresses are personally identifiable information, and every time you hand one out, you're trusting the recipient to handle it responsibly. Given how often that trust is violated (there's a new data breach headline practically every week), using disposable addresses for non-essential signups is just good digital hygiene.
Some services try to block disposable email addresses. This is a losing battle, and I'd argue a misguided one. If your product is so reliant on capturing permanent email addresses that you can't tolerate disposable ones, the problem isn't with disposable email — it's with your engagement strategy.
• • •
What Developers Get Wrong About Email (I've Made All of These Mistakes)
After spending years building and maintaining email systems, I've developed a collection of scars — each one a lesson learned the hard way. Here are the mistakes I see developers make over and over.
Mistake #1: Sending email synchronously in request handlers
User clicks "Register." Your API handler creates the account, sends a welcome email, waits for the SMTP server to respond, and then returns a 200 to the user. If the SMTP server is slow or down, your user stares at a loading spinner for 30 seconds before getting a timeout error.
Email sending should always be asynchronous. Push it to a queue (Redis, RabbitMQ, SQS, whatever you've got) and return immediately. Process the queue in the background. If sending fails, retry with exponential backoff. The user doesn't need to wait for the email to be delivered before they can continue.
Mistake #2: Building your own email templates with string concatenation
I've seen this in production:
javascript
const html = '<h1>Welcome, ' + user.name + '!</h1>';
Besides being an injection vulnerability, this approach becomes unmaintainable the moment your templates have any complexity. Use a proper templating system. Use database-backed templates with variable substitution. Use anything that separates your content from your code and lets non-developers edit templates without deploying code changes.
Mistake #3: Ignoring bounce handling
When you send to an invalid address, the receiving server sends back a bounce notification (a Non-Delivery Report, or NDR). If you ignore these, you keep sending to invalid addresses, your bounce rate climbs, and mailbox providers start treating you as a spammer.
You need to process bounces. Hard bounces (permanent failures — address doesn't exist) should immediately remove the address from your sending list. Soft bounces (temporary failures — mailbox full, server down) should trigger a retry with eventual removal if the problem persists.
Mistake #4: Using a shared hosting SMTP server for production email
Shared SMTP servers are like shared kitchens in college dorms. You might keep your area clean, but the person next to you is sending 10,000 spam messages, and now the entire IP is blocklisted. Your perfectly legitimate emails go to spam because of your neighbor's behavior.
Use a dedicated sending infrastructure. Whether that's a transactional email service, a dedicated SMTP server with its own IP, or a well-managed shared service with strict sending policies — make sure your email reputation isn't at the mercy of random strangers.
Mistake #5: Not testing email rendering across clients
Email HTML rendering is where web standards go to die. Gmail strips <style> tags from the <head> (but supports them in <body> now — sometimes). Outlook uses Microsoft Word as its HTML rendering engine. Yes, you read that correctly. Microsoft Word. In 2026. The same Word that can't reliably render a two-column layout in a document is responsible for rendering your marketing emails in one of the world's most popular email clients.
Inline your CSS. Test across clients. Use tables for layout (I know, I know). Or use a battle-tested email framework like MJML or Maizzle. Your sanity will thank you.
Mistake #6: Hardcoding SMTP credentials
I shouldn't have to say this in 2026, but:
javascript
// Please don't do this
const transport = nodemailer.createTransport({
host: 'smtp.example.com',
auth: { user: 'admin', pass: 'hunter2' }
});
Environment variables. Secret managers. Vault. Anything but committed credentials. I've seen API keys for email services in public GitHub repos. The scanners find them within minutes. Your account gets compromised, your sending infrastructure gets used for spam, and your domain reputation takes months to recover.
Mistake #7: Not setting up authentication records
I can't tell you how many times I've seen a developer spin up a new service, configure SMTP sending, and then wonder why all their emails land in spam. No SPF record. No DKIM signing. No DMARC policy. They skipped the bouncer trio entirely and are surprised when legitimate recipients treat their mail as suspicious.
Set up SPF, DKIM, and DMARC before you send your first email from a new domain. Not after. Before. It takes 20 minutes and saves weeks of deliverability headaches.
Mistake #8: Treating email addresses as simple strings
Email address validation is a rabbit hole that descends into madness. The RFC 5321 specification allows local parts to contain quoted strings, which means "john doe"@example.com is technically valid. So is [email protected], which Gmail uses for sub-addressing. So is postmaster@[192.168.1.1], which uses an IP literal instead of a domain.
Most regex patterns you find on Stack Overflow reject valid addresses and accept invalid ones. The only reliable way to validate an email address is to send a message to it and see if it bounces. For input validation, keep it simple: check for an @ sign, a dot in the domain part, and a reasonable length. Let the SMTP server do the real validation.
• • •
Closing Thoughts: The Unsexy Miracle
Email doesn't get keynote presentations at tech conferences. Nobody writes breathless blog posts about the latest email features (well, almost nobody). It doesn't have a slick marketing team or a mascot or a developer evangelist doing conference talks with 200 slides and a demo that inevitably crashes.
Email just works. It has worked for decades. It will work for decades more.
The system you use to send a quick note to your colleague is the same system that delivers bank statements, legal notices, medical records, and diplomatic communications. It's the backbone of internet identity, the primary recovery mechanism for every account you own, and the one communication channel that bridges every platform, every device, and every organization on Earth.
And it's all built on a protocol that's basically two computers being polite to each other.
The next time you hit send, take a moment to appreciate the journey your message is about to take. The DNS lookups. The SMTP handshake. The cryptographic verification. The spam filter gauntlet. The final delivery to an inbox that might be on a phone in someone's pocket on the other side of the world.
All of that, in under a second.
That's not just engineering. That's a miracle wearing a boring hat.
• • •
*Building something that sends email? EvilMail provides developer-friendly email infrastructure with disposable addresses, clean APIs, and the authentication records already configured. Because life's too short to debug deliverability issues at 2 AM.*
