Reverse DNS for email
Reverse DNS maps an IP address back to a hostname. For email, this mapping — stored in a PTR record — is one of several signals that receiving mail servers use to evaluate whether an incoming connection is trustworthy.
What is reverse DNS for email?
When a mail server receives an incoming SMTP connection, it can look up the connecting IP address in reverse DNS to find an associated hostname. This is the opposite of a normal DNS lookup: instead of asking "what IP does this hostname resolve to?", it asks "what hostname is associated with this IP?"
The result is returned by a PTR record — a DNS record type specifically designed for reverse lookups.
Many receiving servers perform this reverse DNS lookup as part of their spam filtering process. A sending IP with no PTR record, or one that resolves to a generic hostname, can look more suspicious than one with a meaningful, correctly configured hostname.
What is a PTR record?
A PTR (pointer) record is a DNS record that maps an IP address to a hostname. PTR records live in a special DNS zone based on the IP address — for IPv4 addresses, under the in-addr.arpa domain.
Unlike most DNS records, PTR records are not managed in your normal domain registrar or DNS hosting panel. They are controlled by whoever owns the IP address — typically a hosting provider, VPS provider, or internet service provider.
To set or change a PTR record for a sending IP, you usually need to contact the hosting or network provider responsible for that IP block and request the change, or use the provider's control panel if they offer self-service PTR management.
Why PTR records affect deliverability
Receiving mail servers use PTR records as a trust signal. A sending IP with no PTR record, or one resolving to a generic name like "ip-192-0-2-1.provider.example", is treated with more suspicion than one resolving to a meaningful mail server hostname.
Many spam filters use missing or generic PTR records to increase the spam score of incoming mail. While a missing PTR rarely causes outright rejection on its own, it is a consistent negative signal that compounds with other deliverability issues.
PTR records are especially important for dedicated sending IPs and self-hosted mail servers. Senders using reputable ESPs typically have PTR records handled automatically by the provider.
Forward-confirmed reverse DNS
A PTR record alone is not sufficient — it should be accompanied by a matching forward DNS record. This is called forward-confirmed reverse DNS (FCrDNS).
FCrDNS works as follows: the PTR record for the sending IP resolves to a hostname, and that hostname in turn resolves back to the same IP address via an A or AAAA record. Both lookups must agree.
FCrDNS is a stronger trust signal than a PTR record alone. Some receiving servers check for it explicitly. If the PTR resolves to a hostname but that hostname does not resolve back to the original IP, the configuration is considered incomplete or suspicious.
PTR, HELO, and mail server hostname alignment
When an SMTP connection is established, the sending server announces its identity using the HELO or EHLO command, providing a hostname.
Best practice is for the HELO/EHLO hostname to match the PTR record of the sending IP. Mismatches between the HELO hostname and the PTR result — or between either and the forward DNS record — are a common cause of elevated spam scores.
A well-configured sending server should have:
- A PTR record for its sending IP pointing to a meaningful hostname
- That hostname forward-resolving back to the same IP
- The HELO/EHLO hostname matching the PTR hostname
Reverse DNS vs SPF, DKIM, and DMARC
Reverse DNS and PTR records are not a replacement for SPF, DKIM, and DMARC. They operate at different layers.
PTR records are an IP-level trust signal evaluated at connection time, before message content is even received. They help receivers decide whether to accept the connection from that IP at all.
SPF, DKIM, and DMARC are message-level authentication standards. They verify the identity of the sending domain and whether the message was sent by an authorised server and has not been tampered with in transit.
A complete configuration requires both: correct PTR/HELO alignment for the sending IP, and valid SPF, DKIM, and DMARC records for the sending domain. Neither substitutes for the other.
Common reverse DNS mistakes
Missing PTR record. The sending IP has no reverse DNS entry at all. This is the most common problem on self-hosted or newly provisioned servers.
Generic PTR hostname. The PTR record exists but resolves to a default name generated by the hosting provider — such as an IP-based hostname or a server ID. These carry no meaningful identity and are treated similarly to a missing PTR by many filters.
PTR points to a domain-less hostname. A PTR that resolves to a bare hostname without a domain (e.g. "mailserver" rather than "mail.example.com") is not a valid mail server identity.
No forward confirmation. The PTR hostname exists but does not resolve back to the sending IP, breaking FCrDNS.
HELO mismatch. The HELO/EHLO hostname differs from the PTR hostname, creating an inconsistent server identity.
How to fix reverse DNS problems
Identify your sending IP. Confirm which IP address your mail server uses to establish outbound SMTP connections.
Contact your hosting or network provider. PTR records are set by the IP owner, not by your domain registrar. Ask your VPS, dedicated server, or email hosting provider to set the PTR record for your sending IP to a meaningful hostname — typically "mail.yourdomain.com" or similar.
Create a matching forward DNS record. Add an A or AAAA record for the PTR hostname pointing back to the sending IP.
Align your HELO/EHLO hostname. Configure your mail server software to use the same hostname in its HELO/EHLO greeting as the PTR hostname.
Verify the full chain. After changes propagate, confirm that the PTR resolves to the hostname, the hostname resolves back to the IP, and the HELO hostname matches. Also verify SMTP TLS is correctly configured on the server.
How MXFend can help check related signals
MXFend provides tools that surface the signals most closely related to IP and server configuration:
SMTP TLS Checker — verifies STARTTLS support, TLS certificate validity, and cipher configuration for your mail server. Also surfaces HELO hostname and connection-level details.
Blacklist Checker — tests your sending IP against major DNS blacklists. A sending IP with PTR configuration problems may also be blacklisted.
Email Security Score — a comprehensive audit covering SPF, DKIM, DMARC, MX, blacklists, SMTP TLS, and related signals in a single report.
SPF, DKIM, and DMARC Checkers — verify the domain-level authentication records that work alongside PTR to establish a complete sending identity.
Frequently asked questions
What is reverse DNS in email?
Reverse DNS in email is the process of looking up the hostname associated with a sending IP address using a PTR record. Receiving mail servers use this lookup as a trust signal when evaluating incoming SMTP connections.
Do I need a PTR record to send email?
A PTR record is not universally required, but its absence is a negative signal for many receiving servers. A sending IP without a meaningful PTR record is treated as less trustworthy, which can increase spam placement risk — especially for self-hosted mail servers and dedicated sending IPs.
Who controls my PTR record?
PTR records are controlled by the owner of the IP address, not by your domain registrar or DNS hosting provider. For most senders, this means contacting the VPS, dedicated server, or hosting provider assigned the IP block and requesting a PTR change, or using their control panel if they offer self-service PTR management.
Should PTR match my HELO hostname?
Yes. The HELO or EHLO hostname used by your mail server should match the hostname returned by the PTR record for your sending IP. Mismatches between the two create an inconsistent server identity and are a common cause of elevated spam scores.
Does reverse DNS fix emails going to spam?
Correct PTR configuration removes one negative signal, but it does not guarantee inbox placement on its own. Spam placement is usually caused by a combination of factors including authentication records (SPF, DKIM, DMARC), sender reputation, blacklist status, and content quality. Fixing PTR should be done alongside checking all other deliverability signals.