Reverse DNS check for mail servers
Looks up up to five MX hosts, their IPv4 and IPv6 addresses (at most ten), the PTR record of each address and whether a PTR name resolves back to the same address.
Updated 2026-10-25
What this tool checks
Receiving mail servers often look up the reverse DNS of the address that connects to them. Many reject mail from an address without a PTR record, or treat it as more likely to be spam, and some also require the name to resolve back to the address.
The check starts from the domain's MX records:
- It takes up to 5 MX hosts, best preference first.
- For each host it resolves up to 2 IPv4 and 2 IPv6 addresses, at most 10 addresses in total.
- For each address it looks up the PTR record in
in-addr.arpaorip6.arpa. - For each PTR name it looks up the A or AAAA record and checks whether the original address is among them. Up to two PTR names per address are tried.
The evidence shows the MX host, the address and the PTR name for each finding.
How to read the result
PTR_MISSING: the address has no reverse DNS at all. This is the most common reason for rejections based on reverse DNS.PTR_NOT_FORWARD_CONFIRMED: there is a PTR name, but it does not resolve back to the address. Often the name was set once and the address changed later, or the name was never published.PTR_MULTIPLE_RECORDS: information only.PTR_NO_MAIL_HOSTS: the domain has no MX hosts, or a null MX, so there is nothing to check.
A PTR name does not have to be in your own domain. A provider name such as mail-1.provider.example is fine as long as it resolves back.
The MX guide explains how mail servers are found in the first place.
Limitations
- Only MX hosts are checked. Servers that only send, such as a newsletter service, are not visible in DNS and are not covered.
- The check does not connect to the servers, so it does not compare the PTR name with the name a server announces in its SMTP greeting.
- Hosts beyond the first 5, and addresses beyond the per-host limits, are not checked.
Use it from code
API reference for Reverse DNS check for mail servers
curl -i "https://api.probekit.dev/v1/mail/ptr?domain=example.com"A request without payment is answered with 402 Payment Required and the exact price. See the API reference.
Limits
| Input | Domain |
|---|---|
| Deadline | 10 seconds |
| Freshness | Up to 5 minutes, never longer than the record TTL |
| Price | $0.01 per check |
Findings this tool can report
Reverse DNS (4)
- Warning
PTR_MISSINGA mail server address has no PTR record. - Info
PTR_MULTIPLE_RECORDSA mail server address has more than one PTR record. - Warning
PTR_NOT_FORWARD_CONFIRMEDThe PTR name of a mail server address does not point back to it. - Info
PTR_NO_MAIL_HOSTSThe domain has no MX hosts whose reverse DNS could be checked.
Check (1)
- Warning
CHECK_QUERY_BUDGET_EXCEEDEDThe check stopped after reaching its DNS query limit.
DNS (3)
- Error
DNS_DOMAIN_NOT_FOUNDThe DNS resolver reported that the domain does not exist. - Warning
DNS_RESOLVER_FAILUREThe DNS resolver returned a server failure. - Warning
DNS_RESOLVER_TIMEOUTThe DNS resolver did not answer in time.
Frequently asked questions
What is forward-confirmed reverse DNS?
An address has forward-confirmed reverse DNS (FCrDNS) when its PTR record names a host, and that host name has an A or AAAA record pointing back to the same address. It shows that whoever controls the address and whoever controls the name agree. Many receiving servers check it before they accept mail.
Who sets the PTR record for my server?
Whoever owns the IP address range, usually your hosting or cloud provider or your internet provider. You cannot publish it in your own domain's zone. Most providers let you set it in their control panel or on request.
Why does the check look at MX hosts and not at my sending servers?
DNS does not say which servers send mail for a domain, only which servers receive it. MX hosts often send too, so they are the part that can be checked from DNS alone. If you send through other servers, their reverse DNS matters just as much.
Is more than one PTR record a problem?
It is allowed but often causes trouble, because some receivers only look at one of the names. The check reports it as information with PTR_MULTIPLE_RECORDS and still tries up to two of the names for forward confirmation.