Mail Flow and Anti-Spam Refresher Series – Part 1: Mail Delivery Basics

Lately, I’ve been involved in diagnosing a handful of mail delivery issues. What used to be a relatively straightforward process has evolved into something far more complex thanks to the ongoing arms race against spammers, scammers, and other bad actors who continue to exploit email as an attack vector.

Platforms like Mail Assure are working hard to stay ahead of these threats, but when an email doesn’t get delivered, it’s not always easy to pinpoint what went wrong or where the failure occurred. That said, many issues stem from something simple. So over the course of the next few blog posts, I’ll break down the fundamentals of SMTP (Simple Mail Transfer Protocol) delivery, explore anti-spam technologies, and share practical tips to help you get the most out of Mail Assure.

Let’s dig in.

The SMTP Delivery Loop: Step-by-Step

When you hit “send” on an email, it feels instant. But under the hood, there’s a precise and layered process that ensures your message gets from sender to recipient securely, reliably, and (hopefully) without ending up in the junk folder.

Here’s what happens when one mail server sends a message to another:

1. MX Record Lookup
   The sender extracts the recipient’s domain (e.g., @n-able.com) and queries DNS for its MX record, which tells it which server handles mail for that domain. Where more than one MX records exists they are tried in a lowest priority order.
2. Hostname Resolution
   The MX record points to a hostname depending on what delivery service is being used (e.g., n-able-com.mail.protection.outlook.com for domains using native M365). The sender performs a DNS lookup for A (IPv4) or AAAA (IPv6) records to get the IP address.
3. SMTP Connection
   The sender opens a connection to the recipient’s mail server on TCP port 25. The recipient responds with an SMTP banner (e.g., 220 mail.n-able.com ESMTP). Optional encryption can be used here to “upgrade” the connection to one secured by TLS (Transport Layer Security).
4. EHLO/HELO Handshake
   The sender introduces itself with EHLO (or HELO in legacy setups). The recipient replies with its capabilities – like supported extensions and max message size.
5. Sender & Recipient Info
   The sender issues MAIL FROM: with the envelope sender address, followed by RCPT TO: for each recipient. The server accepts or rejects each one.
6. Message Transmission
   The sender sends the DATA command. After receiving 354 Start mail input, it transmits the message headers and body, ending with a single period (.). The recipient replies with 250 OK if successful.
7. Session Closure
   The sender sends QUIT, and the recipient replies with 221 Bye. The message is now queued for delivery or forwarded if needed.

This loop is the backbone of email delivery. If something breaks, say a DNS misconfiguration or a blocked port, your message might bounce, stall, or vanish.

SMTP Submission vs Relay: Know the Difference

• Client-to-Server SMTP (Submission)
  Used by email clients (Outlook, scanners, apps) to send mail to their own server. Happens on port 587, requires authentication, and uses TLS encryption. Or this can be another proprietary protocol used depending on the mail servers involved.
• Server-to-Server SMTP (Relay)
  Used when one mail server delivers to another. Happens on port 25, typically unauthenticated, and may use opportunistic TLS via STARTTLS.

Understanding these roles helps diagnose delivery issues, like why your scanner can’t send mail externally or why your outbound mail is rejected.

DNS Records That Make It All Work

• MX Records: Direct mail to the correct server.
• A/AAAA Records: Resolve hostnames to IPs.
• PTR Records: Enable reverse DNS lookups, which many servers use to verify legitimacy.

Misconfigured DNS is a common cause of delivery failures. Always verify that your domain’s MX points to the right host (e.g., <yourdomain>.mail.protection.outlook.com for M365 with no additional protections). 

Why This Matters

This foundational knowledge isn’t just academic—it’s essential for:

• Troubleshooting delivery failures
• Understanding bounce messages (NDRs)
• Configuring devices and apps to send mail
• Preparing for anti-spam and security layers

In Part 2, we’ll explore how platforms filter spam, authenticate senders, and protect against spoofing and phishing using industry standard technologies such as SPf, DKIM and DMARC before looking deeper into troubleshooting steps.

Ben Lee is a Head Nerd at N‑able and has a long history working in the Microsoft space. You can find him on LinkedIn as BenLeeUK or email him at [email protected]