My mail server isn't receiving email
What this is
You run a mail server on your VPS (Mailcow or a classic Postfix stack) and mail sent to you isn't arriving. Inbound delivery is a short, strictly ordered chain, DNS → connection → acceptance → mailbox, and the failure is always at exactly one link. Walk it in order.
Link 1: DNS, can senders find you?
A sending server looks up your domain's MX record, then connects to that host:
dig +short MX yourdomain.com
dig +short A mail.yourdomain.com
- The MX must exist and point at a hostname (
mail.yourdomain.com), and that hostname must resolve via an A record, an MX pointing at a CNAME or straight at an IP is out of spec and breaks with some senders. - No MX at all? Some senders fall back to your domain's A record, many don't; set the MX.
- Changed DNS recently? Propagation applies, and mind a stale AAAA record on the mail hostname pointing somewhere that isn't listening.
Link 2: is anything listening on port 25?
Inbound mail arrives on port 25, and a port is only open if something listens:
ss -tulnp | grep :25
You want a LISTEN on 0.0.0.0 (or the public address), not 127.0.0.1. Nothing there? The mail service (or its SMTP container, in Mailcow's case) isn't running, fix that first. Then check nothing filters it: our edge firewall doesn't touch port 25 inbound, but your own ufw/iptables default-deny policy might, ufw allow 25/tcp.
Link 3: test the whole path from outside
From your home machine (not the VPS, that skips DNS and network):
telnet yourdomain.com 25
A healthy server answers 220 mail.yourdomain.com ESMTP ... within seconds. Or do the full conversation in one command with swaks, the SMTP Swiss army knife:
swaks --to [email protected] --server yourdomain.com
- Connection refused instantly → reached the machine, nothing listening (Link 2).
- Timeout → something dropping packets (the reject-vs-drop rule), your firewall, or note that many residential ISPs block outbound port 25, so a timeout from home Wi-Fi may mean your ISP, not your server; test from another VPS or use an online SMTP test to be sure.
- Connects but the recipient is rejected (
Relay access denied,User unknown) → the server doesn't consider itself responsible for that domain/mailbox: the domain or mailbox isn't configured in your mail stack. That's a mail-software config fix, not a network one.
Link 4: it's accepted but never appears
If swaks succeeds and mail still "doesn't arrive", it arrived and went somewhere: check the spam/junk folder, and then the mail log, which records every message's fate:
tail -50 /var/log/mail.log # classic stacks
# Mailcow: the postfix container's logs in its UI or docker logs
Greylisting (first attempt deferred, retried minutes later), a full mailbox or full disk, and overzealous spam scoring are the usual endings. The log line for the message names which.
Ask the sender for the bounce
When a specific sender's mail fails, the bounce message they received is the single most useful artifact, it contains your server's (or their server's) exact rejection line. "It just doesn't arrive, no bounce" plus a clean mail log usually means the sender's message never left their side.
Still need help?
You can open a support ticket. So we can help on the first reply, it's worth mentioning:
- the VPS and the mail domain,
- what the MX lookup and the telnet/swaks test from outside show,
- the exact rejection or bounce text, if a sender got one.
Related questions
- "Why isn't my mail server receiving email?"
- "How do I test SMTP on port 25 from outside?"
- "What should my MX record point to?"
- "What does relay access denied mean?"
- "Mail is accepted but not in the mailbox, where did it go?"