Mail server: what it is, how it works, and why it matters
A mail server is a program (or a set of programs) that accepts, stores, routes, and delivers email. When you send a message from ivan@company.com to olga@partner.com, it passes through at least two mail servers: one on the sender's side, one on the recipient's.
A mail server is not one monolithic piece of software. It is an architecture of several components, each with a distinct job. Understanding that architecture helps with deliverability troubleshooting, DNS configuration, and reading error messages during email address validation.
Three core components
A classic mail system has three parts: MTA, MDA, and MUA.
MTA — Mail Transfer Agent
The transfer agent is the core of the mail server. It accepts a message from the sender (or another MTA), looks up the destination via DNS MX records, and hands the message off. Well-known MTAs include Postfix, Exim, Microsoft Exchange, and Sendmail. The MTA speaks SMTP and listens on port 25 for server-to-server traffic, or ports 587/465 for client submissions.
MDA — Mail Delivery Agent
Once the MTA has a message for a local user, it passes it to the MDA. The MDA's job is to put the message into a specific mailbox, in Maildir, mbox, or database format. Dovecot (which also handles IMAP/POP3), Procmail, and Sieve are common examples. The MDA also does filtering: sorting into folders, running SpamAssassin, and applying user rules.
MUA — Mail User Agent
The mail client is what end users interact with: Thunderbird, Outlook, Apple Mail, Gmail's web interface. The MUA is not strictly part of the server, but it is where users send and read mail. It connects to the server via IMAP or POP3 to fetch messages, and via SMTP to send them.
How a message travels from sender to recipient
Say Ivan sends a message to Olga. Here is what happens:
- Ivan's MUA (Thunderbird) connects to his mail server's MTA (smtp.company.com) via SMTP on port 587 with authentication.
- The MTA at company.com queries DNS: which MX record does partner.com have? It gets back mx.partner.com with priority 10.
- The MTA opens an SMTP connection to mx.partner.com on port 25 and delivers the message.
- The MTA at partner.com checks SPF, DKIM, and DMARC. If everything passes, it hands the message to the local MDA.
- The MDA places the message in Olga's mailbox. If SpamAssassin is configured, the message goes through the filter first.
- Olga opens Outlook, which fetches the message from the server via IMAP.
Types of mail servers
Servers are grouped by function:
- Inbound server — accepts mail for the domain. MX records point to it. It handles authentication checks, spam filtering, and delivery to mailboxes.
- Outbound server — sends mail out. It acts as an SMTP relay. This can be self-hosted (Postfix on a VPS) or cloud-based (SendGrid, Amazon SES).
- Relay server — sits between two MTAs. Used in corporate networks for centralized filtering and policy enforcement.
- Email gateway — placed in front of the main server. Handles security: anti-spam, antivirus, DLP.
DNS records a mail server needs
For a mail server to work properly, the domain's DNS zone needs several records:
- MX record — names the server that accepts mail for the domain. Without it, messages will not arrive.
- A record — maps the server's hostname to an IP address. The MX record points to a hostname; the A record resolves that hostname.
- PTR record — reverse DNS. It resolves an IP back to a hostname. Many mail systems reject messages from servers without a PTR record.
- SPF, DKIM, DMARC — authentication records that confirm the server is authorized to send on behalf of the domain.
Mail servers and email validation
When a validator checks an email address, it connects directly to the recipient's MTA over SMTP and asks: "Will you accept mail for user@domain.com?" The server's response code (250, 550, or 450) tells the validator whether the mailbox exists.
Not all servers answer honestly. Catch-all servers accept everything. Servers with greylisting return a temporary rejection. Some close the connection without responding at all. That is why validation is not a single SMTP probe — it requires reading the specific server's behavior pattern.
Common problems
- Missing PTR record — messages get rejected by Gmail, Yahoo, and other major providers.
- IP on a blocklist — if the server was used to send spam, its IP ends up in a DNSBL. Mail from that IP lands in spam or gets rejected outright.
- Broken SPF/DKIM — messages fail authentication and go to spam.
- Queue backup — the MTA cannot keep up with volume, messages pile up, and delivery slows or stalls.
uChecker checks whether the recipient's mail server is reachable, inspects its MX records and PTR, and observes how its MTA behaves during the SMTP handshake. The result is not just an address status — it is a full picture of the domain's mail infrastructure.
