# My mail server isn't receiving email
Source: https://vpsdime.com/knowledgebase/troubleshooting/cannot-receive-email
Last reviewed: 2026-07-02
Summary: The inbound checklist, an MX record pointing at an A record (not a CNAME), something actually listening on port 25, no firewall in the way, and the mail log telling the rest. How to test from outside with telnet/swaks and read sender bounces, plus where rejected-but-received mail actually went (spam scoring).

## What this is

You run a mail server on your VPS ([Mailcow](https://vpsdime.com/knowledgebase/technical-questions/mailcow-on-linux-vps) 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](https://vpsdime.com/knowledgebase/getting-started/pointing-your-domain), 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](https://vpsdime.com/knowledgebase/troubleshooting/my-port-xxx-is-closed):

```
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](https://vpsdime.com/knowledgebase/troubleshooting/allow-ssh-in-common-firewalls) 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 you@yourdomain.com --server yourdomain.com
```

- **Connection refused instantly** → reached the machine, nothing listening (Link 2).
- **Timeout** → something dropping packets ([the reject-vs-drop rule](https://vpsdime.com/knowledgebase/troubleshooting/my-port-xxx-is-closed)), 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](https://vpsdime.com/knowledgebase/troubleshooting/disk-full), 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](https://vpsdime.com/open-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?"