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 →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.