How do I configure reverse DNS (rDNS) with multiple IP addresses for email sending?
Michael Ko
Co-founder & CEO, Suped
Published 21 Jul 2025
Updated 16 Aug 2025
9 min read
Configuring reverse DNS (rDNS) can be tricky, especially when you are dealing with multiple IP addresses for email sending. Many email marketers and system administrators find themselves confused by the intricacies of DNS records, particularly how to map multiple IPs back to their sending domains. It is a common point of friction that can significantly impact email deliverability.
The core of the challenge often lies in understanding that a single A record typically points one hostname to one IP address. When you introduce additional dedicated IP addresses, the traditional setup seems to break down. How do you tell the world that multiple IP addresses belong to your authenticated sending domain without creating conflicts or misconfigurations?
My goal is to clarify the steps involved in properly setting up rDNS for a multi-IP email sending environment. We will cover the necessary DNS entries, how to interact with your email service provider (ESP) or hosting provider, and crucial verification steps to ensure your emails reach the inbox effectively.
Understanding rDNS and its role in email
Reverse DNS (rDNS), often referred to by its record type, PTR, serves as a critical component in email deliverability. While standard DNS (A records) translates domain names into IP addresses, rDNS performs the inverse: it translates IP addresses back into domain names. This reverse lookup is a fundamental check performed by receiving mail servers.
Mailbox providers (MBPs) use rDNS to verify the authenticity of incoming email. When an email server receives a message, it typically performs a reverse DNS lookup on the sending IP address. If the IP address does not resolve to a hostname, or if there is a mismatch between the rDNS hostname and the hostname declared by the sending server (EHLO/HELO), it raises a red flag. This can lead to your emails being flagged as spam, deferred, or even outright rejected. Proper forward-confirmed reverse DNS (FCrDNS) is essential for maintaining a good sender reputation.
The absence of a correct rDNS record is a common reason for email delivery failures and can land your IP on various email blocklists (or blacklists). Many spam filters, especially those used by larger mailbox providers, consider a valid rDNS record a baseline requirement for legitimate email traffic. Ignoring this configuration can severely impact your ability to reach your recipients' inboxes. To learn more about how to set up reverse DNS, consider consulting your hosting provider's documentation.
Configuring A records for multiple IP addresses
When you have multiple dedicated IP addresses for sending email, you cannot simply point one A record to all of them. Each IP needs a unique identifier, or hostname, for its reverse DNS lookup. This is where the concept of using distinct subdomains for each IP address comes into play.
The solution is to create a unique A record for each IP address, mapping it to a distinct hostname (or subdomain) that falls under your primary sending domain. For instance, if your authenticated (sub)domain is ml.yourdomain.com, and you have two dedicated IPs, you would create something like mta1.ml.yourdomain.com for the first IP and mta2.ml.yourdomain.com for the second. The prefix (mta1, mta2, etc.) is entirely up to you and your ESP.
Example A records for multiple IPsdns
A mta1.ml.yourdomain.com 192.0.2.1
A mta2.ml.yourdomain.com 192.0.2.2
A mta3.ml.yourdomain.com 192.0.2.3
This approach ensures that each of your dedicated IP addresses has a unique forward DNS entry. This is the first step your ESP or hosting provider will require to configure the reverse DNS for you. It's a common practice to map a dedicated IP to a specific subdomain for email sending. You can find more details on how one dedicated IP maps to multiple subdomains in our other guides.
Setting up PTR records with your provider
Unlike A records, which you manage in your own DNS zone, PTR records are managed by the owner of the IP address block. This typically means your Internet Service Provider (ISP), hosting provider, or Email Service Provider (ESP). Once you have set up the A records pointing your unique subdomains to each IP, you will need to contact your provider to request the configuration of the PTR records.
Your provider should then configure each IP address to resolve back to its corresponding unique hostname. For example, for IP 192.0.2.1, the PTR record should point to mta1.ml.yourdomain.com. This creates the necessary alignment for FCrDNS, where the forward lookup (mta1.ml.yourdomain.com to 192.0.2.1) matches the reverse lookup (192.0.2.1 to mta1.ml.yourdomain.com). This is a critical factor for preventing your emails from being flagged as spam.
Understanding PTR record alignment
A common point of confusion is whether the PTR record needs to point directly to your primary sending domain (e.g., yourdomain.com) instead of the specific hostname like mta1.ml.yourdomain.com. It is perfectly acceptable, and indeed the standard practice, for the PTR record to resolve to the specific hostname associated with that IP address, even if it includes a prefix like mta1. The key is that the hostname returned by the PTR record falls within the same domain space as your sending domain. This is considered an aligned rDNS setup by mailbox providers and will not typically cause deliverability issues.
This configuration establishes trust between your sending IP and your domain, a fundamental requirement for many spam filters. The goal is to ensure that a reverse lookup of your sending IP consistently points back to a legitimate hostname under your control. It helps prevent your mail from being put on a blocklist (or blacklist) by suspicious receiving servers.
Enhancing authentication with SPF for EHLO
Beyond rDNS, strengthening your email authentication includes properly configuring Sender Policy Framework (SPF) records. While SPF primarily authenticates the domain in the Return-Path header, some mail servers may also perform SPF checks on the EHLO (Extended Hello) value presented by the sending server. This is an extra layer of verification that can significantly bolster your sender reputation.
To address this, I highly recommend creating simple SPF TXT records for each of the unique hostnames you've set up for your IP addresses. This record would specifically authorize the corresponding IP address to send email on behalf of that particular hostname. This ensures that the EHLO value, which is typically the hostname, also passes SPF validation.
While your primary SPF record for your sending domain (e.g., ml.yourdomain.com) will contain includes for your ESPs, these additional SPF records for the specific MTA hostnames provide an extra layer of protection and clarity. This is particularly useful for niche mail servers with strict anti-spam policies. It's a subtle but important detail in advanced email deliverability. For more on this, check out how to set up an SPF record with multiple services.
Verifying your rDNS setup
After configuring your A records and getting your provider to set up the PTR records, the next crucial step is to verify that everything is working as expected. The most reliable way to do this is by sending a test email and inspecting its full headers. The Received header is where you will find the information necessary to confirm your rDNS setup. To check this, send an email from your configured IPs to a test inbox that allows you to view raw email headers, such as Gmail or Outlook.
Within the Received header, look for a line that includes your sending IP address. This line typically shows the hostname that the sending server presented (EHLO value), followed by the IP address in square brackets, and then the rDNS hostname (the result of the PTR lookup for that IP) in parentheses. For proper FCrDNS, the hostname inside the parentheses should match the EHLO value. It’s also important that the rDNS hostname belongs to your domain space.
Example of a correctly configured Received header
Received: from mta1.ml.yourdomain.com (mta1.ml.yourdomain.com [192.0.2.1])
by mx.recipient.com with ESMTP id ABCDEFGHIJKLMNOPQRSTUVWXYZ
for <yourrecipient@recipient.com>;
Date, Time -Timezone
If these values align as shown in the example above, your rDNS is correctly configured for that specific IP. If they do not match, or if the rDNS hostname is generic or missing, it indicates a problem that needs to be addressed with your provider. Remember, consistent and accurate DNS records are fundamental for ensuring your emails bypass spam filters and maintain a healthy dedicated IP reputation.
Incorrect vs. correct rDNS configuration for multiple IPs
Scenario: Multiple IPs, one domain
A records: One A record mail.yourdomain.com pointing to multiple IPs (e.g., 192.0.2.1 and 192.0.2.2).
PTR records: Provider attempts to set 192.0.2.1 to mail.yourdomain.com and 192.0.2.2 to mail.yourdomain.com.
Potential deliverability impact
Confusion for MBPs: While DNS can technically allow one A record to point to multiple IPs, it creates ambiguity for rDNS. This can lead to some mail servers flagging it.
Mismatch concerns: Older or stricter EU ISPs might have issues with any perceived mismatch in the FCrDNS process, impacting deliverability.
Blacklisting risk: Increased risk of being placed on a blocklist (or blacklist) due to improper authentication and potential spam association.
Best practice: Multiple IPs, unique hostnames
A records: Create unique hostnames for each IP (e.g., mta1.ml.yourdomain.com to 192.0.2.1, mta2.ml.yourdomain.com to 192.0.2.2).
PTR records: Provider configures each IP to resolve to its unique, matching hostname (192.0.2.1 to mta1.ml.yourdomain.com).
Positive deliverability impact
Clear FCrDNS: Each IP has a clear, unambiguous FCrDNS setup, which is preferred by MBPs.
Enhanced trust: Demonstrates careful configuration and legitimate email sending practices, building sender trust.
Reduced blocklisting: Minimizes the risk of being added to an email blacklist (or blocklist) due to DNS authentication failures.
Conclusion: A robust rDNS setup is key
Configuring rDNS with multiple IP addresses, while seemingly complex, boils down to a clear, one-to-one mapping between each sending IP and its unique hostname. By setting up distinct A records for each IP and ensuring your provider configures matching PTR records, you establish a strong foundation for email authentication. This, combined with proper SPF records for your EHLO values, significantly boosts your deliverability and protects your sender reputation.
Always verify your setup by checking email headers. This proactive approach allows you to quickly identify and rectify any misconfigurations, ensuring your messages consistently reach your recipients’ inboxes. Proper rDNS is not just a technical requirement, it's a critical trust signal for mailbox providers and a cornerstone of successful email marketing.
Views from the trenches
Best practices
Always use a unique hostname (subdomain) for each dedicated IP address.
Ensure the PTR record set by your provider resolves to the specific hostname associated with that IP.
Add simple SPF TXT records for each hostname (EHLO value) to enhance authentication.
Common pitfalls
Attempting to use a single A record for multiple IP addresses without unique hostnames.
Expecting PTR records to resolve to the primary domain instead of the specific hostname.
Not verifying rDNS configuration after setup, leading to hidden deliverability issues.
Expert tips
Consider using a consistent naming convention for your hostnames, such as 'mtaX' or 'mailX', for clarity.
If using an ESP, confirm their specific requirements for rDNS setup, as processes can vary.
Be aware that different ISPs, especially in Europe, may have varying strictness on DNS checks.
Expert view
Expert from Email Geeks says they use specific prefixes like mta.ml.hostname.com and mta2.ml.hostname.com when setting up dedicated IPs, which aligns with common practice.
2022-06-01 - Email Geeks
Marketer view
Marketer from Email Geeks says that while one A record can technically map to two IPs, it's generally not recommended for email sending due to potential mismatch flags from online tools and strict ISPs.
Gmail or 
Outlook.
