{"id":75402,"date":"2025-10-22T11:20:40","date_gmt":"2025-10-22T10:20:40","guid":{"rendered":"https:\/\/www.n-able.com\/?p=75402"},"modified":"2025-11-19T10:48:02","modified_gmt":"2025-11-19T10:48:02","slug":"mail-flow-and-anti-spam-refresher-series-part-1-mail-delivery-basics","status":"publish","type":"post","link":"https:\/\/www.n-able.com\/it\/blog\/mail-flow-and-anti-spam-refresher-series-part-1-mail-delivery-basics","title":{"rendered":"Mail Flow and Anti-Spam Refresher Series \u2013 Part 1: Mail Delivery Basics"},"content":{"rendered":"

Lately, I\u2019ve 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.<\/span><\/p>\n

Platforms like Mail Assure<\/a> are working hard to stay ahead of these threats, but when an email doesn\u2019t get delivered, it\u2019s 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\u2019ll 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.<\/span><\/p>\n

Let\u2019s dig in.<\/span><\/p>\n

The SMTP Delivery Loop: Step-by-Step<\/span><\/h2>\n

When you hit \u201csend\u201d on an email, it feels instant. But under the hood, there\u2019s 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.<\/span><\/p>\n

Here\u2019s what happens when one mail server sends a message to another:<\/span><\/p>\n

    \n
  1. MX Record Lookup<\/span><\/strong>
    \nThe sender extracts the recipient\u2019s domain (e.g., @n-able.com) and queries DNS for its MX record<\/strong>, 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.<\/span><\/li>\n
  2. Hostname Resolution<\/span><\/strong>
    \nThe 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)<\/strong> or AAAA (IPv6)<\/strong> records to get the IP address.<\/span><\/li>\n
  3. SMTP Connection<\/span><\/strong>
    \nThe sender opens a connection to the recipient\u2019s mail server on TCP port 25<\/strong>. The recipient responds with an SMTP banner (e.g., 220 mail.n-able.com ESMTP). Optional encryption can be used here to \u201cupgrade\u201d the connection to one secured by TLS (Transport Layer Security).<\/span><\/li>\n
  4. EHLO\/HELO Handshake<\/span><\/strong>
    \nThe sender introduces itself with EHLO (or HELO in legacy setups). The recipient replies with its capabilities \u2013 like supported extensions and max message size.<\/span><\/li>\n
  5. Sender & Recipient Info<\/span><\/strong>
    \nThe sender issues MAIL FROM: with the envelope sender address, followed by RCPT TO: for each recipient. The server accepts or rejects each one.<\/span><\/li>\n
  6. Message Transmission<\/span><\/strong>
    \nThe 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.<\/span><\/li>\n
  7. Session Closure<\/span><\/strong>
    \nThe sender sends QUIT, and the recipient replies with 221 Bye. The message is now queued for delivery or forwarded if needed.<\/span><\/li>\n<\/ol>\n

    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.<\/span><\/p>\n

    SMTP Submission vs Relay: Know the Difference<\/span><\/h2>\n