MX & SMTP Technical Reference (RFC 5321)

What This Reference Covers

RFC 5321 defines the Simple Mail Transfer Protocol (SMTP) — the protocol that moves email between servers. It also defines how MX (Mail Exchanger) records work: the DNS records that tell sending servers where to deliver email for a domain.

This page covers the MX lookup algorithm, SMTP reply codes, EHLO/HELO behavior, Null MX, open relay prevention, and the rules that trip up administrators most often. Use the mxio MX Lookup to check your domain's MX configuration.

MX Lookup Algorithm (§5.1)

When a sending server needs to deliver email to user@example.com, it follows a specific algorithm to find the destination mail server. This is not a simple DNS query — it is a multi-step process with fallback behavior defined in the RFC.

Step 1: Query MX Records

The sender queries DNS for MX records at example.com. Each MX record has a preference value (lower = higher priority) and a hostname:

example.com  MX  10  mx1.example.com
example.com  MX  20  mx2.example.com

The sender tries mx1.example.com first (preference 10). If it is unreachable, it falls back to mx2.example.com (preference 20).

"The sender-SMTP MUST order the MX RRs by preference value, with the lowest value having the highest priority." — RFC 5321 §5.1

Step 2: Equal Preference — Random Selection

When multiple MX records share the same preference value, the sender must distribute load:

"If there are multiple destinations with the same preference and they are the highest-preference destinations, the sender-SMTP SHOULD use some mechanism to spread the load across them." — RFC 5321 §5.1

This is commonly implemented as random selection or round-robin among equal-preference records.

Step 3: No MX Records — Fall Back to A/AAAA

If no MX records exist, the sender falls back to the domain's A (IPv4) or AAAA (IPv6) record:

"If no MX records are found, but an A RR is found, the A RR is treated as if it was associated with an implicit MX RR." — RFC 5321 §5.1

This means a domain without MX records can still receive email if it has an A record pointing to a server running SMTP. However, this is a fallback mechanism — explicitly publishing MX records is strongly recommended. See Missing MX Records for why this matters.

Step 4: Null MX (RFC 7505)

RFC 7505 introduced the Null MX — a way to explicitly declare that a domain does not accept email:

example.com  MX  0  .

A single MX record with preference 0 and a target of . (the root domain) tells sending servers not to attempt delivery. This is cleaner than having no MX records (which triggers A record fallback) or using a nonexistent hostname (which produces delayed bounces).

"A domain that advertises a null MX MUST NOT accept email." — RFC 7505 §3

Use Null MX for parked domains, redirect-only domains, and any domain that should never receive email.

MX Must Not Point to a CNAME

RFC 2181 §10.3 and RFC 5321 §5.1 prohibit MX records from pointing to CNAME records:

"MX records MUST NOT point to a CNAME alias." — RFC 5321 §2.3.5

This is one of the most commonly violated DNS rules. In practice, many resolvers will follow the CNAME chain and deliver the mail. But some will not, and the behavior is explicitly undefined by the RFC. If your MX target is a CNAME, the MX Lookup tool flags it.

Also noted in RFC 1912 §2.4: "Don't use CNAMEs in combination with RRs which point to other names like MX."

EHLO and HELO (§4.1.1.1)

When two SMTP servers connect, the sending server introduces itself with an EHLO (Extended HELO) or HELO command:

EHLO mail.example.com

The hostname provided should be the fully qualified domain name (FQDN) of the sending server. This is not just a formality — receiving servers use the EHLO hostname for:

• Reverse DNS validation — Does the EHLO hostname resolve to the connecting IP?
• SPF evaluation — The EHLO domain is checked separately from the MAIL FROM domain
• Logging and reputation — Receiving servers log the EHLO hostname for troubleshooting

"The domain name given in the EHLO command MUST be either a primary hostname (a domain name that resolves to an address RR) or, if the host has no name, an address literal." — RFC 5321 §2.3.5

A misconfigured EHLO hostname (nonexistent domain, localhost, generic hostname) is a common reason for spam classification. The Header Analyzer extracts EHLO information from message headers.

SMTP Reply Codes (§4.2)

SMTP uses three-digit reply codes to communicate the result of each command. Understanding the code structure is more useful than memorizing individual codes.

The Three-Digit System

The second digit narrows the category:

Common Codes

For a comprehensive guide to bounce codes and how to resolve them, see Email Bounce Codes.

Enhanced Status Codes (RFC 3463)

RFC 3463 extends the three-digit system with structured status codes in the format class.subject.detail:

550 5.1.1 User unknown

The 5.1.1 breaks down as:

• 5 = Permanent failure
• 1 = Addressing
• 1 = Destination address unknown

This provides machine-readable granularity beyond the basic three-digit code. Major providers include enhanced status codes in their bounce messages.

The Received Header (§4.4)

Every SMTP server that handles a message adds a Received: header, creating a chain that traces the message's path from origin to destination:

Received: from mail.example.com (mail.example.com [203.0.113.1])
    by mx.recipient.com (Postfix)
    with ESMTPS id ABC123
    for <user@recipient.com>;
    Mon, 3 Mar 2026 10:15:30 -0800 (PST)

"When an SMTP server receives a message for delivery or further processing, it MUST insert trace information at the beginning of the message content." — RFC 5321 §4.4

Received headers are read bottom-to-top: the oldest (originating server) is at the bottom, the most recent (your mail server) is at the top. The Header Analyzer parses this chain and calculates hop-by-hop delivery times.

Received Header Forgery

Headers below the first trusted server in the chain can be forged by the sender. Spammers routinely add fake Received headers to obscure the true origin. Only trust headers added by servers in your receiving infrastructure.

Open Relays (§7.2)

An open relay is an SMTP server that accepts email from any sender to any recipient, regardless of whether either is local. Open relays are the internet's oldest email abuse vector.

"SMTP servers SHOULD NOT relay mail from addresses or to addresses outside any domains they serve." — RFC 5321 §7.2

A properly configured SMTP server only relays mail that is:

• Inbound to a domain it serves (delivering to local mailboxes)
• Outbound from an authenticated user or authorized network

If your server is an open relay, it will be blacklisted rapidly. The Blacklist Check tool verifies your IP against major DNS blocklists.

Message Size Limits

RFC 5321 §4.5.3.1.8 specifies that SMTP servers must accept messages of at least 64KB (including headers). In practice, most servers accept messages up to 25-50MB, and the SIZE extension (RFC 1870) allows servers to advertise their limit during the EHLO exchange.

If a message exceeds the server's size limit, the server responds with:

552 5.3.4 Message size exceeds fixed maximum message size

Quick Reference

---

This reference covers RFC 5321 — Simple Mail Transfer Protocol, authored by J. Klensin. Supplementary RFCs referenced: RFC 7505 (Null MX), RFC 3463 (enhanced status codes), RFC 1912 (DNS operational guidelines), RFC 2181 (DNS specification clarifications), RFC 1870 (SMTP SIZE extension). Content on this page is an editorial interpretation; see the original RFCs for normative text. RFC content is subject to the IETF Trust's Legal Provisions.