๐ŸŒ Networks & infrastructure

How Email Travels: MX Records, SMTP and Mail Infrastructure

An email's journey from client to recipient: SMTP, MX records and priorities, reverse DNS, ports 25, 587 and 993, relays, and what to check if mail fails.

Email is one of the oldest Internet services and still one of the hardest to run well. Behind a simple "send" there are several servers, several protocols and a number of DNS checks. When a message fails to arrive, knowing this path lets you work out where it stopped instead of proceeding by trial and error.

The components

Component Role
Mail client (MUA) The application you write and read with: a program, app or webmail
Submission server Receives messages from your authenticated clients
MTA (Mail Transfer Agent) Transfers messages between servers of different domains
Receiving server and mailboxes Accepts mail for the domain and stores it
Access server (IMAP or POP3) Lets clients read the stored mail

Several roles often live on the same service, but keeping them distinct helps you understand where a problem arises.

A message's path

Suppose anna@example.com writes to luca@otherdomain.com:

  1. Anna's client connects to her provider's submission server on port 587 (or 465), authenticates with username and password and hands over the message on an encrypted channel.
  2. Anna's server has to work out where to deliver mail for otherdomain.com. It queries DNS for that domain's MX records.
  3. It gets, for example, two answers: 10 mx1.otherdomain.com and 20 mx2.otherdomain.com. It tries the lowest value first.
  4. It connects to mx1 on port 25 using the SMTP protocol, normally encrypted with STARTTLS, and transfers the message.
  5. The receiving server runs its checks: IP address reputation, reverse DNS, the sending domain's authentication policies, spam and virus filters.
  6. If the message passes, it lands in Luca's mailbox, and he will read it with his client over IMAP on port 993.

If mx1 does not respond, the sending server tries mx2. If none responds, it queues the message and retries for a period that usually extends to a few days, before returning a non-delivery notice.

The MX record in detail

  • The number is the priority: the lower it is, the more preferred the server. Servers with the same priority share the load.
  • The value must be a host name with A or AAAA records, not an IP address and not a CNAME.
  • If a domain has no MX records, sending servers try to deliver to the address in the domain's own A record. For a domain that should not receive mail, you can publish a "null MX" (0 .), explicitly stating that there is no mail server.

Backup MX servers

It used to be common to have a secondary MX at another provider, to receive mail when the primary was unreachable. Today it is less necessary, because sending servers queue and retry anyway. A poorly configured secondary MX is also often less protected against spam and becomes the spammers' favourite way in.

Reverse DNS and reputation

Anyone sending mail from their own server must take care of some infrastructure aspects that managed services handle for you:

  • Reverse DNS (PTR record): the server's IP address must resolve to a name, and that name must resolve back to the same IP. Many receiving servers reject or penalise mail from IPs without a consistent PTR. The PTR is set by whoever owns the IP address, that is the ISP or hosting provider, not in the domain's DNS panel.
  • Name in the SMTP greeting: the server must introduce itself with a valid name, consistent with the PTR.
  • IP reputation: addresses previously used for spam or belonging to residential ranges are often blocked outright.
  • Domain authentication: SPF, DKIM and DMARC records are now essential for large providers to accept the mail.

Why you cannot send mail from home

Many home broadband providers block outbound port 25, and residential IP addresses appear on lists that mail servers use to reject messages. It is a measure against infected computers sending spam.

If you host a mail server at home or on a virtual server with a poor-reputation IP, the most practical solution is to use a relay (smarthost): your server hands outgoing mail, after authenticating, to a sending service with a good reputation, which delivers it to the recipient.

Encryption between servers

STARTTLS between servers is opportunistic: if it fails, many servers deliver in clear text anyway. To make encryption mandatory towards your domain there are two mechanisms: MTA-STS, which publishes a policy via DNS and HTTPS, and DANE, which requires DNSSEC. They are most useful for domains that receive confidential data.

When mail does not arrive

  1. Check the recipient domain's MX records with dig MX otherdomain.com or nslookup -type=mx.
  2. Read the bounce message: it contains a code and often the precise reason for the rejection.
  3. Make sure your server has a consistent PTR and does not appear on public blocklists.
  4. Examine the headers of a message that did arrive: the "Received" lines show, from bottom to top, every server it passed through.

In short

  • Mail goes from client to submission server, then between servers via SMTP on port 25.
  • MX records name the receiving servers; the lowest number has priority.
  • An MX must point to a name with A or AAAA records, never to an IP or a CNAME.
  • Sending from your own server requires a consistent PTR, good reputation and domain authentication.
  • From home connections, use a relay, because port 25 is often blocked.
MM
Marco Marzaduri

Marco Marzaduri works in cybersecurity, digital forensics and web development. A computer science graduate, he combines rigorous technical analysis with attention to the people who use technology.

Read also