MTA (mail transfer agent)
An MTA is a program that moves email between servers. It accepts a message, decides where it should go next by looking up the recipient domain's MX record, opens a connection to that host and hands the message over. Queueing, retries and bounce notices are its responsibility. When people talk about running their own mail server, this is usually the part they mean.
At a glance
- Category
- Infrastructure
- Speaks
- SMTP, to other transfer agents
- Decides routing by
- The recipient domain's MX records
- Owns
- The queue, the retry schedule and failure notices
- Distinct from
- The mail client, and from the delivery agent that files mail
- Specified in
- RFC 5321
How it works
A transfer agent takes a message with an envelope sender and one or more recipients and puts it in a queue. For each recipient domain it looks up the MX records, sorts them by priority and tries them in turn. It opens a connection, usually upgrades it to TLS, presents the envelope and the message, and reads the reply. A success code means the next host has taken responsibility. A temporary failure goes back on the queue with a growing delay; a permanent one produces a bounce notice.
Why it matters
The transfer agent is where nearly all the hard operational work of email actually lives: queue management, retry policy, connection reuse, rate limiting per destination, TLS negotiation, and turning a receiving server's reply into something a human can act on. Understanding that this is a distinct role explains why an email API exists at all — it is this component, run as a service, with an HTTP interface in front of it instead of a queue directory.
Example
A message for someone at example.com reaches a transfer agent. It looks up the MX records for example.com, finds two hosts with different priorities and connects to the lower-numbered one. That host is busy and answers with a temporary failure, so the message goes back on the queue. Four minutes later the agent tries the second host, which accepts the message. One delivery, two connection attempts, no bounce.
Common mistakes
- 01Confusing the transfer agent with the mail client, and expecting a reply code to say whether a person read the message.
- 02Running one without a sensible retry schedule, so a receiving server's brief deferral becomes a permanent failure.
- 03Assuming acceptance by the next hop means delivery to a mailbox, when it only moves responsibility one step along.
- 04Reusing one connection for an unlimited number of messages to a single destination, which many receiving servers treat as abuse.
Related terms
Frequently asked questions
Is an email API just a hosted MTA?
In part. The transfer agent is the core, but the service around it also handles authentication records, suppression, event delivery and reporting, which are the parts teams usually underestimate.
What is the difference between an MTA and an MDA?
A transfer agent moves mail between servers, while a delivery agent files an accepted message into the right mailbox at the destination. The two are often bundled in the same software.
Why would I still run my own?
Usually for internal routing or for an environment that cannot reach an external service. For public sending it means owning warm-up, reputation, feedback loops and TLS, which is a full-time role rather than a deployment.
Sources
Last updated 16 September 2026.
Start sending this morning
Verify a domain and send your first email in minutes.