A mail transfer agent (MTA), sometimes written "message transfer agent", is the software that moves email from one server to the next. When you send a message, an MTA accepts it, works out where the recipient's domain receives mail, and delivers it over SMTP, passing it on through other MTAs until it reaches its destination. This guide explains what a mail transfer agent does, where it fits among the other parts of the mail system, what happens when delivery fails, and how it differs from a mail client or a mail server.
What is a mail transfer agent?
The Internet Mail Architecture, described in RFC 5598, names the MTA as the component that relays messages between systems. The standard uses the term "Message Transfer Agent", and most people say "mail transfer agent"; they mean the same thing. An MTA is not the program you read mail in. It works in the background, usually as a server process that listens for connections, accepts messages, stores them in a queue and sends them on.
Well-known examples of MTA software include Postfix, Exim, Sendmail and Microsoft Exchange. Large sending services run MTAs built or tuned for high volume. Our own sending engine, MigoMTA, is an MTA designed for delivering a lot of mail reliably while pacing itself towards each mailbox provider.
The parts of the mail system
| Part | Full name | What it does |
|---|---|---|
| MUA | Mail User Agent | The program a person uses to write and read mail, such as an email app or webmail |
| MSA | Mail Submission Agent | Accepts new messages from MUAs, normally on port 587 after authentication |
| MTA | Mail Transfer Agent | Relays messages between servers using SMTP |
| MDA | Mail Delivery Agent | Places a received message into the recipient's mailbox |
| MX record | Mail exchanger (DNS) | Tells senders which MTA receives mail for a domain |
In many products one program plays several of these roles. A single server can act as the submission agent, the transfer agent and the delivery agent. The roles matter because they explain where each problem happens: a login failure is a submission problem, a rejection by another server is a transfer problem, and a missing message in the inbox may be a delivery problem.
How an MTA delivers a message
- Accept. A client or another MTA connects over SMTP and submits a message. The MTA checks who is allowed to send and records the sender and recipients. See our article on the SMTP server.
- Queue. The message is written to a queue on disk, so it is not lost if the server restarts.
- Look up the destination. The MTA asks DNS for the MX records of the recipient's domain. These name the servers that accept the mail and give each a priority. See email DNS records.
- Connect and send. The MTA opens a connection to the destination, usually trying the highest-priority server first. It negotiates TLS if both sides support it, and then submits the message.
- Handle the answer. A success reply means the next system has accepted responsibility. A temporary failure means the message stays in the queue for another attempt. A permanent failure creates a bounce message back to the sender.
Retries, queues and bounces
A well-behaved MTA retries temporary failures with growing intervals, for hours or days, before giving up. When it gives up, or when the destination returns a permanent error, it sends a delivery status notification to the sender's address. This is the bounce. How your MTA handles retries and back-off affects both delivery and reputation, since hammering a server that asked you to slow down is a bad signal. Read email rate limits, retries and back-off and email bounce types.
MTA vs mail client vs mail server
- A mail client is the app you use to write and read mail. It is a MUA, not an MTA.
- A mail server is a computer, or the software on it, that handles mail. It usually runs an MTA and may also run the IMAP or POP3 service that lets users read their mail. See what IMAP is.
- An SMTP server is an MTA described by the protocol it speaks. The terms overlap.
- An SMTP relay is an MTA configured to accept mail from you and forward it for you. See SMTP relay explained.
Why the MTA matters for deliverability
The MTA is where much of the sending behaviour is decided. It controls how many connections are opened to each mailbox provider, how fast messages are released, how failures are retried, whether TLS is used, what name the server announces and which IP address it sends from. Those choices decide whether providers see a careful sender or a flood. This is why high-volume senders use specialised MTAs and why a sending service's pacing and queue management are worth asking about.
Several DNS settings also tie to the MTA. The server's IP needs a reverse DNS record that matches its announced name; see reverse DNS for email. The sending domain needs SPF and DKIM and a DMARC policy. See SPF and DKIM.
Should you run your own MTA?
You can. Installing Postfix or Exim on a server is not hard. Running it well is. You take on IP reputation, blocked ports, blocklists, TLS certificates, queue monitoring, security and abuse handling. Most applications are better served by a hosted service that runs a tuned MTA for them. Read our guide to SMTP servers and SMTP services to decide.
Checking what your MTA is doing
MTAs keep logs and queues. In a hosted service, you read them as message logs and events. In your own MTA, you read the logs and the queue listing. In both cases, the question is the same: for each message, what did the next system say? Our article on tracing a message through its delivery lifecycle shows how to read them, and reading email headers shows the path a message took from the other end.
Open relays and why they are dangerous
An MTA that accepts mail from anyone and forwards it to anyone is called an open relay. In the early days of the internet this was common and friendly. Today it is an invitation for spammers, who use open relays to send mail that appears to come from someone else. Modern MTAs require authentication before relaying for a user, and accept mail from the outside only for the domains they host. If you run an MTA, test that it is not an open relay, because a listing on blocklists can follow quickly.
Pacing and connection limits
Receiving servers protect themselves by limiting how many connections and messages they accept from one sender in a short time. A good MTA keeps separate settings per destination domain: how many connections to open, how many messages to send on each, and how fast to go. It also reads replies that signal "slow down" and backs off. A badly configured MTA that sends as fast as it can to every provider will cause deferrals and rejections even when the mail itself is fine. This is the part of an MTA that high-volume senders value most.
Want a managed MTA without running one? Our relay handles queues, retries and pacing for you. Tell us your volume and we will help you connect.
References and further reading
Frequently asked questions
What is a mail transfer agent?
A mail transfer agent (MTA) is software that moves email between servers using SMTP. It accepts a message, queues it, finds the recipient's mail server through DNS MX records and delivers it, retrying temporary failures.
Is a message transfer agent the same as a mail transfer agent?
Yes. The Internet Mail Architecture standard uses the name Message Transfer Agent, and most people say mail transfer agent. Both abbreviate to MTA.
What is the difference between an MTA and an MUA?
An MUA, or mail user agent, is the program a person uses to write and read mail. An MTA works in the background to relay messages between servers.
What are examples of MTA software?
Well-known examples include Postfix, Exim, Sendmail and Microsoft Exchange. Sending services run MTAs tuned for high volume.
Should I run my own MTA?
You can, but you then take on IP reputation, blocked ports, blocklists, TLS, queue monitoring and security. Most applications are better served by a hosted service.