Verify PTR records and forward-confirmed reverse DNS for any IP address. Essential for email deliverability.
Enter an IP address to look up its PTR record and verify forward-confirmed reverse DNS.
A PTR (Pointer) record maps an IP address to a hostname — the reverse of an A record. It is stored in a special DNS zone managed by whoever controls the IP address (usually your hosting provider or ISP). PTR records are essential for reverse DNS lookups, which mail servers use to verify the identity of sending servers.
Email servers routinely check PTR records to verify that the sending IP belongs to a legitimate mail server. Missing or mismatched PTR records are treated as a strong spam signal. Google and Yahoo require valid PTR records for all bulk senders as part of their 2024 email authentication requirements. Without a proper PTR record, your emails may be rejected or routed to spam.
FCrDNS is a two-step verification: first, the PTR record for an IP is looked up to find the hostname; then, an A record lookup on that hostname is performed to check if it resolves back to the original IP. When both match, it proves the IP and hostname genuinely belong together. This is considered a strong trust signal by mail servers and anti-spam systems.
PTR records are managed by your IP address provider, not your domain registrar. Contact your hosting provider or ISP and request a PTR record pointing your server's IP to a hostname you control (typically your mail server's hostname). After it's set, add a matching A record on your DNS to complete the forward-confirmed reverse DNS chain.
No. When you send through a shared provider, they own the sending IPs and manage the PTR records for you (that's why Google Workspace or Mailgun deliverability "just works"). You only need to check reverse DNS for an IP you control yourself — a self-hosted mail server, a VPS running Postfix, or an on-premise Exchange box. If you're not sure which IP is actually sending, check the Received: headers of a test message you sent, or use the sending IP shown in your provider's dashboard.
PTR records follow the TTL of the reverse zone, which is set by your IP provider — commonly anywhere from 5 minutes to 24 hours. Because you don't control that zone, you can't shorten the TTL yourself. After your provider confirms the change, re-run this checker periodically; once the old value expires from resolver caches worldwide, FCrDNS will verify.
Rarely, and that's the point. IPs on residential or dynamic ranges usually carry a generic ISP-assigned PTR (something like host-198-51-100-7.dynamic.example-isp.net) that doesn't match your mail hostname, so FCrDNS fails and most receivers reject the mail. Legitimate bulk sending needs a static IP with a PTR you can point at your own mail hostname — which is exactly what a dedicated sending IP or a reputable ESP provides.
Your IP has a PTR record, and the hostname it points to resolves back to the same IP. This is the two-way match mail servers look for on every inbound connection. No action needed — this IP will clear the reverse-DNS checks that Gmail, Yahoo, and most corporate mail gateways run.
A PTR record exists, but the hostname it returns doesn't resolve back to your IP, so forward-confirmed reverse DNS fails. The usual cause is a missing or wrong A record for your mail hostname, or a PTR still set to a generic ISP-owned name. Fix the A record so the hostname and IP agree in both directions, then re-check.
The IP has no reverse-DNS entry at all — the strongest negative signal of the three. Many mail servers reject connections from IPs with no PTR before your message is even accepted. Because PTR records live with whoever owns the IP block, you resolve this through your hosting provider or ISP, not your domain registrar.
MailOver, the AI email secretary, reads every email for you and surfaces only what matters.

