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 22 May 2026
8 min read
Summarize with
Configure reverse DNS for multiple sending IPs by giving every IP its own hostname, publishing a forward A or AAAA record for that hostname, then asking the IP owner to publish the PTR record for that IP back to the same hostname. For two dedicated IPs, a clean pattern is mta1.ml.example.com for 123.234.123.234 and mta2.ml.example.com for 111.222.111.222.
The PTR does not need to return the exact authenticated sending domain, such as ml.example.com. It should return a real hostname that resolves forward to the same IP, and that hostname should sit in your sending domain space when you control the dedicated IP branding. I prefer one hostname per IP for email because it is easier to audit and avoids confusing strict receiver checks.
- Use one host: Create mta1, mta2, and mta3 style hostnames for separate IPs.
- Ask the IP owner: Your DNS zone controls forward records, but the IP owner controls PTR.
- Keep the domain space: Dedicated branded IPs should use names under your sending domain.
- Verify with mail: Send a real test message and inspect the Received header, not only DNS.
The correct rDNS pattern
Reverse DNS works backwards from normal DNS ownership. You can publish mta1.ml.example.com in your normal DNS zone, but you usually cannot publish the PTR record yourself. The PTR lives in the reverse DNS zone for the IP address range, so the ESP, cloud host, ISP, or network team that owns the address space has to set it.
When a provider asks you to create an A record first, they are usually checking that the hostname you want in PTR resolves to the IP. That forward record is the proof step. After they create the PTR, a receiver can check both directions.
The short rule
For email, keep a one-to-one relationship between the sending IP and the hostname used for PTR and EHLO.
- Forward: mta1.ml.example.com resolves to 123.234.123.234.
- Reverse: 123.234.123.234 resolves back to mta1.ml.example.com.
- EHLO: the mail server introduces itself with that same hostname.
- SPF: the EHLO hostname can publish a tight SPF record for that IP.
Forward DNS recordsdns
mta1.ml.example.com. 300 IN A 123.234.123.234 mta2.ml.example.com. 300 IN A 111.222.111.222 mta3.ml.example.com. 300 IN A 134.211.211.211 mta1.ml-de.example.com. 300 IN A 121.212.121.212
PTR records to request from the IP ownertext
123.234.123.234 -> mta1.ml.example.com 111.222.111.222 -> mta2.ml.example.com 134.211.211.211 -> mta3.ml.example.com 121.212.121.212 -> mta1.ml-de.example.com
Do not worry that the PTR names keep the prefixes. That is normally correct. The receiving server sees mta1.ml.example.com in rDNS and can confirm it points to the connecting IP. It does not need every PTR to collapse back to ml.example.com.
What receivers are checking
Most receivers do not use rDNS as the DMARC identifier. They use it as an infrastructure signal. The practical checks are whether the connecting IP has a PTR record, whether the PTR hostname looks real, whether that hostname resolves forward to the same IP, whether EHLO uses a sensible hostname, and whether SPF, DKIM, and DMARC authenticate the visible message domain.
If the terms are still fuzzy, the shorter explainer on rDNS and FCrDNS is a useful reference before changing production DNS.
|
|
|
|
|---|---|---|---|
PTR | Hostname found | Missing PTR | IP owner |
Forward | Same IP | Wrong IP | DNS owner |
EHLO | Known host | Generic host | MTA owner |
SPF | IP allowed | No TXT | DNS owner |
DMARC | Pass | Fail | Sender |
The checks are separate, but receivers read them together.
Receiver check flow for rDNS, EHLO, and message authentication.
Should I use one shared hostname?
DNS permits one hostname to have multiple A records. That is normal for many web systems, but I avoid it for email sending IP identity. Some tools and smaller receivers do a simple forward, reverse, then forward check. A shared hostname with several IPs can create noisy results even when the setup is technically legal.
One hostname per IP
- Clean check: each PTR hostname resolves to one clear sending IP.
- Easier operations: IP warmup, routing, and complaint tracking stay separated.
- Better receiver story: strict checks see a consistent host and IP pair.
- Clear headers: Received lines show exactly which server handed off mail.
One hostname for several IPs
- Legal DNS: a hostname can return several addresses.
- Harder audits: a failed lookup takes longer to trace to one IP.
- Checker noise: simple validation scripts can complain about mismatches.
- Weak separation: pools, regions, and traffic types become less clear.
For operational work, I keep a simple mapping file: one IP, one PTR host, one EHLO value, one SPF record for that EHLO host. The same principle is covered in this IP hostname check guide.
Step-by-step setup
I set up multiple sending IPs in this order. The key is to decide the naming pattern before asking the provider to publish PTR, because changing PTR later usually takes support time and propagation time.
- Choose hostnames: Use names like mta1.ml.example.com, mta2.ml.example.com, and mta3.ml.example.com.
- Publish forward DNS: Add one A record for each IPv4 address and one AAAA record for each IPv6 address.
- Request PTR: Ask the IP owner to point each IP back to its matching hostname.
- Set EHLO: Configure the MTA to introduce itself with the same hostname for that IP.
- Add EHLO SPF: Publish a narrow SPF record on the EHLO hostname when receivers check it.
- Keep message auth: Maintain SPF, DKIM, and DMARC on the visible message domain too.
- Monitor reputation: Watch authentication, bounce, complaint, and blocklist signals after rollout.
SPF records for EHLO hostnamesdns
mta1.ml.example.com. 300 IN TXT "v=spf1 ip4:123.234.123.234 -all" mta2.ml.example.com. 300 IN TXT "v=spf1 ip4:111.222.111.222 -all" mta4.ml.example.com. 300 IN TXT "v=spf1 ip6:2001:db8::10 -all"
Do not edit PTR in the wrong zone
A PTR record for 123.234.123.234 is not created under example.com. It is published in the reverse DNS zone for the IP space. If the IP belongs to an ESP or hosting provider, their support team or control panel must publish it.
How to verify the result
After DNS propagates, send a real message through the IP and inspect the headers. A quick email test helps because it shows the path, authentication results, and sending IP in one report.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
In a Received header, the first hostname after "from" is usually the EHLO value. The hostname inside the parentheses is often the rDNS result, followed by the connecting IP in brackets. Header formats differ, so trust the lines added by receivers or systems you control.
Header line to inspecttext
Received: from mta1.ml.example.com (mta1.ml.example.com [123.234.123.234]) by mx.receiver.example with ESMTPS; Fri, 22 May 2026 10:15:00 +0000
The expected result is boring: EHLO is mta1.ml.example.com, rDNS is mta1.ml.example.com, and the IP is 123.234.123.234. If EHLO is a generic provider host or a name that does not exist in DNS, fix the MTA setting or ask the ESP what hostname it uses for that sending pool.
For a broader DNS view, run a domain health check after the change. That catches related SPF, DKIM, DMARC, and DNS issues that often appear during sending-domain work.
In Suped, open the domain record detail diagnostics view after the PTR change. I use it to confirm DNS record status while DMARC reports show whether real traffic is passing.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
How Suped helps after DNS is correct
rDNS setup itself happens at the DNS or IP provider, but monitoring is where teams lose time. Suped brings DMARC monitoring, SPF and DKIM visibility, blocklist monitoring, hosted SPF, hosted DMARC, hosted MTA-STS, and real-time alerts into one workflow.
For most teams, Suped is the best overall DMARC platform because it connects DNS status, authentication results, blocklist (blacklist) signals, and sender inventory. That matters after adding IPs because a clean PTR record does not tell you which source is failing DKIM, which source is missing SPF, or which IP has started to attract blacklist listings.
Where Suped fits
- Source visibility: see which platforms send for each domain and subdomain.
- Issue detection: turn authentication failures into specific steps to fix.
- Hosted SPF: manage senders and SPF lookup limits without repeated DNS edits.
- Policy staging: move DMARC policy forward with alerts and change tracking.
- MSP scale: manage many client domains from one multi-tenant dashboard.
Common mistakes to avoid
The mistakes I see most often come from mixing the roles of A records, PTR records, EHLO, and DMARC. They are related, but each one answers a different question for the receiver.
- All PTRs to one name: This creates avoidable ambiguity across a pool of dedicated IPs.
- Only adding A records: Forward DNS alone does not create reverse DNS for the IP.
- Ignoring EHLO: Receivers can record and check the hostname your server announces.
- Using unrelated domains: Dedicated branded sending should keep PTR names in your domain space.
- Forgetting IPv6: IPv6 sending needs AAAA, PTR, EHLO, and SPF treatment too.
- Treating rDNS as DMARC: rDNS supports trust checks, but SPF or DKIM must pass for DMARC.
Views from the trenches
Best practices
Use one stable hostname per sending IP so PTR, A, EHLO, and headers stay easy to verify.
Keep the PTR hostname under your sending domain space when dedicated IP branding is available.
Add tight SPF records on EHLO hostnames when the server presents those names to receivers.
Verify headers from a real message, because DNS checks alone do not show the EHLO value.
Common pitfalls
Pointing several IPs at one hostname creates avoidable noise in forward and reverse checks.
Asking the public DNS host to add PTR records fails when the IP owner controls reverse DNS.
Expecting the PTR to equal the exact DKIM domain causes unnecessary rework and tickets.
Skipping IPv6 leaves a parallel sending path with no reverse DNS or matching SPF policy.
Expert tips
Name hosts by pool or region only when those labels still make sense after scaling.
Keep low TTLs during setup, then increase them after PTR and forward checks pass cleanly.
Document each IP, PTR host, EHLO name, and SPF value in one change record before rollout.
Use DMARC reports to confirm which sources send after the DNS changes are published.
Marketer from Email Geeks says each dedicated sending IP should have its own hostname, such as mta1 or mta2, and the provider should use that hostname for the PTR.
2022-06-01 - Email Geeks
Marketer from Email Geeks says a PTR value such as mta1.ml.example.com is fine when the authenticated mail domain is ml.example.com, because both names live in the same domain space.
2022-06-21 - Email Geeks
My practical answer
Use multiple hostnames for multiple IPs. Make the relationship one-to-one: A or AAAA hostname to IP, PTR IP back to hostname, EHLO uses the hostname, and the EHLO hostname has a narrow SPF record when that check happens. The PTR does not need to equal the exact authenticated sending domain.
After that, verify with real messages and monitor DMARC, DNS, and blocklist (blacklist) signals over time. rDNS does not replace SPF, DKIM, or DMARC, but it removes a common receiver complaint and makes each sending IP easier to explain.
