What Is a Mail Transfer Agent (MTA)? How Email Gets Delivered

What is a mail transfer agent (MTA)?

A mail transfer agent (MTA) is the software that moves email from one server to another. It accepts a message, looks up the recipient domain's MX record to find the right server, and hands the message over using SMTP. A separate component, the MDA, handles final delivery. Postfix, Exim and Sendmail are examples.

This guide is for website and online store owners, and for developers who manage their own hosting account. First we explain the path an email takes and the four roles on that path. Then we cover port 25 versus 587, the queue, relaying and the open relay risk.

We are a digital marketing and web team, not a hosting company. So the explanations rest on RFC documents and Google's official email sender guidelines. We do not walk you through an installation. Instead, our goal is to help you understand email infrastructure decisions and ask your provider the right questions.

The question "what is an MTA" usually comes up at a bad moment. A contact form notification never arrives, a newsletter lands in spam, or a bounce message appears. So this article shows you what to check in each case. One small note on naming: RFC 5598 spells the term "Message Transfer Agent", while everyday usage says "Mail Transfer Agent". In practice, both describe the same component.

How do the MTA, MUA, MSA and MDA differ?

Email is not the work of a single program, because it needs several cooperating roles. There are four roles in the chain, and RFC 5598 (the Internet email architecture) defines each one. However, in small setups one piece of software can play several roles. Even so, separating the roles helps you find where a problem actually sits.

RFC 5598 compares an MTA to a packet switch or an IP router. In other words, its job is to make a routing decision and move the message closer to the recipient. Managing the mailbox or the user interface is not an MTA task. For example, if you cannot log in, the problem sits with the MSA. If the message leaves but never arrives, look at the MTA and your DNS records.

What path does an email take from sender to recipient?

Following the path step by step also makes the MTA's place clear. The sequence below is a simplified view of a typical delivery. However, real setups can add extra servers, security scanners and forwarding rules.

1. First, the sender writes the message in the MUA and presses send.
2. Next, the MUA hands it to the MSA, which verifies identity and passes it to the outgoing MTA.
3. Then that MTA queries DNS for the recipient domain's MX record.
4. After that, it connects to the server named in the MX record and delivers the message over SMTP.
5. Once there, the recipient's MTA accepts the message and passes it to the MDA.
6. Finally, the MDA writes the message into the recipient's mailbox.
7. Later, the recipient opens the mailbox in their own MUA and reads it.

Step four, for example, moves the message from server to server, and that is the MTA's real work. Meanwhile, the remaining steps either prepare the message or finish the delivery.

Therefore, use this order as a map when troubleshooting. If the message stalls at step two, you have an authentication problem. If it stalls at step three, the DNS record is missing or wrong. Likewise, a stall at step four means the receiving server is refusing the message or returning a temporary error. Finally, problems at steps five and six usually sit inside the recipient's own system, such as a full mailbox.

How is a mail transfer agent connected to the MX record?

An MX record is simply the DNS entry that tells senders which server accepts mail for a domain. The outgoing MTA looks up the MX record for the recipient's domain and connects to the server it returns. According to RFC 5321 section 3.6.2, a relay server is usually the target of an MX record rather than the final delivery system.

When a domain has several MX records, each one carries a priority value. The MTA tries the lowest value first, which is the preferred server. Then, if that server does not answer, it moves on to the next record. However, if a domain has no MX record at all, RFC 5321 section 5.1 allows a fallback to the A or AAAA record.

So a wrong MX record sends mail to the wrong server, or nowhere. You can check your records with our DNS lookup tool. Also check them especially after you switch email providers. A DNS change can take time to spread, and during that window some messages may go to the old server and some to the new one.

What is SMTP and how do MTAs talk to each other?

SMTP (Simple Mail Transfer Protocol) is the protocol MTAs use to pass email along, and RFC 5321 defines it. It is a text protocol, so the client sends a command and the server answers with a three-digit code. For example, the shortened session below shows the flow with example domains.

S: 220 mx.example.net ESMTP ready
C: EHLO mail.example.com
S: 250-mx.example.net
S: 250 STARTTLS
C: MAIL FROM:<sender@example.com>
S: 250 OK
C: RCPT TO:<recipient@example.net>
S: 250 OK
C: DATA
S: 354 Send the message, end with a dot
C: (headers and message body)
C: .
S: 250 Queued
C: QUIT

The S at the start of a line marks the server, and the C marks the client. First the two sides introduce themselves (EHLO). Then the envelope is given (MAIL FROM and RCPT TO), and the message itself comes last (DATA). Once the server says "Queued", it has taken over responsibility, and that point matters in the queue section below. So a message that shows as "sent" has not necessarily arrived. It only means the first MTA accepted it.

What is the difference between port 25, 587 and 465?

Port 25 is for server-to-server transfer, while port 587 is the submission port where a client first hands over a message. According to RFC 6409, an MSA on port 587 must by default reject the MAIL command if the session is not authenticated. Port 465 does not appear in RFC 6409, and some providers offer it with implicit TLS.

In practice, when you configure a mail client or a WordPress plugin, enter the port and encryption type your provider supplies. So do not try random ports. Instead, rely on the provider's help page.

Which mail transfer agent software exists: Postfix, Exim or Sendmail?

Postfix, Exim and Sendmail are different programs that do the same job. All of them speak SMTP, keep a queue and route email. However, the differences show up in configuration style, default behavior and the distribution or hosting panel that ships them. Still, the table below gives only a general frame.

Which one runs is often not your choice. On shared hosting, the provider makes that call. Therefore, before asking which MTA is better, ask a more useful question: how does my provider manage email delivery?

What is an MTA queue and why do emails wait?

The queue is where an MTA temporarily stores messages it could not deliver yet. If the receiving server is busy, returns a temporary error or cannot be reached, the MTA does not delete the message. Instead, it retries at intervals. RFC 5321 section 4.5.4 expects the retry process to run for several days.

Postfix, for example, uses several queue areas: incoming for new mail, active for mail being prepared for delivery, deferred for postponed mail and hold for mail stopped by hand. These names appear in the Postfix QSHAPE document. To see what is waiting, you use the commands below.

postqueue -p
mailq

The second command is equivalent to the first. The output shows each message's queue ID, size, sender and recipient. If thousands of messages pile up, the cause is usually on the receiving side, or unwanted mail is leaving your server. In that case, do not delete the queue on your own. Instead, tell your provider.

What do SMTP error codes mean: 4xx versus 5xx?

The first digit of an SMTP reply tells you whether the problem is temporary or permanent. Codes starting with 4 are temporary, so the MTA keeps the message and retries. Codes starting with 5 are permanent, so the MTA stops trying and generates a bounce message for the sender.

For example, if the recipient address does not exist, you get a 5xx and must correct the address. If the receiving server is busy at that moment, you get a 4xx and the MTA retries by itself. Always read the text of a bounce message, because the cause is usually written right there.

Why does a bounce message come with an empty sender?

A bounce message tells the sender that an email could not be delivered. RFC 5321 section 4.5.5 asks for an empty return address on these notifications: MAIL FROM:<>. The goal is to prevent an endless loop if the bounce itself cannot be delivered.

Also, this detail helps when you troubleshoot. If the sender field of a bounce looks empty or like a system address, treat that as normal. However, what matters is the technical explanation inside the message. There you find the name of the receiving server, the error code and a short reason.

• Check whether the error code is 4xx or 5xx.
• Search the reason text in a search engine, in quotes.
• Use the receiving server's name to see which side has the problem.
• If needed, forward the full message to your provider.

What does a hosted email service mean for your mail transfer agent?

If you use a cloud email service such as Google Workspace or Microsoft 365, the service provider runs the MTA for you. You only point your MX records at the values that service gives you. As a result, the queue, TLS, relay restrictions and security updates leave your responsibility.

However, not everything is handed over. You still manage the SPF, DKIM and DMARC records for your domain. You also decide how your website's own emails, such as order notifications and form replies, reach that service. So when you move to a new service, check two things: your MX records and the way your site sends mail.

Choosing a provider is a separate topic, and we do not compare providers here. You can find the options and the benefits of a domain-based address in our business email guide.

What do smarthost and email forwarding mean for an MTA?

A smarthost means an MTA hands its outgoing mail to another server instead of delivering it directly. For example, the local MTA on your server does not send to the recipient itself. It passes the message to an authenticated email service. Delivery reputation then depends on that service's infrastructure.

Forwarding is a different thing. A message sent to one address is automatically passed on to another address. During forwarding, the original sending server stays the same, but the server doing the sending is now the forwarder. Because of this, some receiving servers may fail forwarded messages in their SPF check.

• A smarthost decides which server outgoing mail leaves from.
• Forwarding moves incoming mail to another address.
• In both cases, watch authentication and record alignment.
• Take the setting values from your provider's help page.

What is a relay and why is an open relay dangerous?

A relay happens when an MTA passes on mail for a domain it does not own to another server. Legitimate relaying works for authenticated users or defined networks. An open relay is a misconfigured server that forwards mail from anyone to any address.

The danger is simple. An attacker can send millions of unwanted emails under your server's name through an open relay. As a result, your IP address lands on blocklists, your legitimate emails drop into spam folders, and your provider may suspend your account. Worse, you often do not notice for weeks.

RFC 5321 section 3.6.2 says a server may decline to relay to a particular address for policy reasons, and it should answer with a 550 reply. Modern MTA software does not allow open relaying by default. The risk mostly comes from broad permissions added by hand.

How can you be sure your server is not an open relay?

First, find out who manages the server. On shared hosting or a managed VPS, relay settings are the provider's responsibility. In that case, ask the provider for written assurance. If you run your own VPS, you need to read and verify the relay restriction settings in the MTA's official documentation.

If you use Postfix, the relevant settings are the smtpd_relay_restrictions and mynetworks parameters. Read their exact meaning and safe values in the official Postfix documentation. We do not recommend values here, because a wrong mynetworks entry can open your server to the whole network.

• Look for an unexpected amount of outgoing email from the server.
• Watch whether the queue grows unusually.
• Be suspicious if many bounce messages arrive.
• Check with your provider whether your IP address is on a blocklist.

Do not flood third-party servers with test messages. Run tests only with addresses you control, and with your provider's knowledge.

Should you run your own mail transfer agent or leave it to your host?

For most website owners the answer is clear: leave the email infrastructure to your provider or a managed email service. Running your own MTA means managing DNS records, TLS, the queue, blocklist monitoring and security updates all the time. One mistake can damage the reputation of your whole domain.

You should not handle your own MTA in these cases:

• You have no experience diagnosing delivery problems.
• Your site sends critical messages such as customer emails and order notifications.
• You do not have time to follow security updates regularly.
• Your server is on shared hosting, where you have no access anyway.

If you manage your own VPS and still want to set up an MTA, read our hosting selection guide first. Our guides to Fail2ban and the CSF firewall also help you protect the server.

How do SPF, DKIM and DMARC relate to the MTA?

SPF, DKIM and DMARC are DNS-based records that the receiving MTA checks to confirm a message really comes from you. According to Google's sender guidelines, all senders need to set up SPF or DKIM. Senders of more than 5,000 messages a day must set up all three: SPF, DKIM and DMARC.

• SPF lists which servers may send email on behalf of your domain.
• DKIM adds a digital signature to the message header to show the content was not altered.
• DMARC tells the receiver what to do when authentication fails.

In short, the MTA carries the message, and these three records prove the carried message is trustworthy. You can test your records with our SPF, DKIM and DMARC checker. Before you change records on your own, list every service that sends email for you, such as your site, CRM and newsletter tool. A missing record sends that service's emails to spam.

Why do PTR records and TLS matter for delivery?

Receiving MTAs also look at the identity of the connecting server. According to Google's sender guidelines, the sending IP address must match the IP address of the hostname in its PTR record. The forward DNS record (A or AAAA) must also resolve to the same IP address. Without this match, a message can be rejected or sent to spam.

The same guidelines ask you to use a TLS connection when transmitting email. TLS makes it harder to read a message on its way between servers. As a result, PTR and TLS help your server look like a properly run MTA.

The owner of the IP address, meaning your hosting or cloud provider, usually sets the PTR record. You cannot create a PTR record from your own DNS panel. So contact your provider about it. Imagine an example IP such as 203.0.113.10: only the party that allocated the address to you can change its reverse record. When you write to support, ask which hostname the PTR record for your server's IP address points to.

Do WordPress sites send email through an MTA?

Yes, but in two different ways. By default, WordPress uses PHP's mail function, which hands the message to the local MTA on the server. The alternative is to connect to an outside email service with authentication through an SMTP plugin. Plugins such as WP Mail SMTP make this second route easier.

Here the question of what a mail transfer agent does gets practical. Your site's email leaves from a local MTA or an outside service, and the receiver judges it by that source. Form notifications that land in spam are often the result of the first method. The sender domain and the sending server do not match, so SPF and DKIM checks fail.

Our business email guide covers the corporate side in more detail. We do not explain plugin setup here. Use the SMTP values your provider gives you.

How do you diagnose email that is not being delivered?

Start by separating who is responsible: the sender, the receiver or a server in between. The order below goes from the cheapest check to the most expensive. That way you do not bother your provider needlessly, but you also do not waste time when you need them.

1. Read the bounce message and note whether the code is 4xx or 5xx.
2. Make sure you typed the recipient address correctly.
3. Check the domain's MX records with a DNS lookup.
4. Test the SPF, DKIM and DMARC records.
5. Check your server's IP address and its reverse DNS record.
6. Ask your provider whether messages are waiting in the queue.
7. If the problem continues, open a support ticket with the full bounce message.

You can also use the IP lookup tool to see who owns an IP address. This step helps you tell whether the problem sits on your server or with a third party.

What changes for email marketing when you pick an MTA?

For newsletters and campaigns, sender reputation matters more than the MTA itself. The behavior of everyone sending from the same IP address affects that address's reputation. Also, with bulk sending, receiving servers may apply rate limits and turn messages away with a temporary 4xx error.

For this reason, sending campaigns along the same route as your normal mailbox is not a good idea. Separating transactional email, such as orders and password resets, from marketing email makes sense, because one stream's trouble should not hurt the other. Your email service provider's documentation guides how to make that split.

Google's guidelines ask senders to keep the spam rate reported in Postmaster Tools below 0.3 percent. So list hygiene and easy unsubscribing matter as much as technical settings. You can also read how AI fits into campaigns in our AI in email marketing article.

What are the common misconceptions about MTAs?

We hear a few misconceptions about MTAs again and again. Knowing them saves time when you talk to your provider or hunt for a problem. Below we give the correct version of each.

• "The MTA is the mailbox." No. The component that writes into the mailbox is the MDA.
• "Port 25 and 587 are the same." No. One is for server-to-server transfer and the other for client submission.
• "Without an MX record, no email arrives." Not always. RFC 5321 allows a fallback to an A or AAAA record.
• "Messages in the queue are lost." Usually they are not. The MTA retries.
• "I set up SPF, so I am done." Not enough. You need DKIM and DMARC too.

Most misconceptions come from reducing email to a single piece of software. In reality, email is a chain of DNS, authentication, reputation and several programs working together. When you are unsure at any point, contacting your hosting provider's support is the safest route, because they hold the access and the responsibility for server-side settings.

Where should you start with mail transfer agents?

In short, an MTA is the software that carries email from server to server, and it forms a chain with the MUA, MSA and MDA. The MX record shows the way, SMTP provides the language and the queue adds resilience. An open relay is the most expensive mistake in this setup. To decide what to do, clarify your own situation first.

1. Work out who carries your email: your host, an email service or your own server.
2. Check your MX, SPF, DKIM and DMARC records.
3. Find out whether your site sends mail with the PHP function or with SMTP.
4. Ask your provider about relay and PTR settings.
5. Separate critical emails from marketing emails.
6. Keep a copy of your current DNS records before you change anything.

If you want your website's email, speed and security infrastructure reviewed together, take a look at our web design service. Our SSL certificate guide also covers the security side. This article gives no legal or technical guarantee. For details, read RFC 5321, RFC 5598, RFC 6409 and Google's email sender guidelines.