MTA: the server that carries mail from one domain to another

A Mail Transfer Agent (MTA) is the server software that accepts a message over SMTP and passes it along to the next server until it reaches the recipient's mailbox. It sits at the heart of any sending infrastructure: it is the component that talks to mailbox providers, absorbs their throttling, and writes the logs that explain what actually happened to each message.

What an MTA is, and what it is not#

Three families of software take part in the life of an email:

• the MUA (Mail User Agent) is the mail client: Thunderbird, Outlook, a provider's webmail, or the application that generates transactional messages;
• the MTA (Mail Transfer Agent) accepts the message over SMTP, chooses a route, queues it and delivers it to the MTA of the recipient's domain;
• the MDA (Mail Delivery Agent) writes the message into the final mailbox, where the MUA will read it over IMAP or POP.

An MTA is therefore a relay. It may relay outbound mail (a company's sending server or an email service provider's fleet) or inbound mail (the server named in a domain's MX record). The same software often does both.

How an MTA routes a message#

For every recipient, the outbound MTA follows four steps:

1. It extracts the domain from the address (example.com in mary@example.com).
2. It queries DNS for that domain's MX records, sorted by priority.
3. It opens a TCP connection on port 25 to the lowest-priority MX, negotiates STARTTLS if offered, then sends EHLO, MAIL FROM, RCPT TO and DATA.
4. It reads the reply: a 250 code means the message was accepted, 4xx means try again later, 5xx means the message is permanently rejected.

A shortened exchange looks like this:

S: 220 mx1.example.com ESMTP
C: EHLO smtp-out.sender.net
S: 250-mx1.example.com
S: 250-STARTTLS
S: 250 SIZE 52428800
C: MAIL FROM:<newsletter@sender.net>
S: 250 2.1.0 Ok
C: RCPT TO:<mary@example.com>
S: 250 2.1.5 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
S: 250 2.0.0 Ok: queued as 4F3A2B1C

On a temporary refusal (421, 450, 451) the MTA keeps the message in its queue and retries on a growing schedule, typically for two to five days, before returning a non-delivery report (bounce) to the sender.

Common software#

The most widely deployed MTAs are Postfix, Exim and Sendmail in the open-source world, Microsoft Exchange in corporate environments, and high-volume commercial products such as PowerMTA, KumoMTA, Halon or MailerQ. Email service providers almost always run their own MTA fleet, invisible to their customers, but it is the hostname of those machines that shows up in the Received headers of the delivered message.

On the receiving side, the large mailbox providers (Google, Microsoft, Yahoo, Orange, Free and others) run inbound MTAs that absorb millions of connections per hour and apply their reputation rules during the SMTP session itself.

What an outbound MTA has to get right#

A well-configured MTA presents a consistent identity to mailbox providers:

• The name announced in EHLO is a fully qualified hostname that genuinely exists in DNS.
• The sending IP address has a PTR record, and that PTR resolves back to the same address (see the page on MX records and reverse DNS).
• The MTA offers a valid TLS certificate and supports STARTTLS both inbound and outbound.
• Messages are DKIM-signed before leaving the server, and the MAIL FROM address belongs to a domain covered by SPF.
• The MTA honours each provider's limits on concurrent connections and messages per connection, and slows itself down when it receives 4xx codes.

The sender requirements published by Google and Yahoo in 2024 make several of these points mandatory for bulk senders: valid reverse DNS, TLS, SPF or DKIM authentication, and a complaint rate kept below 0.3%.

What to watch in the logs#

MTA logs are the most reliable source for diagnosing a delivery problem. Every delivery attempt leaves a line with the recipient, the MX contacted, the reply code and its text. A typical Postfix line:

Oct  1 09:14:22 smtp-out postfix/smtp[18233]: 4F3A2B1C: to=<mary@example.com>,
  relay=mx1.example.com[203.0.113.10]:25, delay=0.42, status=sent (250 2.0.0 Ok)

Indicators worth tracking continuously:

• the share of 4xx and 5xx replies per destination provider;
• the rejection texts, which usually carry a provider-specific error code and a documentation URL;
• the queue size and the age of the oldest queued message;
• the average delivery time per destination, whose degradation often signals provider-imposed throttling.

Common mistakes#

• Announcing a generic name in EHLO (localhost, mail, the machine's internal name) that matches no DNS entry.
• Allowing unauthenticated relaying from the whole local network, which turns the server into an open relay abused within hours.
• Ignoring 4xx codes and keeping the same sending rate, which turns a temporary slowdown into a block.
• Not processing bounces, so invalid addresses stay on the lists and the error rate climbs with every campaign.
• Keeping logs for too short a period to reconstruct the history of an incident.

Further reading#

Analysing the logs of an MTA fleet, destination by destination and reply code by reply code, calls for dedicated tooling once volume exceeds a few thousand messages a day. Postmastery describes an approach to monitoring MTA logs and domain reputation that picks up where this guide leaves off on the operations side.