Why Receiving Email is Hard
Sending email is straightforward. Receiving it reliably is a different story.
Most developers have sent emails programmatically — it's a well-documented problem with plenty of APIs. But when you need your application to receive inbound email, you quickly discover it's a different challenge entirely.
Here's why developers typically spend 4-6 weeks building email receiving infrastructure — and why most regret it.
1. You need real email infrastructure
To receive email, you need an SMTP server listening on port 25. This means:
- MX records: Configure DNS to point mail to your server
- TLS certificates: STARTTLS for encryption in transit
- High availability: Email servers must be up 24/7 or mail bounces
- IP reputation: Your IP needs a clean history for deliverability
Note: Many cloud providers block port 25 by default. AWS, GCP, and Azure all require special requests to unblock it for new accounts.
2. MIME is more complex than it looks
Email messages use MIME (Multipurpose Internet Mail Extensions), a format designed in 1992. It's surprisingly complex:
Content-Type: multipart/mixed;
boundary="----=_Part_12345"
------=_Part_12345
Content-Type: multipart/alternative;
boundary="----=_Part_67890"
------=_Part_67890
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hello, this is the plain text version.
------=_Part_67890
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: base64
PGh0bWw+PGJvZHk+SGVsbG8sIHRoaXMgaXMgSFRNTC48L2JvZHk+PC9odG1sPg==
------=_Part_67890--
------=_Part_12345
Content-Type: application/pdf; name="document.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="document.pdf"
JVBERi0xLjQKJeLjz9MKMyAwIG9iago8PC9UeXBlL1BhZ2UvUGFyZW50...
------=_Part_12345--This is a simple email with plain text, HTML, and one attachment. Real-world emails get far more complex with nested forwarded messages, inline images, and inconsistent encoding.
- •Nested multipart structures (alternative, mixed, related)
- •Multiple encodings: base64, quoted-printable, 7bit, 8bit
- •Character set variations: UTF-8, ISO-8859-1, Windows-1252
- •Malformed headers from different email clients
3. Attachments are unpredictable
Handling email attachments reliably requires dealing with:
Encoding variations
Base64, quoted-printable, uuencode, or raw binary depending on the client
Inline vs attached
Images can be inline (CID references) or traditional attachments
Filename encoding
RFC 2231 encoding for non-ASCII filenames, often implemented incorrectly
Size limits
Large attachments can exceed memory limits during processing
You'll spend weeks handling edge cases: what happens when Gmail sends an attachment one way, Outlook another, and Apple Mail a third?
4. Spam and security are your problem
The moment you accept email from the internet, you inherit email security problems:
- Spam filtering: Most inbound email is spam. You need filters or your application drowns.
- SPF/DKIM/DMARC: Verify sender authenticity to prevent spoofing.
- Malicious attachments: Scan for viruses and malware before processing.
- Rate limiting: Prevent DoS attacks via email flooding.
5. Email expects 100% uptime
Unlike HTTP requests that retry quickly, email has specific delivery expectations:
- •Sending servers retry for up to 5 days (RFC 5321)
- •If your server is down, mail queues elsewhere
- •Extended downtime means permanent bounces
- •You need redundancy, failover, and monitoring
Your application's SLA now includes email infrastructure. A database migration that takes your app down for 10 minutes? That's 10 minutes of queued or bounced emails.
6. Every email client is different
Email from Gmail looks different than email from Outlook, which looks different than email from Apple Mail, which looks different from a 20-year-old enterprise server.
You'll encounter edge cases constantly:
- •Headers with inconsistent casing or formatting
- •Non-standard date formats that break parsers
- •Reply chains with quoted content in different formats
- •Character encoding declared incorrectly
The alternative
Instead of building and maintaining email infrastructure, use a service that handles it for you. With Mailhooks, you receive inbound email as simple webhooks:
- ✓No SMTP server to run or maintain
- ✓MIME parsing handled for you — receive clean JSON
- ✓Attachments as downloadable URLs
- ✓Built-in spam filtering
- ✓99.9% uptime SLA