AWS SES: Simple Email Service Setup and Best Practices

SMTP and email delivery have gotten complicated with all the authentication protocols and deliverability rules flying around. As someone who’s configured more email servers than I’d like to admit, I learned everything there is to know about getting emails from point A to point B reliably. Today, I will share it all with you.

Let me tell you something — email looks simple on the surface. You type a message, hit send, it shows up in someone’s inbox. But under the hood? It’s one of the most intricate systems in all of computing. I spent a full weekend once debugging why our transactional emails were landing in spam folders, and that experience taught me more about SMTP than any textbook ever could.

What is an SMTP Server?

An SMTP server is basically the post office of the internet. SMTP stands for Simple Mail Transfer Protocol, and the server’s job is to take your outgoing email, figure out where it needs to go, and get it there. When you hit “send” in Gmail or Outlook, your email client hands that message off to an SMTP server, which then relays it to the recipient’s mail server.

If the receiving server isn’t available — maybe it’s down for maintenance or overloaded — the SMTP server doesn’t just give up. It holds onto your email and keeps retrying. Most servers will attempt delivery for several days before finally bouncing the message back to you. I’ve seen emails get delivered 72 hours after they were sent because the receiving server had an extended outage. The system is more resilient than people give it credit for.

How Does the SMTP Protocol Actually Work?

Probably should have led with this section, honestly. The SMTP protocol is surprisingly straightforward once you break it down. It’s text-based, meaning the commands are human-readable. Here’s what happens when you send an email:

1. Your email client opens a connection to the SMTP server on port 25, 465, or 587.
2. The client introduces itself with a HELO (or EHLO for extended SMTP) command.
3. The server responds — basically saying “hey, I’m listening.”
4. Your client sends MAIL FROM with the sender’s address.
5. The server checks and acknowledges it.
6. The client sends RCPT TO with the recipient’s address.
7. Server verifies the recipient (or at least accepts the address).
8. The client sends DATA, followed by the actual email content.
9. Server stores the email and starts routing it to the recipient’s server.

I’ve actually telnet-ed into SMTP servers and typed these commands by hand to debug delivery issues. It’s a great way to understand what’s happening under the hood, and I’d recommend every developer try it at least once.

Why SMTP Still Matters

You might think with all the modern messaging platforms out there, SMTP would be fading away. Nope. It’s still the backbone of email communication worldwide. Every single email you’ve ever sent went through SMTP at some point. The protocol also supports authentication methods that keep unauthorized senders from hijacking your mail server — which, trust me, is something spammers are constantly trying to do.

SMTP Server Configuration

Configuring an SMTP server isn’t rocket science, but getting it right matters. Here are the settings you’ll need to nail down:

• Server Address: The hostname or IP of your SMTP server. For Amazon SES, it’s something like email-smtp.us-east-1.amazonaws.com.
• Port Number: Port 25 is the traditional SMTP port, 465 is for SMTPS (SMTP over SSL), and 587 is the modern standard for submission with STARTTLS.
• Authentication: Methods include PLAIN, LOGIN, or CRAM-MD5. Most modern services use PLAIN over TLS.
• Encryption: Always use TLS. Sending email in plaintext in 2025 is just asking for trouble.

I always tell people to use port 587 with STARTTLS. It’s the most widely supported and gives you the best balance of compatibility and security. Port 25 is increasingly blocked by ISPs to combat spam.

SMTP and Email Security

Security is where a lot of people get tripped up. You can’t just set up an SMTP server and call it a day. You need layers of protection:

• TLS Encryption: Encrypts the email in transit so nobody can snoop on the content. Non-negotiable in my book.
• SPF Records: Tells receiving servers which IP addresses are authorized to send email for your domain. Without this, your emails will probably land in spam.
• DKIM Signing: Adds a digital signature to your emails proving they haven’t been tampered with. Amazon SES handles this beautifully.
• DMARC Policies: Ties SPF and DKIM together and tells receivers what to do with emails that fail authentication checks.
• IP Reputation: Your sending IP’s reputation directly impacts deliverability. This is why managed services like SES are so valuable — they actively manage IP reputation.

I once inherited a server where someone had ignored all of these, and the IP was blacklisted on every major blocklist. Took weeks to clean up. Don’t be that person.

Common SMTP Error Codes

When things go wrong — and they will — SMTP error codes are your first clue. Here are the ones I see most often:

• 250: The happy code. Everything worked. Mail action completed.
• 421: Service temporarily unavailable. The server’s overwhelmed or shutting down. Usually resolves on its own.
• 450: Mailbox unavailable. Could be a temporary issue like the mailbox being full.
• 550: The mailbox doesn’t exist or the server is rejecting your email. This one stings.
• 551: User not local. The server is telling you to try a different path. Rare in modern setups.

Pro tip: any 4xx error is temporary and worth retrying. Any 5xx error is permanent and means something needs to change on your end.

Popular SMTP Server Options

You’ve got plenty of choices when it comes to SMTP servers, each with their own personality:

• Postfix: My go-to for self-hosted email. Open source, fast, and battle-tested. It’s what most Linux servers run.
• Microsoft Exchange: The enterprise standard. Heavy, but it does everything if you’re in a Microsoft shop.
• Sendmail: The grandfather of mail transfer agents. Still around, still works, but Postfix has largely replaced it.
• Exim: Popular on cPanel servers. Flexible configuration but can be quirky.
• Amazon SES: If you’re already on AWS, this is the obvious choice. Pay-per-email pricing, excellent deliverability, and it handles all the infrastructure headaches for you.

That’s what makes Amazon SES endearing to us cloud engineers — it takes all the pain out of email infrastructure while keeping costs absurdly low. Seriously, $0.10 per 1,000 emails is hard to argue with.

Setting Up Your Own SMTP Server

If you want to go the self-hosted route, here’s the process I follow:

1. Pick your software. I usually go with Postfix on Ubuntu, but your mileage may vary.
2. Install it on a server with a static IP. Don’t try to run email from a dynamic IP — you’ll get blacklisted immediately.
3. Configure your server address, port, and authentication settings. Lock it down so only authorized users can send.
4. Set up your DNS records: MX records pointing to your server, SPF, DKIM, and DMARC records.
5. Send test emails to multiple providers (Gmail, Outlook, Yahoo) and check if they land in the inbox or spam.

Fair warning: running your own SMTP server is a commitment. You’re responsible for security patches, IP reputation management, and dealing with delivery issues. For most people, a managed service like SES is the smarter choice.

SMTP Server Logs

Logs are your best friend when troubleshooting email problems. A good SMTP server logs every transaction — timestamps, sender and recipient addresses, the response codes from each step, and any errors that occurred.

I make it a habit to set up log monitoring with CloudWatch when running email infrastructure on AWS. Catching a problem early — like a sudden spike in bounce rates — can save your IP reputation before it tanks. Check your logs regularly, even when things seem fine. Especially when things seem fine.

Using SMTP With Common Platforms

Most email clients make SMTP configuration pretty painless:

• Microsoft Outlook: Head to account settings, add a new account, and plug in your SMTP server details under outgoing mail.
• Gmail: Go to Settings, then Accounts and Import, and configure the “Send mail as” section with your SMTP credentials.
• Thunderbird: Open account settings, add an outgoing server entry, and fill in the SMTP details.

The process is basically the same everywhere: server address, port number, username, password, and encryption type. If it’s not working, double-check the port and encryption settings first — that’s where most mistakes happen.

SMTP Services for Business

Most businesses these days use a third-party SMTP service instead of running their own servers. It just makes sense — let someone else deal with IP warming, reputation management, and infrastructure scaling. Here are the big players:

• Amazon SES: Best value for AWS users. The API is solid, the deliverability is excellent, and it integrates with everything else in the AWS ecosystem.
• SendGrid: Popular with developers. Great dashboard, good analytics, and a generous free tier.
• Mailgun: Strong API-first approach. I’ve used their email validation API and it’s saved me from sending to a ton of bad addresses.
• SMTP.com: Been around forever. Reliable and straightforward.

Optimizing SMTP Performance

If you’re sending at any serious volume, you’ll need to think about performance:

• Connection Pooling: Reuse SMTP connections instead of opening a new one for each email. This alone can dramatically improve throughput.
• Queue Management: Monitor your email queue and set up alerts for backlogs. A growing queue usually means something downstream is wrong.
• IP Warming: If you’re on a new IP, start with low volume and gradually ramp up. Blasting 100,000 emails from a brand-new IP is a guaranteed way to get blacklisted.
• Bounce Handling: Process bounces immediately and remove bad addresses from your list. High bounce rates destroy your sender reputation.

The Biggest Challenges

Running SMTP infrastructure isn’t all smooth sailing. The challenges I see most often:

• Spam and Phishing: Your server will be a target. Lockdown authentication and monitor for abuse.
• IP Blacklisting: One bad day can get your IP blocked by major providers. Monitor your reputation with tools like MXToolbox.
• Deliverability: Getting to the inbox (not the spam folder) is an ongoing battle. Authentication records, content quality, and sender reputation all play a role.
• Compliance: CAN-SPAM, GDPR, and other regulations add requirements around unsubscribe links, data handling, and consent.

What’s Next for Email

SMTP has been around since the 1980s, and it’s still going strong. The protocol itself doesn’t change much, but the ecosystem around it keeps evolving. Better authentication standards like BIMI (Brand Indicators for Message Identification) are gaining traction, letting senders display their logo next to emails in supported clients.

Machine learning is making spam filters smarter, which means legitimate senders need to be more diligent about following best practices. And with privacy regulations tightening globally, expect more changes in how email data is collected and processed.

For now, my advice is simple: use a managed service like Amazon SES unless you have a very specific reason to run your own SMTP infrastructure. It’ll save you time, money, and a whole lot of midnight debugging sessions.