Inside corporate email:
what's actually running on your mail server
“Mail is down” — three words that make any sysadmin's stomach drop. Every message travels through 7–8 separate components, and any one of them can fail.
Here's a map of the whole chain. Not abstract theory — the actual pieces running on your server the moment you click Send.
MUA — the mail client
Outlook, Thunderbird, Apple Mail, mobile Gmail — all of these are MUAs. The application where you type your message and hit Send.
For an organization, standardizing the client is worth the effort. IT support is simpler with one application than a mix of five. Outlook fits Microsoft shops well; Thunderbird is free and flexible.
SMTP · port 587
The client hands the message to the server over STARTTLS-encrypted SMTP.
MTA — Mail Transfer Agent
Postfix · Exim · Sendmail
The courier. It picks up the message and carries it across the internet to the recipient's server. Server-to-server delivery also runs over SMTP, but on port 25.
Postfix ships on nearly every Linux server. Exim runs on most cPanel hosts. Both handle thousands of messages per minute without breaking a sweat.
A misconfigured MTA is where delivery problems start. Slow queues, undelivered messages — this is the first place to check.
DNS records
- MX — tells the internet which server accepts your mail. No MX record, no incoming mail. Full stop.
- SPF — a list of IPs authorized to send on behalf of your domain. Everything else is suspect.
- DKIM — a digital signature. Your server signs outgoing mail; the recipient verifies it. Proof nothing was tampered with in transit.
- DMARC — policy for messages that fail SPF or DKIM, plus aggregate reports so you can see who's sending from your domain.
Four records. Without them, your domain is an open door for spoofing.
TLS encryption
Without TLS, email travels as plain text. Like a postcard — any server along the route can read it.
With TLS, the message is in a sealed envelope. Gmail shows a red lock icon on unencrypted incoming mail. Your partners will notice.
TLS isn't optional anymore. It's baseline hygiene.
Anti-spam filters
SpamAssassin · Rspamd · built-in Google/Microsoft filters
Dozens of signals: sender reputation, content, links, DNS records. A good filter catches spam and phishing — the top threat for corporate inboxes.
An overly aggressive filter is worse than none. A client's message landing in Spam is a lost deal. Getting the threshold right matters more than running the most restrictive ruleset.
MDA — Mail Delivery Agent
Dovecot · Cyrus
The message has arrived. The MDA sorts it into the right mailbox — like a mail sorter at a distribution center. It applies filters, rules, and checks quotas.
Mailbox full? The MDA bounces the message back to the sender. Watch your mailbox quotas — otherwise colleagues silently miss incoming mail.
📨
IMAP
Messages stay on the server; every client syncs to the same state. Laptop, phone, tablet — one inbox, everywhere.The business standard.
📥
POP3
Downloads messages and removes them from the server. Old-school. Useful when storage is tight and you're working from a single device.
🌐
Webmail
Roundcube, SOGo, or Gmail/Outlook Web. Open a browser and you're in. Works well as a fallback when clients aren't available.
Address validation — the piece most teams overlook
All this infrastructure is wasted if you're sending to dead addresses. Every bounce hurts your domain reputation. Enough bounces and you're on a blacklist.
uChecker checks each address before delivery: syntax, domain DNS, mailbox existence, and spam traps. Via API — automatically, at the point of collection or right before a send.
Validate your list →Where the chain usually breaks
Knowing the diagram matters less for its own sake than for what it lets you infer from a symptom. "Mail will not send" and "mail sends but never arrives" are different failures in different places, and they are fixed differently.
When a client cannot send at all, the fault lies between client and MTA: port 587 closed, wrong credentials, a STARTTLS requirement the client will not satisfy. All of it shows up in the mail server log and none of it is visible from outside.
When the message leaves and the recipient never sees it, the segment is different: DNS and anti-spam. This is where SPF, DKIM and DMARC operate, and where the inbox-or-spam decision gets made. You diagnose it not from logs but from the Authentication-Results header on the message itself and from aggregate DMARC reports.
The third case is a message accepted by the receiving server that never reaches the mailbox. That means the MDA or a recipient-side filtering rule acted on it. The sender has no leverage here: their logs show a successful delivery, because formally it was one.
Why running your own server costs more than it looks
Standing up Postfix is an evening's work. What follows rarely makes it into the estimate: warming the IP address, registering with postmaster consoles, configuring reverse DNS, monitoring blocklists, processing bounces, rotating DKIM keys. Each item is manageable alone; together they add up to continuous work.
Which is why the split became standard practice: transactional and marketing mail goes to a specialised service with warmed infrastructure, while the in-house server keeps internal correspondence, where volumes are small and reputation does not come into it.
Corporate email is a pipeline, not a single app: client → SMTP → MTA → DNS + TLS → anti-spam → MDA → mailbox. Break one link and mail stops working.
Knowing which piece does what makes troubleshooting faster and configuration decisions clearer. And validating your list keeps the whole machine from spinning on bad addresses.