Why Your Mail Starts Temp-Failing After You Rename a Cloud VM or NAT Device

You rename a cloud VM or update a NAT device hostname. Everything looks fine. A few hours or days later, mail to external addresses starts bouncing. The bounce messages are vague. You check SPF, DKIM, and DMARC. All passing. So what is going on? The culprit is almost certainly a stale PTR record. ### What is a PTR record? Most people know that DNS translates hostnames to IP addresses. That is called forward DNS. PTR records do the opposite: they translate an IP address back to a hostname. This is called reverse DNS or rDNS. During an SMTP conversation, a receiving mail server can look up the PTR record for your sending IP. It then checks whether that hostname matches what your server advertises when it introduces itself in the EHLO command. When the two match, the connection passes a basic trust check called forward-confirmed reverse DNS (FCrDNS). Many mail receivers run this check automatically. Here is the part that surprises people: this check operates completely independently of SPF, DKIM, and DMARC. Those protocols answer the question "is this sender authorized to send as this domain?" PTR checks answer a different question: "does this server's hostname match what it claims to be?" A server can pass SPF, DKIM, and DMARC with perfect scores and still fail a PTR check. ### Why renaming infrastructure breaks mail delivery Cloud providers set initial PTR records automatically when you spin up a VM or configure a NAT device. The PTR typically reflects the original hostname or follows a provider-specific pattern. When you rename the VM or NAT device, two things can go wrong. First, the cloud provider may not update the PTR record automatically. AWS, for example, assigns PTR records that cannot be changed without contacting support, which means renaming an EC2 instance leaves the old PTR in place. Second, even when the provider does update the PTR on rename, the change takes effect only from that moment forward -- any mail server that looked up the PTR before the rename may have cached the old value. The result: your mail server advertises itself as new-hostname.cloudprovider.net in EHLO, but the PTR for your IP still resolves to old-hostname.cloudprovider.net. Receivers that check FCrDNS see a mismatch and either temp-fail the message, soft-reject it, or treat it as higher-risk. Not all receivers run PTR checks. That is why some destinations suddenly stop accepting your mail while others continue fine. It depends on each receiver's spam filtering policy. ### What the bounce messages look like This is where the problem gets frustrating. Unlike SPF, DKIM, or DMARC failures, a PTR mismatch does not produce a clear, specific bounce code pointing at DNS. Common vague responses: - "421 Service temporarily unavailable" - Connection timeout with no explanation - Temporary delivery delay followed by a hard bounce - Generic SMTP error codes that do not reference reverse DNS You end up checking SPF, DKIM, and DMARC, finding nothing wrong, and concluding the problem must be on the receiver's end. It usually is not. ### How to diagnose a PTR mismatch Run these two commands on your sending mail server or any system that can reach it: **Step 1: Find your sending hostname** Connect to your mail server on port 25 and run EHLO, or look at your mail server configuration to see what hostname it advertises. Most MTAs will log their EHLO hostname during a test connection: ``` $ telnet your.mail.server 25 EHLO test.example.com ``` Note the hostname your server actually sends. **Step 2: Check what the PTR says** Run a reverse lookup on your sending IP: ``` $ dig -x 203.0.113.50 +short # or $ host 203.0.113.50 50.113.0.203.in-addr.arpa domain name pointer old-hostname.cloudprovider.net. ``` If the hostname from Step 1 does not match the PTR result, you have found the problem. **Step 3: Check your cloud provider's PTR policy** Each major cloud provider handles PTR records differently: | Provider | PTR auto-updates on rename? | Custom PTR allowed? | |---|---|---| | AWS EC2 | No | Via support ticket only | | Google Cloud | Yes (via console rename) | Via Cloud DNS | | Azure | Yes (when FQDN changes) | Via Azure DNS | | DigitalOcean | No | Yes, via control panel | | Hetzner | No | Yes, via robot panel | ### How to fix it **Option A: Update the PTR record** If your cloud provider allows custom PTR records, update them to match the hostname your mail server advertises. In Azure, you do this by setting the PTR through Azure DNS on the reverse lookup zone. In DigitalOcean, you set it in the networking section for each droplet. In Google Cloud, you manage it via Cloud DNS reverse lookup zones. If your provider does not allow custom PTR records, skip to Option B or C. **Option B: Use a dedicated mail relay with a stable hostname** Rather than sending mail directly from cloud VMs that change, route your mail through a dedicated relay with a fixed hostname and a PTR record that never changes. Many third-party SMTP services and mail relay providers offer this out of the box. This also gives you a stable sending identity that survives infrastructure changes entirely. **Option C: Contact your provider** In AWS, you can submit a reverse DNS request through a support ticket. AWS will update the PTR for your Elastic IP if the hostname meets their naming requirements. This takes 1-2 business days. **How long until the fix works?** PTR record changes can take up to 48 hours to propagate fully. ISPs cache reverse DNS results, and some have TTLs of 24-48 hours. During this window, you may still see intermittent failures even after submitting the correct PTR record. Do not assume the problem is fixed the moment you update DNS -- wait at least 24-48 hours before concluding the fix is complete. ### How DMARCFlow helps narrow the search PTR mismatches do not cause DMARC failures directly. SPF, DKIM, and DMARC can all pass cleanly while a PTR check is failing at the SMTP layer. So you will not see a PTR problem show up as a DMARC failure in your aggregate reports. What you might see instead is harder to miss: mail leaving your server, not arriving at specific domains, and your DMARC reports showing clean authentication across the board. The messages go out but the receivers do not accept them. That gap between "auth passing" and "delivery failing" is a useful signal. DMARCFlow aggregate reports help you spot exactly this pattern. When your DMARC data shows normal authentication pass rates but delivery rates to specific domains have dropped, that discrepancy tells you to look at the SMTP layer. PTR mismatches are a common cause after a rename event. The DMARC report correlation is not a direct PTR diagnosis, but it is a fast way to know something changed in your infrastructure before users start complaining. ### Bottom line Before you spend hours debugging SPF, DKIM, and DMARC after mail starts bouncing, run a PTR lookup on your sending IP: ``` dig -x YOUR_SENDING_IP ``` If the hostname it returns does not match what your mail server advertises, and you recently renamed your cloud VM or updated a NAT device, you have found your answer. Fix the PTR record, use a dedicated mail relay with a stable hostname, or contact your provider to update the reverse DNS. That is faster than continuing to hunt for a problem in the wrong layer. ### FAQ **What is a PTR record and why does it matter for email?** A PTR record maps an IP address back to a hostname. During SMTP, receiving servers often check whether the PTR hostname matches the EHLO hostname your server sends. A mismatch can cause temp-fails even when SPF, DKIM, and DMARC all pass. **Can mail fail because of a PTR mismatch even if SPF, DKIM, and DMARC all pass?** Yes. PTR checks are separate from email authentication protocols. A server can have perfect SPF, DKIM, and DMARC results and still fail a PTR check if the hostname does not match. **How do I check if my PTR record matches my server hostname?** Run `dig -x YOUR_IP` or `host YOUR_IP` to see what the PTR says. Then compare it to what your mail server advertises in its EHLO greeting. If they differ, you have a mismatch. **How long does a PTR record change take to propagate?** PTR changes can take up to 48 hours to propagate fully. ISP caching of reverse DNS results means some receivers may still see the old value for up to two days after the change. **Will fixing the PTR record fix all my delivery problems?** Not necessarily. PTR mismatches are one cause of temp-fail messages, but not the only one. If fixing the PTR does not resolve the issue within 48 hours, check other factors: sending IP reputation, HELO/EHLO hostname configuration, and whether your cloud provider blocks port 25 outgoing.