PTR records (reverse DNS) map an IP address back to a hostname. For mail servers, valid PTR is essential to deliverability — receivers often reject or heavily penalise mail from IPs without correct reverse DNS. This article explains PTR records, Forward-Confirmed Reverse DNS (FCrDNS), how UK businesses configure PTR with their hosting provider, and why it matters so much for email.
A PTR (Pointer) record is a DNS record that maps an IP address to a hostname. It is the reverse of an A record: where A maps mail.firm.co.uk to 203.0.113.25, PTR maps 203.0.113.25 back to mail.firm.co.uk.
PTR records live in special zones under in-addr.arpa (for IPv4) or ip6.arpa (for IPv6). They are managed by whoever controls the IP block — usually the ISP, hosting provider, or cloud infrastructure owner, not the domain owner.
For an IPv4 address, the PTR lookup reverses the octets and appends in-addr.arpa:
203.0.113.25 → 25.113.0.203.in-addr.arpaThe PTR record at that name is:
25.113.0.203.in-addr.arpa. IN PTR mail.firm.co.uk.For IPv6, the address is reversed nibble-by-nibble under ip6.arpa:
2001:db8::25 → 5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpaFCrDNS is a consistency check that combines PTR and A records. For a sending IP to "pass FCrDNS":
If yes: FCrDNS passes. If no: FCrDNS fails.
FCrDNS is a basic but powerful sanity check. Legitimate mail servers have consistent forward and reverse DNS. Spam operators often have PTR pointing at one thing and A records at something else, or no PTR at all.
Example passing FCrDNS for epost.plus:
217.149.241.18 → mail.epost.plus (PTR)
mail.epost.plus → 217.149.241.18 (A)
Match: FCrDNS pass.Every major mail receiver checks PTR — and many reject or heavily penalise mail from IPs with missing, mismatched or generic PTR. Common receiver behaviours:
ptr-203-0-113-25.broadband.example.net is almost as bad as missing PTR — indicates residential or dynamic infrastructure.For a UK business, publishing PTR on your mail sending IP is essential. Skip this, and outbound mail deliverability suffers regardless of SPF, DKIM or DMARC configuration.
Unlike forward DNS (A, MX, etc.) which you control via your domain's DNS host, PTR records live in the in-addr.arpa zone. The owner of the IP block manages them:
For hosted mail platforms like SmartXHosting, the platform manages PTR for its sending IPs.
| Provider | PTR configuration |
|---|---|
| SmartXHosting | Managed — customers on email plans use the platform's authorised sending IPs with correct PTR |
| AWS EC2 | Request PTR via console; requires account verification and delay |
| Google Cloud | Configurable per instance via console |
| Microsoft Azure | Configurable per public IP resource |
| Linode / Akamai Cloud | Configurable via user portal |
| Hetzner | Configurable via Robot portal |
| OVH | Configurable via manager interface |
| Dedicated UK providers (UK-Dedicated, Fasthosts) | Contact support to configure |
| BT Business broadband | PTR requests via BT technical support; typically days to process |
| Residential broadband | Usually not available; use managed mail service instead |
General process for a UK mail server on a dedicated or cloud IP:
mail.firm.co.uk.mail.firm.co.uk → 203.0.113.25.203.0.113.25 to mail.firm.co.uk.dig -x 203.0.113.25 and confirm the returned hostname resolves back to the same IP.# Query PTR
dig -x 203.0.113.25
# Expected:
# 25.113.0.203.in-addr.arpa. 3600 IN PTR mail.firm.co.uk.
# Resolve forward
dig A mail.firm.co.uk
# Expected:
# mail.firm.co.uk. 3600 IN A 203.0.113.25
# FCrDNS passes if the original IP matches the forward resolution.Automated check:
host 203.0.113.25 | grep "pointer"
# Returns hostname; check forward against original IP.Online tools like MXToolbox's Reverse Lookup, IPVoid, and Email Blacklist Check also verify PTR and flag issues.
PTR for IPv6 follows the same principle but with the complex ip6.arpa naming. Many UK hosting providers auto-generate a PTR for IPv6 based on the IP itself (ugly hostname like 18.241.149.217.in-addr.arpa) or require manual configuration to produce a meaningful mail-server hostname.
For dual-stack mail servers sending over both IPv4 and IPv6:
Gmail in particular is strict about IPv6 PTR — mail from IPv6 sources without proper PTR is routinely refused. If you run a UK mail server that may send over IPv6, ensure both PTR records are correct.
Reverse DNS and FCrDNS were part of the original DNS design in the 1980s. Their use in email predates SPF, DKIM, DMARC — receivers were checking PTR consistency long before modern authentication protocols existed. In the early anti-spam era (2000s), missing PTR became a near-universal rejection trigger. Modern authentication adds layers on top; PTR remains the baseline.
Today, receivers treat PTR as table stakes. A mail server without PTR in 2026 is treated almost the same as one sending from an obvious residential broadband line — heavy penalty regardless of SPF/DKIM/DMARC.
Q: Can I set PTR for my domain myself?
A: No — PTR lives in the in-addr.arpa zone owned by the IP block owner. You request from the IP owner (hosting provider, ISP).
Q: What happens if my mail IP has no PTR?
A: Most major receivers reject or heavily penalise. Gmail: typically rejects. Outlook.com: high spam score. UK business receivers: varies, but negative impact on deliverability is universal.
Q: What happens if my PTR points at a different hostname than my forward DNS?
A: FCrDNS fails. Receivers treat this similarly to missing PTR — heavy penalty. Ensure PTR and A records match.
Q: Does my mail server need PTR for outbound or inbound?
A: PTR is checked by receivers when your server connects to them (outbound from your server's perspective). Inbound mail to you is unaffected by your PTR.
Q: Can I use a generic hostname in PTR?
A: Technically yes but not recommended. Generic hostnames (cloud provider's default) are often penalised. Use a custom hostname within your domain: mail.firm.co.uk.
Q: How long does PTR propagation take?
A: Same as normal DNS — depends on TTL of the reverse zone. Typically 1-24 hours. Cached entries at resolvers persist until their TTL expires.
Q: Is PTR visible publicly?
A: Yes. Anyone can query PTR for any IP. There is no privacy mechanism — PTR is designed to be public.
Q: What if my ISP refuses to configure PTR?
A: For mail use, switch to a provider that supports PTR configuration. Most UK business ISPs (BT Business, Zen Internet, Exascale) support PTR on request; cheap consumer ISPs often do not.
Q: Can I have multiple PTR records for one IP?
A: Technically yes but strongly discouraged. Creates ambiguity. Stick to one PTR per IP.
Q: Does CDN-fronted mail need PTR for the CDN IPs?
A: CDNs rarely front mail (CDNs are for HTTP). If they did, the CDN's IP PTR would need to be configured by the CDN provider. Unusual scenario.
Q: Do mail receivers check PTR at SMTP connection time or later?
A: Typically at connection time — before or during the SMTP greeting. Some receivers delay the check until DATA phase. Either way, the result affects deliverability.
Q: Does publishing PTR require DNSSEC on the reverse zone?
A: Optional — the reverse zone can be DNSSEC-signed if the IP block owner supports it. DNSSEC on reverse DNS is less common than on forward DNS but growing.
Q: What is the "HELO matches reverse DNS" check?
A: Some receivers compare the SMTP HELO hostname against the PTR. If they match, positive signal. If HELO is server.firm.co.uk and PTR is mail.firm.co.uk, mismatch — negative signal. Configure HELO to match PTR hostname.
Q: Can multiple mail IPs share one PTR hostname?
A: Not cleanly — each IP has one PTR. For load-balanced deployments where multiple IPs all represent "the mail server", each IP should have PTR to the same logical hostname. Forward DNS can have multiple A records for that hostname covering all IPs.
Q: Is PTR relevant for internal-only mail servers?
A: Only for outbound external mail. Purely internal servers (within your corporate network) do not need publicly-visible PTR.
Q: What UK regulations reference PTR?
A: No specific regulation, but NCSC guidance and good-practice frameworks assume mail servers have correct PTR. Compliance audits may note missing PTR as a deliverability risk.
Q: Can PTR be used for security (e.g. verifying a client is really who they claim)?
A: Weakly — PTR is not secure in a cryptographic sense (can be faked with DNS compromise). Use PTR as a hygiene signal, not as a security control.
Q: Does UK GDPR affect PTR publication?
A: PTR is infrastructure metadata, not personal data. No GDPR implications for PTR publication itself.
Q: How often should I verify my PTR is still correct?
A: Quarterly check is sufficient for stable mail servers. After any infrastructure change (new IP, server replacement), verify immediately.
Q: What happens to PTR when I migrate mail servers to a new IP?
A: Old IP's PTR becomes stale (unless re-configured for the new tenant). New IP needs PTR configured for your mail hostname. Coordinate the migration with your hosting provider.
Q: Are there UK services that check PTR health for mail infrastructure?
A: Mail Hardener, Hardenize, NCSC Mail Check all include PTR as part of their broader checks. Most commercial email monitoring services flag PTR issues automatically.
Q: Does PTR matter for DKIM or SPF validation?
A: Not directly — SPF and DKIM operate on different DNS records. Indirectly, a missing PTR drops your reputation enough that receivers penalise the whole message regardless of SPF/DKIM status.
Q: How is PTR different from an A record?
A: A records map hostnames to IPs (forward). PTR maps IPs to hostnames (reverse). Both live in DNS but in different zones and are managed by different parties (domain owner vs IP block owner).
Q: Can I request PTR for a shared hosting IP?
A: Only the IP block owner can set PTR. Shared hosting providers usually set PTR to their own hostnames (e.g. shared-server-42.provider.net). You cannot customise. For custom-PTR mail, use a dedicated IP.
Q: What is the difference between PTR and HELO?
A: PTR is a DNS record; HELO is the hostname announced by the sending server at SMTP start. They should match for optimal reputation. HELO is under your mail server's control; PTR is under the IP owner's.
Q: Does IPv6 PTR have any UK-specific considerations?
A: UK ISPs and cloud providers vary in IPv6 PTR support. Check explicitly when deploying IPv6 for mail. Many UK providers still have patchier IPv6 operations than IPv4.
Q: Is PTR relevant for outbound-only mail relays with no inbound?
A: Yes — PTR is checked on the outbound connection by the receiving server. Outbound-only relays still need correct PTR.
Q: What happens if my PTR hostname has a typo or incorrect format?
A: Receivers perform forward resolution. If the hostname does not resolve or resolves to a different IP, FCrDNS fails. Penalty applies.
Q: Are UK banks typically strict about PTR on outbound mail?
A: Yes. UK banks and financial institutions with strict deliverability requirements configure PTR carefully on all mail sending infrastructure. Compliance audits flag missing PTR.
Q: Can Cloudflare manage PTR records for me?
A: No — Cloudflare manages forward DNS only. For PTR, contact the IP block owner (typically cloud provider or ISP). Cloudflare does not own IP blocks for email.
Q: Does delegating an in-addr.arpa zone to my own nameservers give me direct PTR control?
A: Yes, if your IP block is large enough to justify delegation (a /24 or larger in IPv4). Most UK businesses do not have blocks large enough for this.
Q: What is the impact of PTR on email reputation for UK mail with low volume?
A: Proportionally large. A sole trader sending a few emails per day with correct PTR has dramatically better deliverability than one with missing PTR. Low volume means every signal matters more.
Q: How does PTR interact with RBL listings?
A: RBLs may include your IP if PTR is missing or generic. Some RBLs specifically target IPs without valid PTR. Clean PTR is prerequisite for clean RBL status.
Q: Can I check PTR status for an IP that is not mine?
A: Yes. dig -x 8.8.8.8 works for any IP. Useful for verifying upstream mail sender infrastructure.
Q: Is there ever a scenario where not publishing PTR is correct?
A: Essentially no for mail infrastructure. For other services (web servers, APIs) PTR is less critical but still good practice.
Q: How do I handle PTR if my mail provider uses anycast IPs?
A: The provider manages PTR across their anycast footprint. You rely on the provider's infrastructure. For SmartXHosting-hosted mail, PTR is managed for you.
Q: Does mail forwarding affect PTR checks?
A: The forwarder's IP is checked for PTR at the next hop. Each hop independently. Good PTR on your own mail server does not help if a downstream forwarder has bad PTR.
Q: How do spam filters weight PTR in 2026?
A: Heavily. PTR is one of the oldest signals but remains one of the most reliable. Weight has not diminished despite newer authentication protocols.
Q: Can PTR be used for geolocation?
A: Weakly — PTR hostnames sometimes include geographic hints. Not reliable for accurate geolocation; IP geolocation services do a better job.
Q: What happens to PTR during a cloud provider's IP rotation?
A: If the cloud provider changes the underlying IP (unusual — IPs are usually stable with assigned resources), PTR on the old IP becomes stale. The provider's management should reassign PTR to the new IP; verify after any infrastructure change.
Q: Can NCSC Mail Check tell me whether my PTR is set correctly?
A: Yes for UK public sector accredited domains. The service checks PTR alongside other email security records. For private sector, Hardenize and similar provide equivalent checks.