Reverse DNS (PTR) for email
What is reverse DNS (PTR) for email?
Ordinary DNS translates a name into an IP address: you type in a domain, and DNS looks up which server is behind it. Reverse DNS does the opposite: it translates an IP address back into a name. That "reverse lookup" happens via a PTR record (pointer record) that belongs to the IP address.
For email this matters because, on arrival, the receiving server checks: the message comes from this IP address, and claims to come from this mail server; does that match what reverse DNS returns? If there's no PTR record, or it points to something random, an important piece of trust is missing. You'll find a more detailed conceptual explanation on the page about reverse DNS as a term.
Why reverse DNS makes or breaks your email
Strict receiving servers reject mail from IP addresses without a proper PTR record, or drop it into spam. For you that means: your messages don't arrive, for no clear reason. Especially at large mail providers, a matching reverse DNS has become a basic requirement.
The painful part is that you rarely have any visibility into this yourself. A PTR record doesn't belong to your domain DNS, but to the IP address, and that IP address is owned by whoever hosts the server. If you're on cheap, shared hosting where the reverse DNS isn't set up properly, your deliverability suffers, no matter how correctly you otherwise mail. It's exactly the kind of technical detail that lets mail fail silently.
For the persona this affects, an office manager or business owner who just wants mail to arrive, that's frustrating. You've done nothing wrong on your end, and yet messages disappear. Because there's rarely a clear error message, the problem stays unnoticed for a long time: you only find out when a client complains they received nothing. That makes reverse DNS one of the creeping causes behind poor delivery.
How it works
Picture a doorkeeper checking visitors at the door. Someone announces themselves with "I'm from company X". The doorkeeper calls company X's known number to check whether someone really is on their way to that address. If the story checks out, the visitor may enter. If it doesn't, or no one answers, the door stays shut.
Reverse DNS works the same way. When setting up the connection, your mail server states a name (the "HELO" name). The receiving server takes the IP address the message comes from and looks up via reverse DNS which name belongs to it.
- The sending server connects from a certain IP address.
- The recipient does a reverse DNS lookup on that IP address and reads the PTR record.
- Ideally that PTR record points to a proper server name, and that name in turn points back via ordinary DNS to the same IP address (a "forward-confirmed" match).
- If everything lines up, that counts as a positive signal. If the PTR record is missing or generic, trust drops.
Reverse DNS doesn't stand alone. It works together with authentication such as SPF, DKIM and DMARC. How those three interlock is covered in the guide on setting up SPF, DKIM and DMARC together.
What to watch out for
- You don't set a PTR record in your own domain DNS. It belongs to the IP address and is managed by the party that owns the server. If you search your DNS management in vain for the button, that's why.
- Generic reverse DNS doesn't count. A name like
host-84-12-x.pool.provider.netsays nothing; recipients prefer a name that clearly belongs to a real mail server. - Forward and reverse must match. If the reverse DNS points to a name that itself points back nowhere, the signal stays weak.
- On shared, cheap hosting you have no grip on it. You depend on how the hosting party has arranged it, and that's far from always proper.
Want to check for yourself how things stand? Then there are free online tools with which you look up an IP address and see which name the reverse DNS returns. If you get a generic name or nothing, that's a sign it's not set up well. You usually can't fix it yourself; that's up to the party that owns the server.
In short: reverse DNS is one of those invisible dials that can quietly undermine your deliverability. If your mail often ends up in spam, this check belongs in the list, together with the points in why your mail ends up in spam.
And at Mailflux
At Mailflux you don't have to fiddle with reverse DNS: we run the sending servers with a correct reverse DNS (PTR) and monitor their IP reputation. That way your messages carry the right signals from the start, without you having to hunt for buttons that don't exist in your own DNS anyway.
On top of that you get professional email on your own domain, hosted in Europe and GDPR compliant, with managed SPF, DKIM and DMARC, automatic backups and optional two-factor authentication. One clear price per mailbox, billed annually, without needless bells and whistles.
FAQ
Frequently asked questions
Can I set reverse DNS myself?
Usually not from your ordinary DNS management. A PTR record belongs to the IP address and is managed by the party that owns the server. With your own hosting you request it from your hosting party; with hosted email the provider arranges it for you.
What is the difference between a PTR record and an MX record?
An MX record tells the world which server mail for your domain should go to. A PTR record does the opposite: it links the IP address of the sending server back to a name, so the recipient can verify the sender. Both are needed for reliable delivery.
Does my mail end up in spam because of reverse DNS?
It can play a part. If a proper PTR record is missing or generic, strict recipients reject your mail or drop it into spam. It's rarely the only cause, but it is a basic requirement that's often forgotten on cheap hosting.