What a receiving server checks
| Check | Where it lives | When it is missing |
|---|---|---|
| MX | MX records of the domain | Mail to the domain goes to its A record, or nowhere |
| Reverse DNS | PTR record of the sending address, set by whoever holds the address | Many servers reject or junk the mail |
| SPF | TXT example.com | Receivers cannot tell your servers from anyone else's |
| DKIM | TXT selector._domainkey.example.com | Messages arrive unsigned; forwarding breaks SPF with nothing to fall back on |
| DMARC | TXT _dmarc.example.com | No policy against spoofing and no reports; Gmail and Yahoo require one from bulk senders |
| Blocklists | The lists' own DNS zones | — (a listing is the problem) |
Each section above answers one row. The SPF checker, DKIM checker and DMARC checker go through their record term by term; the blacklist check takes any address.
Reverse DNS for a server of your own
The PTR record of an address is not in your domain’s zone: it belongs to whoever holds the address block, which for a rented server is the provider. On a VMHeaven server you set it yourself in the control panel, for its IPv4 address and, where the server has one, for addresses in its IPv6 prefix. Point it at a host name — mail.example.com— and give that name an A (and AAAA) record with the same address, so that the two confirm each other:
dig -x 203.0.113.25 +short # → mail.example.com.
dig mail.example.com A +short # → 203.0.113.25Use the same name as the server’s HELO name. Receivers compare all three, and a generic provider name such as 203-0-113-25.example-hosting.net marks the address as one that was not set up for mail.
The same checks with dig
dig example.com MX +short
dig example.com TXT +short | grep spf1
dig s1._domainkey.example.com TXT +short
dig _dmarc.example.com TXT +short
dig _mta-sts.example.com TXT +shortdig answers from your own resolver, which may still hold an old record for the length of its TTL. After a change, the DNS propagation checker shows the domain’s own name server next to twelve public resolvers.
Before you run a mail server yourself
The records are the part you control in DNS. The rest is the server: a fixed address with matching reverse DNS, TLS on its SMTP ports, and an address with a clean history — check it on the blocklist check before you start, because a new server can inherit an address someone else got listed. Many hosting providers also restrict outgoing connections on port 25, the port servers deliver mail to each other on, so ask your provider about it before you plan around it.
Frequently asked
What does the mail server check look at?
Everything a receiving mail server can find out about your domain from DNS before it accepts a message: the MX records and the addresses behind them, the reverse DNS of those addresses, the SPF record with every include it pulls in, DKIM keys under your selector or nine common ones, the DMARC policy, the optional MTA-STS, TLS-RPT and BIMI records, and — on a click, because it makes the lists do work — whether the mail servers' addresses are on public blocklists. It reads DNS only and never connects to your mail server.
Why do I need SPF, DKIM and DMARC all at once?
They answer different questions. SPF lists the servers allowed to send mail for the domain, DKIM signs each message so that a receiver can check it came from you unaltered, and DMARC tells receivers what to do when a message claiming your domain passes neither — and where to send reports about it. Since February 2024 Gmail and Yahoo require SPF or DKIM from everyone who sends to them, and SPF, DKIM and a DMARC record from bulk senders.
Does reverse DNS matter for e-mail?
For the servers that send your mail, yes. Many receivers check that the connecting address has a PTR record and that the name in it resolves back to the same address (forward-confirmed reverse DNS), and reject or junk mail that fails. The PTR record is set by whoever holds the address block; on a VMHeaven server you set it yourself in the control panel. This report shows it for the MX hosts, which on a self-hosted setup usually send the mail too.
Why does the check not test SMTP or port 25?
It works from DNS alone, so it can be run against any domain without touching its servers. Whether a mail server answers on port 25 can be tested with the open port checker — a plain TCP connection, nothing sent. Whether it then accepts a message is up to that server's own rules.
What should I fix first?
Anything marked as a problem: no SPF record or more than ten SPF lookups, a missing DMARC record, an MX host that does not resolve, a mail server on a blocklist. Warnings come next — a DMARC policy still at p=none, a 1024-bit DKIM key, missing reverse DNS. Each note says what it means and what to change, and the SPF, DKIM and DMARC checkers go through each record in detail.