Reverse DNS Setup for Send-Only IPs

Why Reverse DNS Matters for Email Deliverability

You send mail through a managed service, your IP is assigned by the host, and everything seems to work—until your messages vanish into spam folders or vanish entirely. Why? One invisible piece of the puzzle: reverse DNS.

Reverse DNS ties your sending IP address to a domain name. It’s like a digital fingerprint. Mailbox providers like Gmail, Outlook, and Yahoo use it to verify your sender identity. If your rDNS doesn’t align with your SMTP server’s HELO/EHLO domain, you’re flagged—no matter how clean your content.

Setting up rDNS isn’t a luxury. It’s a core requirement for inbox placement. Without it, your reputation is undermined before your first message even leaves the queue.

Key takeaways

Reverse DNS maps your sending IP to a domain name, confirming your server’s identity.
Mismatches between rDNS and your SMTP HELO domain are a red flag for Gmail, Outlook, and Yahoo.
Proper rDNS configuration is essential—even for send-only IPs assigned by hosting providers—to maintain sender reputation and avoid deliverability issues.

What Is Reverse DNS and How Does It Work?

Reverse DNS (rDNS) maps an IP address back to a domain name using a PTR record in DNS. While forward DNS resolves a domain like mail.example.com to an IP (e.g. 192.0.2.1), rDNS does the opposite: it looks up the domain associated with that IP. For email senders, your rDNS should point to the domain hosting your SMTP server—like mail.example.com—to help prove you’re not a spammer.

How rDNS Supports Email Deliverability

When your mail server sends an email, receiving servers often check the rDNS of your sending IP. If it doesn’t match your domain or doesn’t resolve at all, the email may be flagged or rejected. This is one layer in a larger trust system. ISPs and email providers use rDNS as a signal that you’re operating with a known, consistent identity—not a random server in a data center.

For example, if your IP is 192.0.2.1 and you’re sending from mail.example.com, the PTR record should return that same domain. If it says something else—like a generic hosting name or fails to resolve—the receiver may treat your mail as suspicious. This isn’t a guarantee of delivery, but it’s a step toward being treated as legitimate.

Setting It Up: What You Need to Know

Unlike forward DNS, which you manage through your domain registrar, rDNS is controlled by the IP address owner—typically your hosting provider. You can’t set it yourself unless you have direct access to the network infrastructure. That means you’ll need to contact your provider’s support team to request the PTR record update.

Keep in mind that some providers will only allow rDNS entries that match the domain they’ve assigned the IP to. If you’re using a cloud provider or shared hosting, they may restrict how much you can customize it. Still, it’s worth asking. Many reputable services allow it for dedicated IPs, especially if you're sending email at scale.

Once set, test it using tools like MxToolbox or RFC 1035, which define DNS fundamentals. It’s also smart to verify your sender reputation and ensure that your IP isn’t on any blocklists before relying on rDNS to improve inbox placement.

Even with correct rDNS, your email success depends on more than one signal. SPF, DKIM, and DMARC are equally important. A full deliverability setup isn’t just about one record—it’s about consistency across DNS, IP reputation, and content. You can test your email’s path to the inbox with MailTester’s inbox placement tester before sending to real users.

When Does Your Hosting Service Assign a Send-Only IP Range?

You’re assigned a send-only IP range when your hosting provider — like AWS, Google Cloud, or a dedicated email delivery service — gives you IP addresses exclusively for outbound email traffic. These IPs typically don’t come with a public domain name attached and are restricted to sending email only, meaning you can’t host websites or use SSH on them. This setup is standard for cloud-based email services that prioritize deliverability and reduce abuse risk.

Common Providers and Use Cases

Cloud providers like AWS and Google Cloud often assign send-only IPs when you use their SES (Simple Email Service) or equivalent. Similarly, colocation hosts or dedicated email platforms may hand out ranges meant for transactional or marketing mail only. These IPs aren’t meant for general web hosting or remote access — they’re designed to keep your sending reputation clean by isolating email traffic from other services.

Because these IPs aren’t tied to a domain by default, you must configure reverse DNS (PTR record) manually to align the IP with a sending domain. Without it, emails are more likely to land in spam folders or be rejected outright. According to RFC 1918, private and reserved IP ranges should not be publicly resolvable, but in practice, sending services use public-IP ranges that still require proper reverse DNS to avoid being flagged as spam.

Why Reverse DNS Matters Here

When your IP range is send-only, you’re not hosting a website, so there’s no natural DNS entry. But email receivers still expect to see a reverse DNS record that matches your sending domain. For example, mail.example.com should point back to your IP. Without this, even legitimate email can be blocked or deprioritized.

Providers like AWS do allow you to set PTR records for SES, but only within your own account and with proper authentication. It’s a critical step that’s often skipped — especially when setting up automated email systems without a full DevOps team. You need to validate that the reverse lookup works before scaling your sends.

Let’s say you’re sending emails through a third-party service. They may hand you an IP block but leave reverse DNS up to you. If your domain isn’t properly aligned, your sender reputation will suffer. You can test your setup with tools like inbox placement testing to see how real inboxes handle your mail. This helps identify issues like missing reverse DNS, poor sender reputation, or spam filters blocking delivery.

Can You Set Reverse DNS for a Shared or Isolated IP Range?

You can only set reverse DNS (rDNS) for an IP range if you’re the owner — typically your hosting provider or ISP. Shared IP ranges usually come with pre-configured, generic PTR records like static.hosting.com, and you can’t change them. With isolated or dedicated IPs, you may be able to reconfigure the PTR record through your provider’s portal or support team, but only if they allow it.

Shared IPs: Limited Control

Most shared IP ranges are managed by a hosting service, and they control the rDNS entries for all users on that range. This means your outbound emails might point to a generic hostname like server123.hosting.net — and that’s not something you can override. A shared setup doesn’t give you the reputation or identity you need for consistent deliverability.

Because rDNS is tied to your sender identity, a mismatch between your domain, IP, and rDNS can trigger filters. This is especially likely with bulk senders. The Internet Engineering Task Force (IETF) has long emphasized that proper rDNS — linked to valid reverse DNS lookups — is a foundational part of email verification and sender trust. You can read more about its role in RFC 5321, which covers SMTP basics and authentication practices.

Dedicated IPs: A Path to Ownership

If you have a dedicated or isolated IP range — often assigned through cloud providers like AWS, Google Cloud, or a managed hosting vendor — you may have the ability to configure rDNS. But this depends on the provider’s policies. Some allow direct updates via a control panel. Others require a support ticket, and some still pre-assign generic names.

When you control rDNS, you can align it with your sending domain (e.g., mail.yourcompany.com). This helps reduce the risk of being flagged as spam. For example, if your IP’s rDNS resolves to a domain you’re known to send from, mail providers gain confidence in your message.

If you're managing email delivery at scale, verifying your sending infrastructure is essential. You can test how your setup performs by simulating real inbox placement, which helps catch misconfigurations before they hurt your reputation. Try an inbox placement test to see how your messages are received across major email providers.

How to Verify Your IP’s rDNS Configuration

You can verify your IP’s reverse DNS (rDNS) by running dig -x <your-ip> or nslookup <your-ip> in your terminal. If the result returns a hostname that matches your expected domain (like mail.yourcompany.com), and doesn’t point to a private network, ISP provider, or unrelated domain, your rDNS is likely set up correctly.

Step-by-step: How to Check Your rDNS

Open your terminal or command prompt.
Run dig -x 203.0.113.10 (replace with your actual send-only IP).
Look at the ANSWER SECTION for the hostname returned.
Confirm it matches the domain you’ve configured — for example, mail.yourcompany.com.
Ensure the result doesn’t show in-addr.arpa, isp.com, or static.ip patterns.
If it doesn’t match or returns a private/neutral domain, your rDNS is misconfigured.

What to Look For in the Results

Incorrect rDNS entries often return ISP-owned hostnames (like host-203-0-113-10.as12345.net) or localhost. A valid rDNS should resolve to a domain you control and use for email sending.

According to RFC 5321, mail servers should perform reverse DNS checks before accepting delivery. Misaligned rDNS is one of the top reasons email fails to pass initial validation.

Let’s say your send-only IP is 203.0.113.10, and the reverse lookup returns proxy-hosting.example.net — that’s a red flag. The server receiving your mail will likely reject the connection or mark it as suspicious.

If you’re using a cloud provider or reseller, rDNS is often managed by them. You’ll need to contact their support team to set it correctly. Most providers allow you to submit a request to update rDNS for your IP range.

Once you’ve made the change, wait 5 to 10 minutes for DNS propagation. Then verify again with dig or nslookup. Repeat until you see the expected domain.

Even if rDNS is correct, don’t assume your email will deliver. Sender reputation, SPF/DKIM/DMARC alignment, and mailbox provider filtering also impact inbox placement. Running a real inbox placement test helps confirm your full setup works.

For testing sender health post-configuration, use inbox placement testing to see how your emails perform across major providers.

How to Request rDNS Configuration with Your Hosting Provider

Log in to your hosting or cloud provider’s control panel, navigate to the IP management section, and look for Reverse DNS (PTR record) settings. If available, set it to your verified outbound domain (e.g., mail.example.com). If not, request it directly from support—most providers require a formal request for PTR assignment. This step is critical for sender reputation and inbox placement.

Step-by-step rDNS setup process

Log in to your cloud provider’s control panel. Access your account on platforms like AWS EC2, DigitalOcean, or Linode. This is where your IP addresses are managed.
Navigate to the network or IP management section. Look for terms like “Elastic IPs,” “IP addresses,” or “Network settings.” Your send-only IP range should appear here.
Locate the Reverse DNS or PTR record field. Some providers expose this directly—others hide it under advanced settings or require a support ticket. Check for labels like “Reverse DNS,” “PTR record,” or “Hostname.”
Set the PTR record to your validated outbound domain. If editable, enter the fully qualified domain name (FQDN) you use for outbound mail, like mail.yourdomain.com. This must resolve correctly and match your SPF record.
Submit a ticket if the field is uneditable. Most cloud providers do not allow direct PTR updates. Use the support portal to request a PTR assignment with clear justification: “Assign reverse DNS for public IP 198.51.100.100 to mail.example.com.” Include your SPF and DKIM setup status if applicable.

Why this matters: rDNS and email deliverability

Without a properly configured PTR record, receiving mail servers often treat your mail as suspicious or spam. According to RFC 1912, reverse DNS helps verify the authenticity of the sending host. Providers like Mailchimp and SendGrid check PTR records during delivery, and missing or misconfigured ones increase the risk of hard bounces or spam filtering.

The 5 steps described in “Step-by-step rDNS setup process”, in order.

If you're validating your outbound infrastructure, use an inbox placement test to check how your messages land. Test your mail streams end-to-end, especially after configuring rDNS. MailTester’s inbox placement tool simulates real-world delivery across Gmail, Outlook, and other major providers, giving you actionable feedback on deliverability.

Common Issues When Requesting rDNS from Hosting Providers

Many hosting providers restrict reverse DNS (rDNS) configuration to dedicated IPs only, even if you’re using a send-only range. Even when allowed, you might face delays, domain verification steps, or time-limited change windows. Propagation can take 24 to 72 hours due to DNS TTLs and caching across networks. These delays and restrictions often lead to poor sender reputation or email delivery failures, especially if you're relying on inbound feedback loops or authentication alignment.

Dedicated IP Requirement

Most cloud and shared hosting platforms block rDNS edits unless you have a truly dedicated IP address. This is a common hurdle for teams using shared infrastructure but still sending transactional or marketing emails. You’ll need to review your provider’s support documentation or reach out directly — but even then, changes often require approval, especially on large-scale or reseller-based networks.

Verification Delays and Propagation

Even after your provider accepts a change, the update isn’t immediate. DNS records propagate based on Time-To-Live (TTL) settings — often set to 86,400 seconds (24 hours) or higher at the authoritative level. This means rDNS updates can take up to 72 hours to reflect worldwide. During this window, SPF, DKIM, and DMARC reports may show mismatches, and receiving mail servers may flag your traffic as suspicious or untrusted.

A real-world example: If your mail server is hosted on a provider like DigitalOcean or AWS EC2, you may find rDNS only configurable after requesting a dedicated IP — not just any static IP from a pool. Some providers require domain ownership proof via TXT record validation before granting access. This adds friction, especially when you’re already under time pressure to fix deliverability issues.

Tools like inbox placement tests can help you validate whether a configuration change successfully improves your email delivery, especially across major inboxes like Gmail, Outlook, or Apple Mail. Before you commit to a change, run a delivery simulation to confirm the impact on real mail filters.

What to Do If Your Hosting Service Won’t Let You Set rDNS

If your hosting provider blocks rDNS configuration, you can't reliably send email from their IP ranges. Instead, route all outbound mail through a trusted SMTP relay service like SendGrid, Amazon SES, or Mailgun—these platforms manage rDNS on your behalf and maintain sender reputation, reducing the risk of blocks or spam filtering. You can also use a verified domain with self-managed DNS (including rDNS) to send from a dedicated, reputable email environment. Relying on unconfigurable or shared IPs for bulk email campaigns is a known path to deliverability failure.

Why rDNS Matters for Email Deliverability

Reverse DNS (rDNS) maps an IP address back to a domain name. Most reputable mail receivers check this during validation. If the rDNS doesn't match the sending domain, it raises red flags—even if your content is clean. According to RFC 1918 and modern anti-spam practices, mismatched rDNS is a common signal used in spam scoring. Without proper rDNS, your messages may be delayed, flagged as spam, or outright rejected.

How to Bypass a Locked-Down IP Range

Let's say you're running a campaign from a server on a shared cloud network where rDNS is off-limits. Your best step is to use a verified, dedicated email relay. These services assign you an IP range with properly configured rDNS and maintain aggregate reputation. They also offer built-in deliverability tools, including feedback loops and real-time inbox placement testing.

For example, SendGrid and Amazon SES allow you to send from a domain you control. Once verified, they handle the rDNS, SPF, DKIM, and DMARC for that domain. This gives you full control over reputation while offloading infrastructure complexity.

If you're using a shared or non-configurable IP, avoid using it as your primary email source. The risk of being placed on blocklists is not theoretical—it's common. Once an IP is tainted by spam, even clean messages get blocked, regardless of content. You can test your email’s inbox placement before sending to catch issues early; see how your messages land in real inboxes with a test email.

Also, clean your email list regularly. Invalid or disposable addresses harm deliverability. Use a verified service like MailTester's bulk verification to remove dead addresses before sending. You can also check individual addresses with our email checker.

How to Test Your rDNS and Improve Deliverability

You can verify your reverse DNS setup and assess inbox placement by running an inbox-placement test with MailTester. This test checks for common issues like rDNS mismatch, bad HELO/EHLO behavior, and sender reputation. You’ll see real-time feedback on whether your IP and domain align correctly with standards used by major email providers. If your rDNS hostname doesn’t match your sending domain (e.g., mail.example.com not matching your actual mail server), your messages may be flagged or rejected. Use the test to catch these issues before sending to real users.

Verify Your rDNS Configuration

Run an inbox-placement test using MailTester’s inbox tester, which simulates real recipient inboxes across major providers.
Ensure the test sender domain (e.g. sender.example.com) matches the rDNS hostname (e.g. mail.example.com) listed for your IP address.
Check for errors like rDNS mismatch or bad HELO/EHLO—these indicate your server identity doesn't align with DNS records.
Use tools like MXToolbox or RFC 5321 to validate your HELO/EHLO greeting and reverse DNS resolution independently.
Fix discrepancies by updating your PTR record to point to a hostname that matches your mail domain and is consistent with your SPF/DKIM/DMARC policies.

Improve Deliverability with Proactive Checks

Test your sending environment before sending to customers. Use MailTester’s real-time email checker to verify individual recipient addresses.
Run bulk list verification via MailTester’s bulk verification tool to clean your list before deployment.
Ensure your IP range is not listed on blocklists like Spamhaus or SORBS—check via Spamhaus.
Monitor sender reputation using tools that track engagement, bounce rates, and spam complaints over time.
Use the verification API at MailTester’s API endpoint if you're automating checks in a customer onboarding flow or CRM sync.

Deliverability isn’t just about sending— it’s about proving you’re a reliable sender, starting with how your IP identifies itself to the internet.

How Email Verification Plays a Role in Deliverability

Checking email addresses before sending reduces bounces, stops your IP from being flagged, and protects your sender reputation. Invalid, disposable, or catch-all addresses hurt deliverability—sending to them increases spam complaints and blocks. Using a tool like MailTester to clean your list cuts garbage sends and keeps your domain trusted.

Why Poor List Quality Hurts Deliverability

Every invalid address you send to increases bounce rates. High bounce rates signal to ISPs that you’re not managing your list well. Even a 2% bounce rate can trigger filters or lead to IP reputation drops. Disposable email domains (like temporary ones from Mailinator) are often used for fake signups and increase abuse risk. Catch-all addresses accept all emails, making them a dead-end for real communication—and a red flag for email providers.

Spam traps, often old or recycled addresses, are another silent threat. Sending even one message to a spam trap can trigger warnings. Some email services track how often you hit them. The more you do, the quicker reputation damage happens. Real-time verification tools help avoid this by detecting known spam traps, role accounts, and invalid domains before you send.

Cleaning Your List with Reliable Verification

Let’s be clear: you can’t rely on signup forms alone. Users enter typos, use fake domains, or pick throwaway addresses. A single typo like [email protected] can break deliverability. MailTester’s 98.9% accurate email verification identifies these issues instantly—whether you’re sending to one address or 50,000.

Use the bulk verification tool to clean an entire list before campaigns. Or integrate the real-time API into your signup flow or CRM, so every new address gets checked before storage. Both solutions test against SMTP, MX records, and domain reputation—even flagging high-risk disposable domains. The result? Fewer bounces, lower complaint rates, and better inbox placement.

Even without sending, you can test how your message lands by using inbox placement testing. This shows you whether your emails go to the inbox, spam, or get blocked—giving you a real-world signal of your sender reputation. It’s not just about the IP or DNS setup; it’s about proving you’re a legitimate sender, not a spammer.

Check your email list health today. Start with 100 free verifications—no risk, no expiry. The best time to improve deliverability is before your first email hit. You’re already verifying the IP, so extend that discipline to your list.

Final Checklist: Proper rDNS Setup and Deliverability Readiness

Ensure your sending IP’s reverse DNS (rDNS) resolves to a specific, valid domain like mail.company.com. This is the first signal recipients use to verify your identity.

Verify Key Components

The domain in rDNS must match the domain used in the SMTP HELO/EHLO command.
That domain must have a valid SPF record authorizing your IP range.
DKIM must be properly signed with a consistent selector and public key published in DNS.
DMARC policies must be published and enforced (p=quarantine or p=reject) to prevent spoofing.

A clean email list is non-negotiable: remove invalid, role-based (e.g. admin@, info@), and disposable email addresses before sending.

Test your delivery in real-world conditions using a tool that simulates actual inbox placement across major providers. Tools like MailTester’s inbox placement test provide insight into how your messages appear in inboxes—before you send to millions.

Sources

Since May 5, 2025, Microsoft Outlook requires SPF, DKIM, and DMARC from domains sending 5,000+ emails per day, rejecting non-compliant mail outright at the SMTP level with error 550 5.7.515. — Microsoft Outlook requirements (via MailOver bulk-sender requirements guide) (2025)
Only 22.9% of top domains enforce DMARC with p=quarantine or p=reject, while 29.2% remain in monitoring-only p=none mode that blocks nothing. — EasyDMARC 2026 DMARC Adoption & Enforcement Report (2026)

Keep reading

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

Can I set reverse DNS for an IP I don’t own?

No. Only the IP owner (usually your hosting provider or ISP) can configure the PTR record. You cannot override it without access.

Does having rDNS guarantee inbox delivery?

No. rDNS is one of many factors. Deliverability also depends on sender reputation, list hygiene, and authentication setup.

How long does it take for rDNS changes to take effect?

Typically 24 to 72 hours, depending on DNS TTL settings and provider propagation timelines.

What happens if my rDNS doesn’t match my SMTP domain?

Mailbox providers may flag the message as suspicious, leading to delivery failures or spam folder placement.

Can I use a subdomain for rDNS (e.g. mail.company.com)?

Yes, as long as the domain is owned and configured with a valid A record and DNS zone.

Does rDNS affect spam filtering directly?

Not directly. It’s a reputation signal. Inconsistent or missing rDNS increases the risk of being flagged by filter algorithms.

Is reverse DNS required for SMTP sending?

Not universally enforced, but it is a strong signal for reputable sending. Major providers expect it for bulk or authenticated email.

Can I change rDNS after sending emails?

Yes, but old messages may still carry the old rDNS. It’s best to set it before sending to avoid reputation issues.

What if my host blocks rDNS configuration?

Use a third-party email service with proper rDNS already set, such as SendGrid, Amazon SES, or Mailgun, especially for marketing sends.

How do I verify my rDNS is working correctly?

Use tools like `dig -x <your-ip>` or online DNS checkers to validate the PTR record returns the expected domain.