Published 2 November 2026 · By Bram Van Daele, Teneo
A mail transfer agent, or MTA, is the program that carries an e-mail from one server to the next until it reaches the recipient's mailbox. This guide explains what an MTA does with a message, what the receiving side judges it on, and what changes when you let a relay run the MTA for you. We run MTAs for a living, so where we can, we say what we see.
A mail transfer agent is server software that accepts an e-mail over SMTP, works out where it has to go, and passes it to the next server, until the message arrives. Postfix, Exim and Sendmail are MTAs you can install yourself. The software behind every SMTP relay is one too. If you send mail from an application, an MTA sends it in the end, whether you run it or someone else does.
Where an MTA sits
Four roles take part when a message travels, and people mix them up:
- Mail user agent (MUA). The program that writes the message: Outlook, a phone app, or your own application code.
- Mail submission agent (MSA). The server that takes the message from the MUA. RFC 6409 defines this step and gives it its own port, 587, with a login. Many MTAs do this job as well.
- Mail transfer agent (MTA). The server that moves the message towards the recipient's domain. MTAs talk to each other on port 25 (RFC 5321).
- Mail delivery agent (MDA). The last step: the program on the recipient's side that puts the message in the mailbox.
"Message transfer agent" and "mail transfer agent" mean the same thing in everyday use. So does "SMTP server", when people say it loosely.
What an MTA does with a message
Every MTA follows the same sequence, and each step is a place where mail goes wrong.
- It accepts the message and queues it. From that moment the MTA is responsible for it. A message that has been accepted must be delivered or reported back as failed.
- It looks up where to deliver. It asks DNS for the MX records of the recipient's domain. If there are none, RFC 5321 tells it to fall back to the domain's A record. The MX with the lowest preference number is tried first.
- It connects and introduces itself. It opens a connection from one of its IP addresses, says EHLO with a hostname, and offers STARTTLS (RFC 3207) so the conversation is encrypted when the other side allows it.
- It hands over the message and reads the answer. A reply starting with 2 means the receiving server took the message. A reply starting with 4 means try again later. A reply starting with 5 means never. The text after the code is the receiving server's own explanation. That is the theory. In practice, mailbox providers treat these codes the way most drivers treat a speed limit: as a friendly suggestion. Gmail can answer a full mailbox with a 5xx, as if the recipient were gone for good, and plenty of servers send a 4xx for an address that will never exist. A good MTA reads the explanation too, not just the first digit.
- It retries or gives up. After a 4xx answer the MTA keeps the message in its queue and tries again later. RFC 5321 says the retry interval should be at least 30 minutes and that the total time before giving up should be at least four to five days. After a 5xx, or when the time is up, the MTA sends a bounce message back to the sender.
One thing in this sequence is often misread. A 2xx answer means the next server accepted responsibility for the message. It does not mean the message reached the inbox. What the receiving server does after that, inbox, spam folder or silent drop, happens after the SMTP conversation has ended, and the sending MTA hears nothing about it.
Why the MTA decides deliverability
The receiving server knows little about a message when it makes its first decision. It knows the IP address that is connecting, the name that address says it has, and what happened on earlier connections from there. So the first judgment is about the MTA, not about the content.
- The IP address and its history. Receivers and blocklists keep a record per IP address. Mail from an address with a bad record is slowed, filtered or refused before anyone reads the text.
- Names that match. The sending IP needs a reverse DNS name, the EHLO name has to resolve, and the two have to agree. Google's sender guidelines ask for forward and reverse DNS on sending IPs, and Spamhaus has announced it will enforce this from November 2026; we wrote that up in its own guide.
- Authentication. SPF (RFC 7208) checks that the IP may send for the domain, DKIM (RFC 6376) checks a signature, and DMARC (RFC 7489) ties both to the domain in the From header. Google asks every sender for SPF or DKIM, and bulk senders for SPF, DKIM and DMARC. The signing happens in the MTA or just before it. See our guide on rotating a DKIM key.
- Behaviour. How fast the MTA connects, how it reacts to 4xx answers, and how many complaints come back. Google tells senders to keep the spam rate reported in Postmaster Tools below 0.10% and never to reach 0.30%. RFC 5321 asks for at least 30 minutes between retries; an MTA that ignores that gives the receiver a reason to slow it down.
None of this is visible in your application code. It is a property of the MTA and the IP addresses it sends from, which is why two companies sending the same message can see different results.
Running your own MTA
Installing Postfix is the easy part. Running it so that mail arrives is the larger job. You need an IP address with a clean history and a reverse DNS name you control. Many ISPs and cloud providers block outbound port 25, so you may need to ask for it to be opened. After that you watch blocklists, read bounce messages, keep the queue healthy, rotate DKIM keys, and deal with each mailbox provider's rules as they change.
That makes sense when you have the people for it and a reason to want full control. For the mail most companies actually send, invoices and login codes, newsletters, abandoned-cart reminders, order and shipping updates, they would rather have someone else carry that work.
What a relay does with an MTA
An SMTP relay is a managed MTA that you submit your mail to. Your application, or the MTA you already run, connects to the relay on port 587, logs in, and hands over the message. From there the relay's MTA does everything in the list above, from IP addresses that were prepared for it.
If you already run Postfix, the change is a smart host: the line relayhost = [tlsrelay.teneo.be]:587 plus the login. Your own MTA keeps its queue and hands outbound mail on. If you have no MTA, the application connects to the relay directly, over SMTP or over HTTPS with an API.
This is how it works at Teneo. Our MTAs run on AWS in Ireland, on Teneo's own IP range. A message waits in our queue until it is delivered, for at most 48 hours; after that it is dropped and reported to you as a bounce. Message bodies are not kept once delivery is done. The delivery log keeps one line per message for 12 months: sender, recipient, subject line, times, and the receiving server's own answer in plain words, never the body.
What to check about the MTA behind a relay
Five questions tell you most of what you need:
- Which IP addresses does the mail leave from, and who else sends from them?
- Do the reverse DNS name and the EHLO name match, and are they in the provider's own domain?
- How long does the relay retry before it gives up, and do you find out?
- Can you read the receiving server's own answer for each message?
- Who can change the configuration when delivery to one provider goes wrong, and how long does it take to reach them?
We answer these for Teneo, point by point, on our page about what to look for in an SMTP relay service.
Want to see an MTA's answers for your own mail? Create an account, send a test message and read the receiving server's reply in the delivery log. → Create an account or → SMTP relay or email API: which one.
Frequently asked questions
What is a mail transfer agent?
A mail transfer agent (MTA) is server software that receives an e-mail over SMTP, finds the recipient's mail server through DNS and delivers the message to it, retrying when the other side says to try later. Postfix, Exim and Sendmail are examples.
Is an MTA the same as an SMTP server?
In everyday use, yes. SMTP is the protocol and an MTA is the program that speaks it between servers. Strictly, a server that only takes mail from users (submission, port 587) is an MSA, but most MTAs do both jobs.
What is the difference between an MTA, an MUA and an MDA?
The MUA is the program that writes and reads mail, such as Outlook. The MTA moves the message between servers. The MDA is the last step, which stores the message in the recipient's mailbox.
Which ports does an MTA use?
Port 25 is for server-to-server transfer between MTAs (RFC 5321). Port 587 is for mail submission from users and applications, with a login (RFC 6409). Port 465 is also used for submission, with encryption from the first byte (RFC 8314).
Do I need my own MTA if I use an SMTP relay?
No. An application can submit to the relay directly over SMTP or an API. If you already run an MTA such as Postfix or Exchange, you can keep it and set the relay as its smart host, so that all outbound mail leaves through the relay's IP addresses.
Sources: RFC 5321 (SMTP), RFC 6409 (message submission), RFC 3207 (STARTTLS), RFC 8314 (TLS for mail submission), RFC 7208 (SPF), RFC 6376 (DKIM) and RFC 7489 (DMARC); Google's email sender guidelines; Spamhaus Sender Guidelines. Statements about the Teneo platform describe our own service as of November 2026. No private communications were used.