What is reverse DNS (rDNS) and FCrDNS, and how do they impact email sending?
Michael Ko
Co-founder & CEO, Suped
Published 9 Jul 2025
Updated 25 May 2026
12 min read
Summarize with
Reverse DNS, or rDNS, maps a sending IP address back to a hostname through a PTR record. FCrDNS, or forward-confirmed reverse DNS, means the hostname found in that PTR record also resolves forward to the same sending IP address. For email sending, the practical answer is simple: every real outbound mail server should have a non-generic PTR record, and that PTR hostname should pass forward confirmation.
If you send through a normal email service, CRM, or mailbox provider, the provider usually controls rDNS because it controls the sending IPs. If you run your own MTA, use cloud infrastructure, bring your own IPs, or send through a dedicated IP service, rDNS becomes your problem or a coordinated task with the IP owner. That distinction matters because many people try to fix rDNS in their normal DNS zone, then wonder why nothing changes.
The short answer
Reverse DNS starts with the sending IP address. A receiving mail server sees the IP that connects to it, looks for a PTR record for that IP, gets a hostname back, then checks whether that hostname looks credible. With FCrDNS, the receiving server also checks whether that hostname resolves forward to the same IP.
- rDNS: The IP address has a PTR record that returns a hostname, such as mail1.example.com.
- FCrDNS: The PTR hostname also has an A or AAAA record that points back to the same IP.
- Email impact: Receivers treat missing, generic, or mismatched rDNS as a sign of weak sending infrastructure.
- Owner: The IP address owner controls the PTR record, not whoever controls the sending domain's normal DNS zone.
Simple rDNS and FCrDNS exampletext
Sending IP: 203.0.113.25 Reverse lookup: 203.0.113.25 -> mail1.example.com Forward lookup: mail1.example.com -> 203.0.113.25 Result: FCrDNS passes
How rDNS works
Normal DNS answers a forward question: what IP address does this hostname use? Reverse DNS answers the opposite question: what hostname has been assigned to this IP address? Cloudflare has a useful reverse DNS explainer if you want the DNS-only version, but the email version has one extra practical layer: receiving mail systems care whether the reverse name looks like a real mail host.
A PTR record is not placed at mail1.example.com. It is placed in the reverse DNS zone for the IP address. For IPv4, that zone uses in-addr.arpa. For IPv6, it uses ip6.arpa. In practice, you rarely edit these zones directly unless you operate network infrastructure. Your hosting provider, cloud provider, ISP, or ESP normally owns the reverse zone.
Flowchart showing how a receiver checks a sending IP, PTR record, and forward DNS.
Forward DNS
- Question: What IP does this hostname use?
- Record: Usually A for IPv4 or AAAA for IPv6.
- Owner: The domain's DNS administrator.
Reverse DNS
- Question: What hostname has this IP been assigned?
- Record: PTR in the reverse DNS zone.
- Owner: The IP network owner or delegated provider.
What FCrDNS proves
FCrDNS proves consistency between the IP address and the hostname in reverse DNS. It does not prove brand identity, From-domain match, consent, list quality, or message legitimacy. It tells the receiver that the sender has control or cooperation over both sides of the infrastructure naming path.
Passing and failing FCrDNS patternstext
Pass: 203.0.113.25 -> mail1.example.com mail1.example.com -> 203.0.113.25 Fail: 203.0.113.25 -> mail1.example.com mail1.example.com -> 198.51.100.10 Weak: 203.0.113.25 -> host-203-0-113-25.provider.net host-203-0-113-25.provider.net -> 203.0.113.25
The weak example can technically forward-confirm, but it still looks generic. Some receivers treat generic-looking reverse names as a negative signal because they resemble default VPS names, consumer broadband pools, or temporary cloud nodes. A good mail server name should look deliberate and stable.
|
|
|
|---|---|---|
No PTR | The IP has no reverse name. | High rejection and filtering risk. |
Generic PTR | The name looks like a default host. | Suspicion, scoring, or blocklist risk. |
Mismatched | PTR and A do not confirm. | Filtering and troubleshooting noise. |
Confirmed | PTR and forward DNS match. | Baseline infrastructure trust. |
How common reverse DNS states affect email sending.
I treat FCrDNS as a minimum bar for direct sending. It will not make weak mail wanted, but failing it can make good mail look poorly operated before content or engagement even enter the picture.
How receivers use it
When your MTA connects to a receiver, the receiver sees the connecting IP immediately. It can run rDNS before accepting the full message body. It can also compare the PTR hostname with the HELO or EHLO name announced by your mail server. Those names do not always have to be identical everywhere, but they should make sense together and should not contradict the sending setup.
Generic hostnames are a real problem
A reverse name like dynamic-203-0-113-25.isp.example or compute-123-45.cloud.example tells receivers the IP probably has not been prepared for mail. Even if the name resolves forward, it can still look like a poor sending source.
rDNS also affects blacklist and blocklist handling. Some DNSBLs include checks for generic rDNS, missing PTR records, or sending behavior from infrastructure that resembles residential or temporary cloud space. If an IP is listed, the rDNS problem is not always the only cause, but it is one of the first infrastructure checks I would verify.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Suped surfaces rDNS alongside SPF, DKIM, DMARC, and related DNS diagnostics so the issue does not sit in a separate mental bucket. That matters when a deliverability problem mixes authentication failures with infrastructure signals. You can also use the domain health checker when you need a quick read on the DNS and authentication posture around a sending domain.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
The key caveat is that rDNS is IP-based. If your DMARC reports show a sender source you do not recognize, do not assume the rDNS alert is attached to your normal mailbox provider. First prove whether the IP appears in real message headers, DMARC aggregate data, or provider sending logs.
Who needs to configure it
The person who needs to act depends on how mail leaves your domain. This is where most confusion happens. Your public website DNS might be perfectly configured, while your sending IP has a PTR record owned by a cloud provider, mailbox provider, or ESP.
|
|
|
|---|---|---|
Shared ESP | The ESP | Ask support if alerts mention its IPs. |
Dedicated IP | Provider or you | Set a stable mail hostname. |
Own MTA | IP owner | Configure PTR, A, HELO, and TLS. |
Mailbox suite | Mailbox provider | Do not change PTR yourself. |
Cloud VM | Cloud provider | Avoid casual direct sending. |
Who handles rDNS for common email sending setups.
If you send through a provider and do not bring your own IPs, rDNS should not be a day-to-day concern. If a monitoring report says rDNS is failing for an IP you do not recognize, inspect a real message first. The IP must appear in the sending path before you spend time fixing it.
AWS Route 53 DNS records screen showing that normal DNS records differ from IP reverse DNS.
Do not chase the wrong DNS zone
If the sending IP is owned by another provider, adding a PTR-looking record under your own domain will not fix rDNS. You need the provider that controls the IP's reverse DNS delegation to set the PTR.
How to configure rDNS correctly
For direct sending, I like this order: choose the sending hostname, point it forward to the sending IP, ask the IP owner to point the PTR back to that hostname, then verify the full loop. Keep the hostname stable. Do not reuse your root domain as the mail server hostname.
- Pick a hostname: Use a real FQDN such as mail1.example.com or mta1.example.com.
- Create forward DNS: Publish an A or AAAA record from that hostname to the sending IP.
- Set the PTR: Ask the IP provider to map the IP back to the same hostname.
- Match HELO sensibly: Configure your MTA's HELO or EHLO name to be a stable hostname with DNS.
- Verify real mail: Send a message and inspect the connecting IP, authentication results, and headers.
Example DNS and MTA naming plantext
Hostname: mail1.example.com Forward DNS: mail1.example.com. 300 IN A 203.0.113.25 Reverse DNS requested from IP provider: 203.0.113.25 -> mail1.example.com MTA greeting: EHLO mail1.example.com
For multiple sending IPs, either give each IP its own hostname or use a naming pattern that stays clear and auditable. A common pattern is mail1, mail2, mail3, with each hostname resolving to the matching IP. Avoid many PTR records on one IP for outbound mail. Most receivers expect one clear reverse name.
Once the DNS is in place, send a real message to a test address and inspect the received headers. Suped's email tester is useful here because DNS checks alone do not prove which IP actually delivered the message.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
Common failure cases
Most rDNS problems fall into a few repeatable buckets. The fix is usually straightforward once you identify whether the IP is truly part of your sending path.
- Missing PTR: The IP has no reverse DNS. Ask the IP owner to add a PTR to your chosen mail hostname.
- Forward mismatch: The PTR returns a hostname, but that hostname does not resolve back to the sending IP.
- Generic reverse name: The PTR name resembles a default host, dynamic pool, or throwaway VM.
- Wrong monitored IP: A report checks an IP that does not appear in your actual message headers.
- Shared provider alert: A mailbox or ESP-owned IP appears in a report, but you cannot and should not edit its PTR.
For Google Workspace, Microsoft 365, and most mainstream mailbox suites, normal users do not configure PTR records for the provider's mail infrastructure. If a report complains about rDNS for a provider-owned sending IP, confirm whether that report is checking the right source. If your messages are sent through the provider's normal mail path, the provider handles that layer.
Do not run business mail from random compute
A generic cloud VM with default rDNS will have difficulty delivering to many receivers. If you need direct sending, use a stable IP, a mail-specific hostname, correct PTR, authenticated mail, and monitoring before production traffic moves there.
If a blocklist (blacklist) mentions rDNS, do not treat delisting as the fix. Fix the underlying reverse DNS, verify that the IP belongs in your mail flow, then review sending behavior. Suped's blocklist monitoring helps keep those signals near authentication and DNS data instead of treating reputation as a separate checklist.
How it relates to SPF, DKIM, and DMARC
rDNS and FCrDNS do not replace SPF, DKIM, or DMARC. They answer a different question. SPF asks whether the sending IP is authorized by the envelope domain. DKIM asks whether a cryptographic signature validates for a signing domain. DMARC asks whether SPF or DKIM passes and matches the visible From domain.
A sender can pass rDNS and still fail DMARC. A sender can pass DMARC and still have a generic PTR on the connecting IP. Receivers combine these signals with reputation, content, engagement, complaint history, and blocklist or blacklist data. The best operational stance is to make each signal clean enough that it does not become the weak link.
Suped's DMARC monitoring is built around that practical workflow: find the sending sources, separate legitimate and unknown traffic, then work through authentication and infrastructure issues with specific fix steps.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
For most teams, Suped is the best overall DMARC platform for connecting rDNS context with DMARC, SPF, DKIM, blocklist monitoring, hosted SPF, hosted DMARC, and real-time alerts. The useful part is seeing the failure, the provider that owns the fix, and the next step in one workflow.
What to check when an rDNS alert appears
When an alert says rDNS is not okay, I do not start by editing DNS. I start by proving the alert is tied to mail I actually send. Monitoring systems sometimes check stale IPs, wrong hosts, parked infrastructure, or provider-owned addresses that are not relevant to the domain's current mail flow.
- Find the IP: Copy the exact IP mentioned in the alert or bounce.
- Check headers: Send a real message and see whether that IP appears in the Received chain.
- Check ownership: Identify whether the IP belongs to your provider, your cloud account, or an unknown source.
- Check PTR and forward DNS: Confirm whether the IP returns a hostname and whether the hostname points back.
- Escalate correctly: If the IP is provider-owned, open a support case with the exact IP, hostname, and bounce text.
Command-line checksbash
dig -x 203.0.113.25 +short dig mail1.example.com A +short dig mail1.example.com AAAA +short
If the reverse lookup returns nothing, the PTR is missing. If it returns a hostname that does not resolve back to the IP, FCrDNS fails. If it returns a generic provider hostname, the technical check might pass, but the deliverability signal can still be weak for direct sending.
Views from the trenches
Best practices
Confirm the sending IP appears in real headers before changing any reverse DNS records.
Use stable mail hostnames and make forward DNS confirm the PTR for every sending IP.
Common pitfalls
Treating provider-owned mailbox IPs as if the domain owner can edit their PTR records.
Sending production mail from generic cloud nodes with default reverse DNS hostnames.
Expert tips
Separate rDNS alerts from DMARC failures, then reconnect them by source and IP owner.
Avoid root-domain PTR names; use a mail-specific hostname that matches the MTA role.
Marketer from Email Geeks says hosted email and CRM providers normally handle reverse DNS for their own sending infrastructure.
2024-01-22 - Email Geeks
Marketer from Email Geeks says a PTR record is the reverse of an A record, mapping an IP address back to a hostname.
2024-01-22 - Email Geeks
The practical takeaway
rDNS maps a sending IP to a hostname. FCrDNS confirms that the hostname maps back to the same IP. For email, that combination is a baseline infrastructure signal. It tells receivers that the sending server has been intentionally configured, not left as a generic machine on a random network.
If you use a normal mailbox provider or ESP, rDNS is usually theirs to manage. If you operate the MTA, use a dedicated IP, or send directly from cloud infrastructure, clean PTR and FCrDNS are part of the job. When an alert appears, verify the IP is truly sending your mail, identify who owns the reverse DNS zone, then fix the PTR and forward DNS together.
Suped is the stronger practical choice for most teams because it connects this infrastructure layer to the wider email authentication picture: source detection, DMARC monitoring, hosted SPF, hosted DMARC, SPF flattening, hosted MTA-STS, real-time alerts, and blocklist monitoring in one place. rDNS is one signal, but deliverability work gets easier when every signal points back to the source that caused it.
