Mark AvrilovPublished updated 7 min read
Inside corporate email:
what's actually running on your mail server
“Mail is down.” Any sysadmin knows what kind of evening follows. Every message passes through a chain of programs, and any link in it can fail.
Here is a map of that chain: what runs on the server when you click Send, and where to look when something breaks.
What a mail server is
A mail server is a program, or more often a set of programs, that accepts, stores, routes and hands out email. A message from ivan@company.com to olga@partner.com crosses at least two of them, one on each side.
It is rarely one piece of software. One program moves mail between servers, another files it into mailboxes, a third serves it to the mail client, and each speaks its own protocol. The classic split into MTA, MDA and MUA pays off the first time you read a mail log or chase a bounce.
MUA: the mail client
Outlook, Thunderbird, Apple Mail, Gmail on the web or on a phone. The MUA is where you type and hit Send. Strictly speaking it isn't part of the server, but it is how people actually use one.
Standardizing on one client is worth it for an organization: one app is easier to support than five. Outlook suits Microsoft shops; Thunderbird is free and flexible.
SMTP · port 587 or 465
The client logs in and hands the message to the server. Port 587 upgrades to encryption with STARTTLS; port 465 is encrypted from the first byte.
MTA: Mail Transfer Agent
Postfix · Exim · Sendmail · Microsoft Exchange
The core of the server, and its courier. The MTA takes a message from a client or from another MTA, looks up the recipient domain's MX records to see where it goes, and passes it on. Servers talk to each other over SMTP as well, on port 25.
When a message can't be delivered right away, it waits in the MTA's queue and the server keeps retrying. If the MTA can't keep up with the flow, the queue grows and mail arrives late.
A badly configured MTA is the first suspect whenever mail crawls or doesn't leave at all.
DNS records
- MX names the server that accepts mail for the domain. With no MX, RFC 5321 has senders fall back to the domain's own A record; to refuse mail outright, publish a null MX.
- A maps the hostname from the MX to an IP address.
- PTR goes the other way, IP to name. Gmail and Yahoo require one on sending servers; see the guide to reverse DNS.
- SPF lists the servers allowed to send for the domain.
- DKIM publishes the key for checking signatures, so the receiver can tell whether the signed parts were altered.
- DMARC says what to do with mail that fails SPF and DKIM, and where to send reports on who is mailing as you.
MX and A get mail delivered. SPF, DKIM and DMARC keep others from forging your domain.
TLS encryption
Without TLS a message crosses the network in plain text, like a postcard, readable on any hop between servers. TLS encrypts each of those hops.
Google requires TLS from everyone sending to Gmail, and Gmail users see a red open lock on mail that arrived unencrypted.
Anti-spam filters
SpamAssassin · Rspamd · built-in Google/Microsoft filters
A filter weighs dozens of signals: sender reputation, SPF, DKIM and DMARC results, links, attachments, wording. A good one stops both spam and phishing, and phishing is the bigger danger for a corporate inbox.
It is easy to overdo. A client's message in Spam can cost a deal, so the threshold gets tuned rather than cranked up. Larger companies often move filtering to a separate gateway in front of the main server.
MDA: Mail Delivery Agent
Dovecot · Cyrus · Procmail
Once the message reaches the recipient's server, the MTA hands it to the MDA, which writes it into a specific mailbox as Maildir, mbox or a database record. Rules run on the way in: folder sorting, user filters written in Sieve, quota checks.
A full mailbox means the message goes back to the sender with an error. Keep an eye on quotas, or colleagues will quietly lose incoming mail.
📨
IMAP
Mail stays on the server and every client syncs to it. Laptop, phone and tablet all see the same inbox.The business standard.
📥
POP3
Downloads mail to the device and usually deletes it from the server. Old-school, but still around where there is one device and little server space.
🌐
Webmail
Roundcube, SOGo, or the web versions of Gmail and Outlook. Open a browser and you're in. Handy as a fallback.
How a message travels from sender to recipient
Ivan at company.com writes to Olga at partner.com. Step by step:
- Ivan's Thunderbird connects to smtp.company.com on port 587, authenticates and submits the message.
- The company.com MTA asks DNS for partner.com's MX record and gets mx.partner.com.
- It opens an SMTP connection to mx.partner.com on port 25 and delivers the message.
- The partner.com MTA checks SPF, DKIM and DMARC, runs the message through anti-spam and hands it to the MDA.
- The MDA files it in Olga's mailbox.
- Olga's Outlook fetches it over IMAP.
To confirm the first steps work on your side, run an MX lookup and an SMTP test.
Types of mail servers
In a small company one machine does everything. As mail volume grows, the roles split apart.
- Inbound server. Accepts mail for the domain; the MX points here. It checks authentication, filters spam and delivers to mailboxes.
- Outbound server. Sends mail out. That can be your own Postfix on a VPS or a cloud service such as Amazon SES or SendGrid.
- Relay. Sits in the middle, taking mail from one MTA and passing it to another. Corporate networks often route all outgoing mail through one so it can be filtered in a single place.
- Email gateway. Placed in front of the main server for security: anti-spam, antivirus, data loss prevention (DLP).
Where the chain usually breaks
The diagram earns its keep when you work back from a symptom. “Mail won't send” and “mail sends but never arrives” are different failures in different places, and they get fixed differently.
If your client can't send at all, the fault sits between client and MTA: port 587 or 465 closed, a wrong password, a client that can't do the STARTTLS the server demands. Your mail server log shows all of it, and the recipient never knows anything happened.
Message sent, recipient sees nothing? Then look at DNS and anti-spam. That is where SPF, DKIM and DMARC do their work and where inbox versus spam gets decided. You read it from the Authentication-Results header of the message itself and from aggregate DMARC reports, not from your logs. Blocklists belong here too: if spam went out from your server's IP, the address lands on a DNSBL, after which its mail gets rejected or junked. You can check an IP against blocklists.
The third case is a message the receiving server accepted that never reached the mailbox. The MDA or a recipient-side rule acted on it, which leaves the sender little to do: their logs show a successful delivery, because formally it was one.
Why running your own server costs more than it looks
Standing up Postfix takes an evening. What follows rarely makes the estimate: warming the IP, registering with postmaster consoles, reverse DNS, blocklist monitoring, bounce processing, DKIM key rotation. None of it is hard alone, but together it adds up to a standing job.
So a common split is to hand transactional and marketing mail to a sending service with warmed infrastructure and keep the in-house server for internal correspondence, where volumes are small.
Mail servers and email verification
To check an address, a validator talks straight to the recipient's MTA. It connects over SMTP, asks whether the server will take mail for user@domain.com, and reads the reply code (250, 550, 450 and so on) to learn whether the mailbox exists.
Not every server answers straight. A catch-all server accepts any address on the domain, so a yes proves nothing, and uChecker marks such addresses unknown. A full mailbox rejects mail, and the address is marked bad. A greylisting server answers with a temporary refusal first, so the check is retried later; when the refusal is aimed at the checker's IP rather than the address, the retry comes from a different IP. What looks like one SMTP question turns into a conversation shaped by how that particular server behaves.
Address validation: the piece most teams overlook
All this machinery spins for nothing if the mail goes to addresses that don't exist. Every hard bounce costs sender reputation, and a server that keeps mailing into the void risks a blocklist.
uChecker checks an address before you send: syntax, the domain's MX and the recipient server's reply. Each address comes back good, bad or unknown, and the API lets you run the check in a signup form or before a campaign.
Validate your list →Sources
Mark Avrilov · Author
Published Updated