rDNS · FCrDNS
three-way verified.
Enter a sending IP. We check its reverse DNS (PTR record), then verify the hostname forward-resolves back to the same IP (Forward-Confirmed reverse DNS) and flag any mismatch. Most deliverability problems trace back to broken FCrDNS.
# Awaiting input…
Three checks. Production sending requires all three.
PTR exists
The IP must reverse-resolve to a hostname. Generic provider
hostnames (static.185.10.20.30.provider.com) are
technically valid but signal "unmanaged infrastructure" to receivers.
Forward A matches
The hostname returned by PTR must have an A record (or AAAA for IPv6) pointing to the same IP. Forward-Confirmed reverse DNS. Without this, receivers downgrade trust significantly.
Custom hostname
The hostname should be under your sending domain
(mail.example.com), not generic provider naming.
Receivers treat custom rDNS as a quality signal.
Hard rejection at some receivers
Corporate Exchange, Proofpoint, Mimecast, and similar enterprise filters reject outright on FCrDNS failure. Consumer Gmail/Outlook downgrade rather than reject, but inbox placement suffers.
EHLO must match rDNS
Beyond FCrDNS, your MTA's HELO/EHLO command must declare the same hostname as the rDNS. Mismatch is its own reputation hit, even with FCrDNS otherwise valid.
Provider control panel
Most hosting providers offer rDNS configuration in their control panel (often labelled "Reverse DNS" or "PTR record"). Forward A records live in your domain's authoritative DNS.
Custom rDNS is non-negotiable for production sending.
Every IP we provision comes with custom rDNS aligned to a hostname under your sending domain, FCrDNS verified before handover. If your current provider doesn't support this, that's a structural problem and a reason to move infrastructure.
Three checks happen in sequence; failure at any step is a problem.
rDNS (reverse DNS) maps an IP address back to a hostname. For sending mail, receivers do more than just rDNS lookup; they perform FCrDNS (Forward-Confirmed reverse DNS), which requires three things: the IP has a PTR record, the PTR hostname has a forward A record, and the forward A record resolves back to the original IP. The validator runs all three checks and tells you which (if any) failed.
Step 1: PTR record exists for the IP
Reverse DNS lookup against your sending IP must return a PTR record with a hostname. If no PTR exists, receivers treat the IP as unconfigured and most major receivers (Gmail, Outlook, Yahoo) will reject mail outright with 5xx responses citing missing rDNS. PTR records are configured at your hosting provider, not in your own DNS; most providers offer a control panel option, but some require support tickets.
Step 2: PTR hostname has a forward A record
The hostname returned by reverse lookup must itself
resolve in forward DNS. If your IP's PTR is
mail.yourdomain.com but
mail.yourdomain.com doesn't have an A record,
the FCrDNS check fails. Common cause: PTR was set to a
hostname during early infrastructure deployment, but the
forward A record was never published or was removed
during DNS reorganization.
Step 3: Forward A record matches the original IP
The A record for the PTR hostname must resolve back to
the IP that started the chain. mail.yourdomain.com
→ 192.0.2.50 must equal the IP whose PTR you
looked up (192.0.2.50). If mail.yourdomain.com
resolves to 192.0.2.99, FCrDNS fails because
the forward record points elsewhere. Most common cause:
IP migration where PTR was updated but A record wasn't
(or vice versa).
Generic vs branded PTR hostnames
A PTR like vps-12345.provider.net is
generic; mail.yourbrand.com is branded.
Both pass FCrDNS if configured correctly, but receivers
treat them differently. Generic provider PTRs are
associated with shared/transient infrastructure and
receive lower trust scoring. Branded PTRs aligned to
your sending domain receive higher trust. We strongly
recommend custom rDNS aligned to your brand for
production sending; the difference in inbox placement
is measurable.
What we see most often when checking sending IPs.
No PTR record at all
Reverse lookup returns NXDOMAIN. Major receivers reject with 5xx errors immediately; mail doesn't reach the inbox layer at all. Fix: contact your hosting provider to set PTR. Most providers offer a self-service option in their control panel; some require support ticket. Set the PTR to a hostname under a domain you control, not the provider's generic format.
PTR set but forward record missing
192.0.2.50 reverse-resolves to
mail.yourdomain.com, but
mail.yourdomain.com has no A record.
FCrDNS fails. Fix: publish A record for
mail.yourdomain.com in your authoritative
DNS pointing to 192.0.2.50.
Forward A record doesn't match originating IP
PTR 192.0.2.50 → mail.yourdomain.com, but
mail.yourdomain.com A record is
192.0.2.99. FCrDNS fails because the
forward chain doesn't return to the original IP. Fix:
either update PTR to point to a hostname that resolves
back to 192.0.2.50, or update A record
for the existing hostname to point to 192.0.2.50.
Generic provider PTR (vps-XX.provider.net)
FCrDNS passes but the hostname is provider-generic rather than aligned to your sending domain. Lower trust scoring at receivers; potentially flagged in some receiver databases as transient/shared infrastructure. Fix: configure custom rDNS aligned to your sending domain. Our Custom rDNS service handles this end-to-end if your hosting provider doesn't support self-service.
PTR points to host on a different domain than sender
Sending mail from @yourdomain.com but PTR
is mail.unrelateddomain.net. Not
technically wrong but creates confusion in some
receiver heuristics about which entity owns the IP.
Fix: align PTR with your primary sending domain;
consistent branding across IP, sending domain, and
return-path improves trust scoring.
IPv6 has no PTR even though IPv4 does
Common when IPv6 was added to infrastructure but rDNS wasn't configured for v6. Modern receivers increasingly check v6 rDNS for dual-stack senders. Fix: set PTR for v6 address through your hosting provider; ensure forward AAAA record matches.
How major receivers weight reverse DNS in 2026.
Receiver-side weighting on reverse DNS has tightened materially through 2024-2026. The general direction is that receivers increasingly treat missing or broken reverse DNS as a reason to apply additional scrutiny rather than a soft signal that other strong indicators can overcome. The specific behaviour varies by receiver but the pattern is consistent across major providers.
Gmail: Reverse DNS is checked at SMTP
connection time. Missing PTR record produces a soft
warning that combines with other signals to determine
placement. Mismatched FCrDNS (PTR exists but forward
A record does not point back to the same IP) produces
stronger negative signal that survives even good content
and authentication signals. Generic PTR records (the
ISP-assigned reverse DNS like
185-12-34-56.example-isp.net) produce
moderate negative signal compared to brand-aligned PTR.
Microsoft 365 and consumer Outlook: Reverse DNS validity is a baseline requirement. Connections from IPs with no PTR or broken FCrDNS often get rejected at SMTP time with 550-5.7.1 or similar codes, bypassing the content evaluation entirely. The enforcement is consistent across both Outlook consumer and Microsoft 365 commercial properties as of mid-2025.
Corporate email security gateways: Mimecast, Proofpoint, Barracuda, and Cisco IronPort all check reverse DNS at connection time. Most apply stricter rules than mainstream consumer providers: generic PTR (especially ISP-formatted hostnames) triggers quarantine or rejection independent of other signals. Senders targeting business audiences who route through corporate gateways need brand-aligned PTR records on every sending IP without exception.
Yahoo, AOL, ProtonMail: All check reverse DNS at connection time with behaviour similar to Gmail. Yahoo specifically is known to apply harsher treatment to senders without PTR than Gmail does; Yahoo placement for senders with missing reverse DNS frequently lands in spam folder even with otherwise-clean reputation.
The operational steps to fix broken FCrDNS.
Reverse DNS records live in the IP allocator infrastructure, not in your domain DNS. This means the procedure for fixing reverse DNS depends on who owns the IP space. The pattern below covers the three common ownership scenarios.
Hosting provider owns the IP: open a
support request with the provider asking them to set
the PTR record for your IP to your chosen hostname.
Most professional providers have a self-service interface
for this in their control panel; if not, an email or
ticket request typically completes within hours to days.
Specify the exact hostname you want set (something like
mail01.yourdomain.com) and confirm that the
provider has actually made the change by querying the
PTR with dig -x your.ip.address after they
acknowledge.
You own the IP range: the PTR records
live in the reverse DNS zone for your IP range, typically
configured through your DNS provider or your own
authoritative DNS infrastructure. For IPv4, the reverse
zone is structured as
56.34.12.185.in-addr.arpa for IP
185.12.34.56 (reversed octets). For IPv6,
the zone structure is nibble-reversed under
ip6.arpa. The RIR (RIPE, ARIN, APNIC,
LACNIC, AFRINIC) that allocated the range needs to
delegate the reverse zone to your nameservers; this is
a one-time setup that your IP-range purchase
documentation should reference.
Shared IP on managed infrastructure: some shared-IP scenarios (especially on smaller cloud providers or shared hosting) do not offer customer- configurable PTR. In these cases the provider sets a generic PTR that is not brand-aligned. The only fix is either migrating to a dedicated IP with customisable PTR or accepting the deliverability penalty. For sending workloads above 50K monthly volume the structural correct answer is dedicated IP; the cost differential is typically less than the lost revenue from suppressed inbox placement on generic-PTR shared IPs.
After setting the PTR record, complete the FCrDNS by
ensuring the hostname forward-resolves back to the
same IP. This is configured in your domain DNS as a
standard A record (or AAAA for IPv6):
mail01 IN A 185.12.34.56. Verify both
directions resolve cleanly using the tester on this
page. Propagation typically completes within 1-24
hours depending on DNS caching policies; allow up to
48 hours before assuming the change has not taken
effect.
Frequently asked.
Why does rDNS matter for mail but not web?
Web traffic doesn't generally consult rDNS; the client-server model uses forward DNS to find the server. Mail's anti-abuse model uses rDNS as one of several signals confirming the sending IP is operated by an organization rather than by transient/shared infrastructure. Bulk-mail senders almost always have proper rDNS; spam-abuse from compromised hosts often doesn't.
Can I set rDNS in my own DNS server?
No. rDNS uses the in-addr.arpa namespace
(or ip6.arpa for IPv6), which is delegated
from regional internet registries down to network
operators. The IP block owner controls rDNS. As an end
customer, you set rDNS through your hosting provider.
Some providers offer DNS delegation that lets you
manage rDNS for your assigned IPs from your own DNS,
but that requires explicit configuration on the
provider side.
How long do PTR changes take to propagate?
Typically same-day to 24 hours for the change to be visible globally. PTR records have their own TTL (often shorter than forward records, 300-3600 seconds common). Some receivers cache rDNS results for longer than the TTL suggests; effective propagation can take 48-72 hours for full stabilization.
Do all my sending IPs need different PTRs?
They should be unique enough to identify the IP
specifically. Common patterns: mail1.yourdomain.com,
mail2.yourdomain.com, etc., with each
pointing to its specific IP via A record. Some
operations use the same PTR hostname for all IPs in
a pool; this works mechanically but loses the ability
to identify specific IPs in receiver feedback.
What if my hosting provider can't set PTR?
Switch providers. Inability to set PTR is a disqualifying constraint for production mail sending. All reputable hosting providers support PTR configuration; if yours doesn't, you've found a sign that the provider isn't designed for serious mail operations. We provision sending infrastructure with PTR self-service available; consult our SMTP Relay tiers if you need a provider that handles this properly.
Should rDNS match HELO?
Yes, ideally. The HELO/EHLO command in SMTP advertises
the sending host's name; receivers compare HELO with
rDNS as another consistency check. If your MTA's HELO
says mail.yourdomain.com and rDNS confirms
the IP resolves to mail.yourdomain.com,
consistency adds trust. Mismatch isn't always a
failure but is worth aligning during configuration.