What is a mail transfer agent (MTA)?

You never see a mail transfer agent, but every email you've received passed through at least two of them. MTAs are the post offices of email: they sort, hold and pass messages along until one reaches the right mailbox. Knowing where they sit makes bounces, delays and filtering decisions much easier to understand. This guide complements what is SMTP, which covers the protocol the MTAs speak.

What is a mail transfer agent?

An MTA is server software that receives a message and passes it one step closer to its recipient. RFC 5598, the Internet Mail architecture document, defines it this way: an MTA "relays mail for one application-level 'hop'. It is like a packet switch or IP router in that its job is to make routing assessments and to move the message closer to the Recipients."

Three details from that definition matter in practice:

• It's both client and server. An MTA receives a message as an SMTP server, then sends it on as an SMTP client.
• It doesn't rewrite the message. RFC 5598 says an MTA "does not change addresses in the envelope or reformulate the editorial content". Relays that do change messages are, in the RFC's terms, acting as gateways.
• It leaves a trace. An MTA "also adds trace information", the Received: headers you read from the bottom up in how to read email headers.

MTA vs MUA vs MSA vs MDA: what's the difference?

RFC 5598 splits email into roles. One product often plays several, but the roles stay distinct.

The MSA is where your mail first enters the system. RFC 5598 says it "enforces the policies of the hosting ADMD and the requirements of Internet standards", and points to the submission standard, now RFC 6409, which "uses a separate TCP port and imposes distinct requirements, such as access authorization". That's why your mail app logs in on port 587 while server-to-server traffic uses port 25; see SMTP ports 25, 587 and 465.

The MDA is where the transfer ends. RFC 5598 calls the handoff from the transport system to the recipient's mailbox "delivery", and says the MDA "records the RFC5321.MailFrom address into the RFC5321.Return-Path field". After that, the recipient's MUA reads the message with IMAP, POP or a provider's own protocol.

Boundary, inbound and final MTAs

RFC 5598 also names the positions an MTA can hold:

• Boundary (or border) MTA: exchanges mail with other organizations.
• Outbound MTA: a boundary MTA that "relays messages to other ADMDs" (administrative management domains).
• Inbound MTA: a boundary MTA that receives mail from outside, "for example, an MTA running on the host listed as the target of an MX record."
• Final MTA: "The MTA that transfers a message to the MDA."

In a small business on Microsoft 365, the outbound and inbound MTAs are Microsoft's. If you add a filtering gateway, it becomes your inbound boundary MTA, and Microsoft 365 becomes the final MTA.

How does a message travel between MTAs?

A typical journey from a colleague's Outlook to a customer's Gmail looks like this:

1. Submission. Outlook (the MUA) authenticates to Microsoft's submission service (the MSA).
2. Outbound relay. Microsoft's MTAs apply outbound policy and look up the recipient domain's MX records.
3. Transfer. Microsoft's outbound MTA connects to the host named in the customer's MX record and transfers the message over SMTP.
4. Inbound processing. The customer's inbound MTA decides whether to accept it, may filter it, and relays it internally.
5. Delivery. The final MTA hands the message to the MDA, which files it in the inbox or junk folder.
6. Reading. The customer's MUA shows the message.

Each MTA that accepts the message adds a Received: header. Paste a message's headers into the Email Header Analyzer to see each hop and its timestamp.

How an MTA decides where to send mail

RFC 5598 calls the DNS MX record "the dominant routing mechanism for Internet Mail". RFC 5321, section 5.1 sets the rules: when a domain has several MX records, the preference value "MUST be used in sorting", lowest first. If a domain has no MX records at all, the MTA falls back to an "implicit MX" pointing at the domain's own address record. You can see a domain's MX records with the MX Lookup, and what is an MX record explains them in full.

How do MTAs queue and retry messages?

MTAs are store-and-forward systems. RFC 5598 says they "are expected to store messages in a manner that allows recovery across service interruptions, such as host-system shutdown."

The key moment is acceptance. RFC 5321, section 6.1 says that when a server sends "250 OK" after DATA, "it is accepting responsibility for delivering or relaying the message" and "MUST NOT lose the message for frivolous reasons". From then on, the message sits in that MTA's queue until it's passed on or returned.

If the next hop is down or answers with a 4xx code, the MTA keeps the message and tries again. RFC 5321 says the retry interval "SHOULD be at least 30 minutes" and "the give-up time generally needs to be at least 4-5 days". Real MTAs follow that pattern with their own defaults. In Postfix, for example:

When an MTA finally gives up, or a later hop fails after acceptance, it must send a bounce. RFC 5321 says the notification goes to "the address from the envelope return path", sent with an empty (<>) sender so bounces can't bounce. That's why forged senders receive backscatter, and why what happens to email when your server is down is mostly a question of how long the sending MTA keeps trying.

What is the difference between relaying and an open relay?

Every MTA in the middle of a path is relaying. The question is for whom. A properly run MTA relays only for its own users (after authentication), its own networks, or mail addressed to domains it's responsible for. An open relay accepts mail from anyone to anyone and is quickly abused by spammers. A smart host is a relay you deliberately send through; see what is a smart host.

What are common MTAs?

In Exchange Server, the roles map neatly onto Microsoft's own components. Microsoft's transport pipeline overview says the Transport service "handles all SMTP mail flow for the organization, performs message categorization, and performs message content inspection", the Front End Transport service is "a stateless proxy for all inbound and (optionally) outbound external SMTP traffic", and the Mailbox Transport Delivery service delivers to the mailbox database. Exchange Online wraps all of this in a cloud service; what is Exchange Online Protection covers its filtering layer.

Where does spam filtering sit in the mail path?

Filtering can happen at several points, and the earlier it happens, the less work everything after it has to do.

Rejecting during the SMTP conversation is the cleanest outcome, because the sending MTA still holds the message and reports the failure to its own user; nobody you don't know receives a bounce from you. Filters that accept first must quarantine or deliver, not bounce, to avoid backscatter. How spam filters work walks through each check in order.

Next steps

• Look up which MTAs receive mail for your domain with the free MX Lookup.
• Trace a real message hop by hop in the Email Header Analyzer.
• If you run your own MTA, check its reverse DNS (PTR) and keep it off public blocklists.
• To see how an MX-level filter sits in front of your mailbox platform as the inbound boundary MTA, read how iBlockSpam works.

Browse our other email basics guides.