A reverse DNS lookup mail server check answers a basic but consequential question: does the public IP address that sends your business email identify itself with a real, matching hostname? If the answer is no, some receiving mail systems may treat your messages with more caution, reject a connection, or place delivery at greater risk.
The straight answer is this: every server that sends mail directly to the internet should have a valid reverse DNS record, commonly called a PTR record. That record should point back to a hostname you control, and that hostname should resolve forward to the same sending IP address. This is a small DNS setting with a large role in establishing a consistent sending identity.
What a reverse DNS lookup checks
DNS, or Domain Name System, is the internet's address book. A normal DNS lookup starts with a hostname, such as `mail.example.com`, and finds the Internet Protocol, or IP, address behind it. Reverse DNS does the opposite. It starts with an IP address and asks which hostname is assigned to it.
For mail servers, the answer usually comes from a PTR, or pointer, record. For example, a sending server using the IP address `203.0.113.25` might return `mail.example.com` when a recipient performs a reverse lookup.
This matters because recipient systems can compare several pieces of information during a Simple Mail Transfer Protocol, or SMTP, connection. SMTP is the protocol mail servers use to exchange email. They may look at the sending IP address, the PTR hostname assigned to that IP, and the hostname the server presents when it introduces itself. A sensible, consistent match supports trust. A missing or unrelated identity creates a question the recipient server must answer.
Reverse DNS is not an inbox-placement guarantee. It is a baseline technical expectation. A correct PTR record will not fix poor sender reputation, an authentication failure, or unwanted email. But a missing or incorrect record can create a preventable problem before those other factors are even considered.
Why mail server reverse DNS affects your business email
Most small and midsize businesses do not operate a mail server in a data center. They use a business email provider, a marketing platform, a customer relationship system, an appointment tool, or an application that sends invoices and notices. In many cases, the provider manages reverse DNS for its shared sending infrastructure.
The issue becomes more likely when you send from a dedicated IP, an office server, a cloud virtual machine, a firewall appliance, or a line-of-business application configured to relay mail directly. It also appears after a server migration, IP address change, or switch to a new internet provider.
When reverse DNS is absent or wrong, the business impact can be frustratingly vague. A message may bounce with a notice about a missing PTR record. Another recipient may accept it but apply stricter filtering. Your staff may see that one customer gets an invoice while another says it never arrived. The exact outcome depends on the recipient's policies, which vary by organization.
That is why reverse DNS should be treated as an operational check, not a one-time technical chore. If email supports sales conversations, legal notices, patient scheduling, service updates, or payment requests, the identity of your sending infrastructure needs to remain accurate.
The correct reverse DNS configuration
A working setup has three connected parts. First, the sending IP address has a PTR record. Second, that PTR record returns a real hostname. Third, a normal forward DNS lookup of that hostname returns the original IP address.
This third test is often called forward-confirmed reverse DNS. The name is technical, but the logic is simple: the two directions should agree.
Suppose your mail server sends from `203.0.113.25` and identifies itself as `smtp.example.com`. A sound configuration looks like this:
- A reverse lookup of `203.0.113.25` returns `smtp.example.com`.
- A normal lookup of `smtp.example.com` returns `203.0.113.25`.
- The mail server introduces itself during SMTP using `smtp.example.com` or another hostname that is valid and appropriately configured.
The hostname does not have to be your main website address. In fact, a dedicated host such as `mail.example.com` or `smtp.example.com` is usually clearer. What matters is that it is a valid hostname, resolves correctly, and is consistent with the server's identity.
Avoid setting the PTR record to a generic provider hostname if you are presenting your own hostname in SMTP. Also avoid pointing it to a bare domain, such as `example.com`, unless that exact domain has an address record pointing to the sending IP and your mail server is configured consistently. The cleanest approach is usually one IP, one mail hostname, and matching forward and reverse records.
How to run a reverse DNS lookup for a mail server
Start by identifying the public IP address that actually sends your email. This is not always the IP address of your office internet connection. If you use a hosted email service, your provider may send from its own infrastructure. If an application sends directly, it may use a cloud server or relay service with a separate IP.
You can often find the sending IP in the full headers of a message received outside your organization. Look through the delivery path for the server that made the outbound connection to the recipient. If you manage the server, your mail server settings or hosting dashboard may identify it directly.
Then check the IP address with a reverse DNS lookup. You are looking for a PTR response that provides a hostname rather than no response at all. Next, look up that hostname normally to confirm it leads back to the same IP address.
Do not stop at a pass-or-fail result. Compare the returned hostname with your server's configured greeting. If the server says `mail.example.com` but the PTR record returns an unrelated host, you have an identity mismatch worth correcting. If the sending service is fully managed, ask its support team whether it manages reverse DNS and whether a dedicated IP can have a custom PTR hostname.
Common reverse DNS lookup mail server failures
The most common failure is no PTR record. A reverse lookup returns nothing, or a generic error. This often happens because the server owner added a regular DNS record but did not realize reverse DNS is controlled elsewhere.
The second failure is a forward and reverse mismatch. The PTR record may return `mail.example.com`, but the address record for `mail.example.com` points to another IP. This can happen after an IP migration when one side of the configuration was updated and the other was missed.
A third problem is a generic PTR hostname, such as an automatically generated broadband or cloud-provider name, while the mail server identifies itself as your business domain. Some providers do not allow custom reverse DNS on every service. If that is your situation, sending through a properly configured mail relay may be more practical than sending directly from that IP.
Finally, a shared IP can limit what you can change. One IP address can have one PTR record. If a provider hosts many customers on the same IP, it cannot assign a different custom reverse record to each customer. That is normal for shared infrastructure, and the provider should manage the sending identity in a way that fits its service.
Who can make the exact fix
This is the part that surprises many teams: your DNS hosting account may not control reverse DNS. Standard DNS records for your domain are managed by your DNS provider. The PTR record is usually managed by the company that owns the IP address block, such as your internet provider, cloud host, server host, or email delivery provider.
If you own a dedicated IP, request that provider set its PTR record to your chosen mail hostname. Before making the request, create the matching forward address record for that hostname and confirm the mail server uses it. Give the provider the exact hostname and IP address. After the change is published, test both lookup directions again.
If you use Microsoft 365, Google Workspace, or another hosted email platform for ordinary employee mail, do not attempt to create a PTR record for the provider's shared IP addresses. The provider owns and manages those records. Focus instead on the systems that send as your domain outside the main mailbox platform, such as website forms, printers, accounting software, and servers.
If changing the PTR record requires access to an IP provider account, mail server configuration, or cloud networking controls you do not manage, this is a reasonable job for your IT team or a qualified administrator. The key is to make the changes as one coordinated identity update, not as isolated DNS edits.
A valid reverse DNS record gives your mail server a clear name to stand behind. Run MailArrive's free email health check and review the Report Card to see whether reverse DNS and other sending-domain signals need attention.