DNS Problems: The Hidden Reason Your Emails Never Arrive

What Is Reverse DNS and How Does It Work?

To understand reverse DNS, you first need to understand what regular DNS does. When you type a domain name like mail.yourdomain.com into a browser or configure it as your mail server’s hostname, the Domain Name System translates that human-readable name into a numerical IP address, say 203.0.113.25. That translation, from name to number, is called a forward DNS lookup.

Reverse DNS is exactly what it sounds like: the same process running in the opposite direction. Given an IP address, rDNS resolves it back to a hostname. This is accomplished through a special type of DNS record called a PTR record (pointer record). When a receiving mail server sees an incoming SMTP connection from 203.0.113.25, it performs a reverse DNS lookup to ask, “What hostname claims ownership of this IP address?” If the PTR record for that IP returns mail.yourdomain.com, and a subsequent forward lookup of mail.yourdomain.com resolves back to 203.0.113.25, the receiving server gains a degree of confidence that the sending server is legitimate.

This bidirectional verification, sometimes called Forward-Confirmed Reverse DNS (FCrDNS), is the gold standard. It proves that whoever controls the IP address and whoever controls the domain agree about the relationship between the two. Without it, there is no way for a receiving mail server to trust that the connecting IP is who it claims to be at the network level.

The technical underpinning of rDNS relies on a special DNS zone called the in-addr.arpa zone for IPv4 addresses (and ip6.arpa for IPv6). When a reverse lookup is performed on 203.0.113.25, the DNS resolver actually queries for a PTR record at 25.113.0.203.in-addr.arpa. The octets of the IP address are reversed and appended to the in-addr.arpa domain. This inverted structure exists because DNS zones delegate authority from right to left, so reversing the IP octets allows delegation to work naturally along IP block boundaries.

Forward DNS vs. Reverse DNS: Understanding the Difference

The most important distinction between forward and reverse DNS is not technical; it is about who controls them. Forward DNS records, the A records, MX records, CNAME records, and TXT records that you interact with when managing your domain, are controlled by whoever owns the domain. You can log into your domain registrar or DNS provider and modify them at will.

Reverse DNS records, however, are controlled by whoever owns the IP address block. In nearly all cases, that is your hosting provider or Internet Service Provider, not you. This is the single most important fact about rDNS, and it is the root cause of most rDNS problems. You cannot simply log into your DNS management panel and add a PTR record. You must work with the entity that controls the IP space.

Think of it like this: forward DNS is your business card, something you print and hand out yourself. Reverse DNS is your listing in the phone book, something that only the phone company can publish on your behalf. If you hand someone a business card that says “John Smith, 555-1234,” and they look up 555-1234 in the phone book only to find it is listed under “Jane Doe” or not listed at all, they have every reason to be suspicious.

The A Record and PTR Record Relationship

For email purposes, the ideal configuration creates a perfect loop. Your mail server’s hostname, say mail.yourdomain.com, has an A record pointing to your server’s IP address. That same IP address has a PTR record pointing back to mail.yourdomain.com. When a receiving mail server checks both directions and gets matching results, it confirms the identity of your sending server at the network level. This match is not optional for reliable email delivery. It is a baseline expectation that every major email provider enforces to some degree.

Why rDNS Matters So Much for Email Deliverability

Email was designed in an era of trust. The original SMTP protocol, defined in the early 1980s, had virtually no authentication mechanisms. Any server could connect to any other server, claim to be sending mail from any address, and the receiving server would simply accept it. As spam became an epidemic through the 1990s and 2000s, layers of authentication and verification were bolted on to this fundamentally trusting protocol.

Reverse DNS was one of the earliest and most effective of those layers. The logic behind it is straightforward: legitimate mail servers operate on IP addresses that have been deliberately configured with proper PTR records. Spammers, on the other hand, often operate from compromised machines, temporary cloud instances, or residential IP addresses that lack rDNS configuration. By checking for a valid PTR record, receiving servers can immediately filter out a massive volume of illegitimate email traffic before expending any further resources on analysis.

Today, rDNS checking is not a recommendation; it is a requirement. Major email providers will outright reject or severely penalize messages from sending IPs that lack a properly configured PTR record. This is codified in various RFCs and best-practice documents, including RFC 5321, which explicitly notes that SMTP clients should ensure their IP addresses have valid reverse DNS mappings.

“The lack of a PTR record for a sending IP is one of the strongest negative signals a receiving mail server can observe. It suggests the sender either does not understand email infrastructure or does not care about conforming to it, and neither scenario inspires trust.” — Email infrastructure engineering principle

How Gmail, Microsoft, and Yahoo Use rDNS Checks

Gmail’s Approach

Google is one of the strictest enforcers of rDNS compliance. Gmail’s mail servers perform a reverse DNS lookup on every connecting IP address. If the lookup fails, if no PTR record exists, or if the PTR record resolves to a generic hostname like 203-0-113-25.static.provider.net, Gmail may accept the message but route it directly to the spam folder. In some cases, Gmail will reject the connection entirely with a 550 error that explicitly mentions the lack of a PTR record. Google’s postmaster guidelines state plainly that sending IPs must have valid reverse DNS records that resolve to the sending domain.

Microsoft 365 and Outlook.com

Microsoft takes a similar but slightly different approach. Their mail servers perform rDNS lookups and factor the result into an aggregate reputation score for the sending IP. A missing PTR record alone may not trigger an immediate rejection, but it contributes to a negative reputation assessment that, combined with other factors like sending volume and complaint rates, can push your messages into the junk folder or result in a temporary deferral. Microsoft’s SMTP servers frequently return 450-series temporary rejection codes when rDNS checks are ambiguous, causing your server to retry and adding delays of minutes or hours to delivery.

Yahoo and AOL

Yahoo’s mail infrastructure, which also handles AOL mail, has historically been among the most aggressive rDNS enforcers. Their servers will often reject connections outright from IPs without PTR records, returning a 553 or 554 error code with a message indicating that the reverse DNS lookup failed or returned an invalid result. Yahoo’s sender guidelines explicitly require that all sending IPs have forward and reverse DNS records that are consistent and fully qualified.

The Most Common rDNS Problems and Their Causes

1. No PTR Record Exists at All

This is the most straightforward and most common rDNS problem. Your server’s IP address simply has no PTR record configured. This happens frequently when you spin up a new VPS or cloud instance, because many hosting providers do not automatically create PTR records for new IP allocations. The IP works fine for web traffic, SSH, and other protocols, but email delivery fails because receiving servers find nothing when they perform the reverse lookup.

2. PTR Record Points to a Generic Hostname

Many hosting providers set default PTR records that resolve to generic, provider-assigned hostnames like vps12345.hostingcompany.com or ip-203-0-113-25.us-east-1.compute.internal. While these technically satisfy the “has a PTR record” check, they fail the more important test of matching your sending domain. Receiving servers see that your SMTP banner says mail.yourdomain.com but the rDNS says vps12345.hostingcompany.com, and the mismatch raises red flags.

3. PTR Record Exists but Forward Lookup Fails

This is the FCrDNS failure scenario. Your IP has a PTR record pointing to mail.yourdomain.com, but when the receiving server performs a forward lookup on mail.yourdomain.com, it either gets no result, a different IP address, or a DNS error. This forward confirmation failure is treated as seriously as having no PTR record at all, because it suggests the PTR record was set up without corresponding forward DNS configuration.

4. PTR Record Has Propagation Delays

After requesting a PTR record change from your hosting provider, it can take anywhere from a few minutes to 48 hours for the change to propagate across the global DNS infrastructure. During this period, some receiving servers will see the old (or missing) record while others will see the new one, leading to inconsistent delivery results that can be extremely confusing to diagnose.

5. Shared IP Address with Conflicting PTR Record

If you are on a shared hosting plan where multiple domains share a single IP address, the PTR record for that IP can only point to one hostname. If your hosting provider has set it to their own hostname or to another customer’s domain, your emails will fail the rDNS consistency check even though the PTR record technically exists.

6. IPv6 rDNS Is Missing

Increasingly, mail servers send over IPv6 when available. If your server has an IPv6 address but no corresponding AAAA record and PTR record for that IPv6 address, emails sent over IPv6 will fail rDNS checks. This is becoming a more frequent issue as IPv6 adoption accelerates and servers default to using their IPv6 address for outbound SMTP connections.

How to Diagnose rDNS Issues Step by Step

Before you can fix an rDNS problem, you need to confirm it exists and understand its specific nature. Here is a systematic approach to diagnosing reverse DNS issues for your email infrastructure.

Step 1: Identify Your Sending IP Address

The first thing you need to know is which IP address your mail server uses for outbound SMTP connections. This is not always the same as your website’s IP address. If you are using a dedicated mail service, a different server for outbound email, or a relay, the sending IP may differ. Check your mail server’s configuration or send a test email to a Gmail account and examine the “Received” headers, which will show the connecting IP address.

Step 2: Perform a Reverse DNS Lookup

Once you have the IP address, perform a reverse DNS lookup. On Linux or macOS, open a terminal and run:

dig -x 203.0.113.25

On Windows, you can use:

nslookup 203.0.113.25

You can also use online tools like MXToolbox, DNSChecker, or IntoDNS to perform PTR lookups through a web browser. The result should show a PTR record resolving to a meaningful hostname that matches your mail server’s identity.

Step 3: Verify Forward-Confirmed Reverse DNS

Take the hostname returned by the PTR lookup and perform a forward DNS lookup on it. If the PTR record returned mail.yourdomain.com, run:

dig mail.yourdomain.com A

The A record result should point back to the same IP address you started with. If it does, you have valid FCrDNS. If it returns a different IP or no result, you have a broken configuration that needs to be fixed on both the forward and reverse sides.

Step 4: Check Your SMTP Banner

Your mail server’s SMTP banner, the greeting it sends when a remote server connects, should match the hostname in your PTR record. You can test this by telnetting to your mail server on port 25:

telnet mail.yourdomain.com 25

The server should respond with something like “220 mail.yourdomain.com ESMTP.” If the banner shows a different hostname, receiving servers will note the discrepancy, and some will reject the connection.

Step 5: Use Email Testing Tools

Services like mail-tester.com, MXToolbox’s email deliverability test, and Google’s Postmaster Tools can provide comprehensive diagnostics that include rDNS checks alongside SPF, DKIM, and DMARC validation. Send a test email to these services and review the full report for any rDNS-related warnings or failures.

Fixing Your rDNS: A Practical Walkthrough

Once you have identified the specific rDNS problem, fixing it generally involves coordinating changes on two sides: the reverse DNS side (controlled by your hosting provider) and the forward DNS side (controlled by you through your domain’s DNS settings).

Setting Up the Forward DNS Side

First, ensure your mail server has a dedicated hostname with a proper A record. If your mail server’s hostname is mail.yourdomain.com, log into your DNS management panel and create or verify an A record:

• Hostname: mail.yourdomain.com
• Record Type: A
• Value: Your server’s IP address (e.g., 203.0.113.25)
• TTL: 3600 (one hour) or lower during testing

If your server also has an IPv6 address, create a corresponding AAAA record with the same hostname pointing to the IPv6 address.

Requesting the PTR Record from Your Provider

Next, contact your hosting provider and request that they set the PTR record for your IP address to match your mail server’s hostname. With most quality hosting providers, this can be done through a control panel. On providers like Interserver, Kinsta, and KnownHost, PTR record management is available directly in the client area. Other providers like Cloudways and UltaHost allow PTR configuration through their server management dashboards. If your provider does not offer self-service PTR management, you will need to submit a support ticket.

When requesting the PTR record, be specific. Tell them the exact IP address and the exact hostname you want it to resolve to. For example: “Please set the PTR record for 203.0.113.25 to mail.yourdomain.com.” Do not assume they will figure out the correct hostname. Be explicit.

Verifying the Configuration

After both the forward A record and the reverse PTR record are in place, wait for DNS propagation (usually a few hours, though it can be faster) and then re-run the diagnostic steps outlined in the previous section. Confirm that the reverse lookup returns your hostname and that the forward lookup of that hostname returns your IP. Check the SMTP banner to ensure all three elements, PTR record, A record, and SMTP banner, are in agreement.

rDNS on Shared Hosting: The Problem Nobody Talks About

If you are running a website on shared hosting, rDNS is very likely something you have never thought about, and for good reason: you have essentially zero control over it. On a shared hosting plan, your website shares an IP address with dozens or even hundreds of other websites. The hosting provider sets a single PTR record for that IP, and it almost certainly does not point to your domain.

This is one of the fundamental reasons why sending email directly from shared hosting plans is unreliable. The PTR record for the shared IP usually points to the hosting provider’s generic hostname, which means your outbound emails will fail rDNS consistency checks at every major email provider.

Reputable shared hosting providers like SiteGround and BlueHost mitigate this by routing outbound email through dedicated mail relay servers that have properly configured rDNS. However, not all providers take this precaution. Budget hosts may simply send email directly from the shared IP, resulting in chronic deliverability problems that customers blame on SPF or DKIM configuration when the real issue is the PTR record they cannot even see.

“I spent three weeks troubleshooting SPF and DKIM records on my shared hosting plan before I finally checked rDNS. The shared IP had a PTR record pointing to the provider’s default hostname. None of my emails to Gmail were arriving. I switched to a transactional email service and the problem vanished overnight.” — A frustrated website operator’s common experience

The Shared Hosting Workaround

If you are on shared hosting and cannot get a dedicated IP with a custom PTR record, the best solution is to route your outbound email through a third-party service. Transactional email providers maintain their own IP infrastructure with properly configured rDNS, SPF, DKIM, and DMARC. By using their SMTP relay, your emails effectively inherit their deliverability infrastructure without you needing to manage any of it yourself. Providers like IONOS offer email hosting options with properly configured infrastructure, which can be a simpler path for small businesses that want reliable email without managing server-level settings.

Setting Up rDNS on a VPS or Dedicated Server

If you are running your own mail server on a VPS or dedicated server, you have far more control over rDNS configuration, but that also means the responsibility falls squarely on your shoulders. Here is what the process typically looks like across different hosting environments.

VPS Providers

Most reputable VPS providers allow you to set PTR records through their control panel. Providers such as UltaHost, KnownHost, and Interserver typically offer this as a standard feature in their VPS management interfaces. You simply navigate to the networking or DNS section of your server’s control panel, find the PTR or rDNS settings, and enter the hostname you want the IP to resolve to. The change usually takes effect within minutes to a few hours.

With Cloudways, which manages servers on top of major cloud platforms, PTR records can be configured through their platform’s server management tools. This is particularly convenient because Cloudways abstracts away the complexity of the underlying cloud provider’s networking configuration.

Dedicated Servers

On dedicated servers, PTR record management depends on the provider. HostGator and similar traditional hosting providers typically handle PTR requests through support tickets for dedicated server customers. Some providers, like JetHost, offer more streamlined processes. The key is to ask your provider about their PTR record management process before you need it, ideally before you even sign up.

Essential Configuration Checklist for VPS and Dedicated Servers

1. Set your server’s hostname to match the desired PTR record (e.g., mail.yourdomain.com)
2. Create an A record for that hostname pointing to the server’s IP
3. Request or configure the PTR record for the IP to point to that same hostname
4. Configure your mail server’s SMTP banner (HELO/EHLO hostname) to match
5. If using IPv6, repeat steps 2 through 4 for the AAAA record and IPv6 PTR
6. Test with MXToolbox, mail-tester.com, or direct dig/nslookup commands
7. Send test emails to Gmail, Outlook, and Yahoo and verify inbox delivery

rDNS and the Email Authentication Stack: SPF, DKIM, and DMARC

It is tempting to think of email authentication as a hierarchy where rDNS sits at the bottom and DMARC sits at the top. In reality, these mechanisms work in parallel, and a failure in any single one can derail deliverability regardless of how perfectly the others are configured.

How rDNS Fits with SPF

SPF (Sender Policy Framework) tells receiving servers which IP addresses are authorized to send email for your domain. If your sending IP is listed in your SPF record, the SPF check passes. However, even with a passing SPF check, a missing PTR record for that same IP can independently trigger spam filtering or rejection. SPF answers the question “Is this IP allowed to send for this domain?” while rDNS answers the more fundamental question “Does this IP have a verifiable identity?” Both need affirmative answers for reliable delivery.

How rDNS Relates to DKIM

DKIM (DomainKeys Identified Mail) signs your email content with a cryptographic key, proving that the message has not been altered in transit and that it originated from an authorized sender. DKIM operates at the message level, not the connection level. By the time DKIM is evaluated, the SMTP connection has already been established, which means rDNS has already been checked. If the rDNS check caused the connection to be rejected or the message to be flagged, your perfectly valid DKIM signature never gets evaluated.

The DMARC Alignment Factor

DMARC ties SPF and DKIM together with your domain’s policy. But DMARC cannot compensate for rDNS failures because rDNS operates at a layer below DMARC’s scope. Think of it as building codes for a skyscraper: DMARC is the building code enforcement agency, SPF is the electrical wiring inspection, and DKIM is the structural engineering certification. But rDNS is the foundation. If the foundation is cracked, no amount of perfect wiring, structural engineering, or code compliance saves the building.

Real-World Case Studies: rDNS Failures in the Wild

Case Study 1: The E-Commerce Store Losing Orders

A mid-sized e-commerce business noticed that roughly 25 percent of their order confirmation emails were never reaching customers. Customers were calling in to ask whether their orders had been placed, overwhelming the support team and damaging brand trust. The company had SPF and DKIM properly configured, and their DMARC reports showed no authentication failures.

After weeks of investigation, an email infrastructure consultant discovered that the company’s transactional email server had been migrated to a new IP address during a hosting upgrade. The forward DNS records had been updated to point to the new IP, but no one had requested a PTR record for the new address. The old IP still had the correct PTR, but the new IP returned “NXDOMAIN” (no record found) on reverse lookup. Gmail was silently dropping the messages. The fix took ten minutes once identified: a PTR record request to the hosting provider. Within hours, delivery rates returned to normal.

Case Study 2: The Startup Blacklisted Before Launch

A SaaS startup launched their product and immediately began sending welcome emails, password resets, and notification emails from their newly provisioned cloud server. Within 48 hours, their IP address appeared on multiple email blacklists. The team assumed they had been caught up in a neighbor’s bad behavior on a shared IP range, but the actual cause was simpler: they had never configured a PTR record for their server’s IP. Every major email provider was flagging their messages as suspicious, and several anti-spam blacklists automatically listed IPs that send email without valid rDNS. The startup had to go through a delisting process with each blacklist and configure proper rDNS before their emails began reaching users reliably.

Case Study 3: The Newsletter with Inconsistent Open Rates

A marketing team noticed wildly inconsistent open rates on their newsletter. Some sends achieved 30 percent opens while others barely cracked 5 percent, despite similar content and consistent send times. Investigation revealed that the company used a pool of sending IPs, and some had properly configured PTR records while others did not. Messages from IPs with valid rDNS reached inboxes; those from misconfigured IPs landed in spam. Standardizing rDNS across all sending IPs stabilized open rates immediately.

IPv6 and rDNS: A Growing Challenge

As the internet migrates from IPv4 to IPv6, rDNS configuration has become more complex. IPv6 addresses are 128 bits long compared to IPv4’s 32 bits, meaning PTR record zone entries are considerably longer and more error-prone.

An IPv4 PTR record might look like 25.113.0.203.in-addr.arpa. An IPv6 PTR record for 2001:0db8:85a3::8a2e:0370:7334 would look like 4.3.3.7.0.7.3.0.e.2.a.8.0.0.0.0.0.0.0.0.3.a.5.8.8.b.d.0.1.0.0.2.ip6.arpa. Every hexadecimal digit of the fully expanded address is reversed and dot-separated. A single misplaced character breaks the entire record.

Many hosting providers have robust IPv4 rDNS tools but inadequate IPv6 rDNS options. If your server defaults to IPv6 for outbound SMTP connections, you could have perfect IPv4 rDNS and still fail delivery because the IPv6 PTR is missing.

IPv6 rDNS Best Practices

• If your server has an IPv6 address, either configure proper rDNS for it or disable IPv6 for outbound SMTP connections
• Verify that your hosting provider supports IPv6 PTR record management before enabling IPv6 email sending
• Test IPv6 rDNS separately from IPv4 using tools like dig -x with the full IPv6 address
• Consider temporarily disabling IPv6 SMTP while you get the PTR records sorted, then re-enable it once confirmed

rDNS Best Practices for Long-Term Deliverability

Getting rDNS right is not a one-time task. It requires ongoing attention, particularly when your infrastructure changes. Here are the practices that keep your reverse DNS configuration healthy over time.

Maintain the FCrDNS Loop

Always ensure that your PTR record and your forward A record form a complete, consistent loop. When you change one, change the other. Document both records together so that anyone managing your infrastructure knows they are a matched pair. Treat them as inseparable, because from the perspective of receiving mail servers, they are.

Match Your SMTP Banner

Your mail server’s HELO or EHLO hostname should match the hostname in your PTR record. This triple consistency, PTR record, A record, and SMTP banner all agreeing on the same hostname, is the strongest possible signal of a legitimately configured mail server.

Use Meaningful Hostnames

Your PTR record hostname should be meaningful and associated with your domain. mail.yourdomain.com is excellent. mx1.yourdomain.com is also good. server1.yourdomain.com is acceptable. Avoid generic hostnames that do not clearly identify your domain or purpose.

Monitor Regularly

Set up automated monitoring for your PTR record. Services like UptimeRobot, Pingdom, or even simple cron-based scripts can periodically check your rDNS and alert you if the record changes or disappears. Hosting providers occasionally make changes to their IP infrastructure that can silently break PTR records without any notification to the customer.

Document Everything

Keep a record of your complete email authentication configuration in one place: your sending IP addresses, their PTR records, your forward DNS entries, your SPF record, your DKIM selector and key, and your DMARC policy. When something breaks, having this documentation saves hours of diagnostic work.

Audit After Every Infrastructure Change

Server migration, IP address change, hosting provider switch, new sending IP added to a pool, IPv6 enabled, load balancer reconfigured, any of these changes can break your rDNS without warning. Build an rDNS verification step into your change management process.

How to Choose a Hosting Provider That Handles rDNS Properly

Not all hosting providers treat rDNS with the seriousness it deserves. When evaluating a hosting provider for any use case that involves sending email, whether transactional messages from a web application, newsletters, or full-service business email, you should specifically ask about their rDNS capabilities.

Questions to Ask Before Signing Up

• Can I set a custom PTR record for my IP address?
• Is PTR record management available through a self-service control panel, or does it require a support ticket?
• Do you support IPv6 PTR records?
• If I am on shared hosting, how do you handle outbound email rDNS for shared IPs?
• What is the turnaround time for PTR record changes?
• Will I be notified if my IP address changes, which would require a new PTR record?

Providers Known for Good rDNS Support

Among the major hosting providers, several stand out for their approach to PTR record management. Kinsta provides managed WordPress hosting with a robust infrastructure that handles email relay and DNS configuration seamlessly. KnownHost offers VPS and dedicated hosting with straightforward PTR management through their control panel. Interserver has long been praised by email administrators for their willingness to configure custom PTR records quickly and without hassle on their VPS and dedicated plans.

For managed cloud hosting, Cloudways abstracts away much of the server management complexity while still providing access to essential configurations like PTR records. SiteGround handles email infrastructure well on their shared and cloud plans, routing outbound email through properly configured relay servers. UltaHost provides VPS solutions with full control over DNS settings including reverse DNS.

Budget-friendly options like BlueHost and HostGator offer reliable shared hosting, though for email-critical applications you may want to pair them with a dedicated email sending service. IONOS offers an interesting middle ground with integrated email hosting that includes proper authentication setup. Newer entrants like JetHost focus on providing developer-friendly hosting environments with full control over DNS and rDNS configuration.

Advanced rDNS Considerations for High-Volume Senders

If your organization sends email at scale, whether through marketing campaigns, transactional messages, or automated notifications, rDNS management becomes more complex and more critical.

Managing rDNS Across Multiple Sending IPs

High-volume senders often use pools of IP addresses to distribute sending load. Each IP in the pool needs its own PTR record and a corresponding forward A record. A common pattern is sequential hostnames like mail1.yourdomain.com, mail2.yourdomain.com, each paired to a specific IP. If one IP in the pool loses its PTR record, emails from that IP will fail while others succeed, creating intermittent delivery failures that are notoriously difficult to diagnose.

rDNS for Outbound Relays and Cloud Environments

If your application sends email through an SMTP relay, the rDNS that matters is on the relay, not on your application server. This is an advantage of using a relay: its infrastructure is maintained with proper rDNS, freeing your application from PTR record management. In cloud environments where servers autoscale and receive new IPs automatically, routing all outbound email through a dedicated, statically addressed relay server avoids the problem of ephemeral instances lacking PTR records entirely.

Troubleshooting Specific rDNS Error Messages

When emails bounce due to rDNS problems, the error messages can vary significantly across providers. Here is a guide to the most common error messages and what they mean.

“550 IP not in rDNS” or “550 Reverse DNS required”

This is the most explicit rDNS rejection. The receiving server performed a reverse lookup on your IP, found no PTR record, and rejected the connection. The fix is straightforward: add a PTR record for your IP.

“450 4.7.25 Temporary DNS failure” or “421 Try again later”

These temporary rejection codes indicate that the rDNS lookup encountered a DNS timeout. Your server will retry, and if the DNS resolves on a subsequent attempt, the message will be delivered. Persistent errors suggest a problem with the DNS infrastructure serving your PTR zone, which you should report to your hosting provider.

“550 Client host rejected: cannot find your hostname”

This means the PTR lookup returned a hostname, but the subsequent forward lookup on that hostname failed. You have a broken FCrDNS chain. Verify that the forward A record for your mail server hostname exists and points to the correct IP.

“554 5.7.1 Service unavailable; Client host blocked”

While this error has multiple causes, a common trigger is an IP lacking rDNS that has also landed on reputation blacklists. Fix the rDNS first, then request delisting from the relevant blacklists.