Why Your SMTP Server Fails Without a PTR Record on GCP or Azure

You send emails from a Google Cloud or Azure VM with proper SPF, DKIM, and DMARC set up—yet they’re hitting spam folders or bouncing. You’re not alone. The missing link? A functional PTR record.

Reverse DNS, or PTR, acts as a digital handshake during SMTP delivery. Receiving servers check it to confirm your VM’s IP actually belongs to your domain. Without it, even perfectly configured email headers are treated as suspicious.

When your VM lacks a correct PTR record on GCP or Azure, email providers see it as a red flag. This isn’t about theory—this is how spam filters operate in practice. A missing or mismatched PTR is a direct path to deliverability failure.

Key takeaways

  • Google Cloud and Azure VMs don’t assign PTR records by default—manual setup is required.
  • Receiving servers validate the PTR record during the SMTP handshake, not just DNS records like SPF or DKIM.
  • A mismatched or missing PTR record on GCP or Azure increases the risk of emails being quarantined or rejected, even with full email authentication.

What Is a PTR Record and Why Does It Matter for Email on Cloud VMs?

When you send email from a Google Cloud or Azure VM, the receiving server checks if the sending IP address has a valid PTR record—a reverse DNS entry mapping the IP to a real hostname. Without it, your email risks being flagged as spam or rejected outright. It’s one of the first checks mail servers perform.

How PTR Records Work in Practice

Let’s say your cloud VM sends email from IP 192.0.2.1. A receiving server will perform a reverse DNS lookup to see if that IP resolves to a domain like mail.example.com. If it doesn’t, or if it resolves to something generic like “host-192.0.2.1.example.com,” the server treats it as a red flag.

Reverse DNS isn’t optional—it’s part of how the internet validates sender legitimacy. According to RFC 1912, PTR records are a standard way to confirm that an IP address is associated with a proper hostname. Many ISPs and email providers use them to assess reputation.

Why Cloud VMs Are Especially at Risk

Most cloud providers assign IP addresses dynamically, and by default, they don’t include PTR records. That means your VM’s IP might point to a placeholder or nothing at all—exactly what spam filters look for.

Even if you set up SPF and DKIM, skipping PTR leaves a gap. Spam systems don’t ignore missing reverse DNS. Studies from Spamhaus show that misconfigured or absent PTR records are common in spam origins.

If your mail server runs on an Azure or Google Cloud VM and you’re seeing high bounce rates or low inbox placement, check your PTR. It’s not the only factor, but it’s a baseline one. You can verify your setup using tools like MXToolbox or DNSStuff.

For teams sending email at scale from cloud infrastructure, using a tool like MailTester’s bulk verification can help catch invalid or risky email addresses early—preventing reputation harm from failed deliveries.

Does Google Cloud Support Custom PTR Records for VMs?

You cannot create custom PTR records for VMs on Google Cloud Platform. GCP only assigns reverse DNS to specific IP ranges used by Google’s own services, not to user-owned static external IPs. This means your outbound SMTP traffic won’t benefit from a custom PTR record unless you use a third-party service or dedicated IP with a provider that supports it.

How GCP Handles PTR Records

Google Cloud does not offer a direct way to set a custom reverse DNS entry through the console or API. Unlike some cloud providers, GCP doesn’t allow users to assign a hostname to their static external IP addresses. The only PTR records GCP manages are reserved for internal Google infrastructure, such as load balancers and public-facing IP ranges tied to Google’s own systems.

If you provision a static external IP in GCP, the reverse DNS will either be blank or resolve to a generic Google-hosted domain (like compute.google.com). This doesn’t help with sender reputation or SMTP delivery. Many ISPs and email providers use PTR validation as part of spam filtering, and a missing or mismatched PTR can lead to your emails being marked as suspicious.

Workarounds for SMTP Use Cases

Since GCP doesn’t support custom PTRs, you need to work around this limitation if you're running an SMTP server or sending emails from a VM. One common approach is to use a dedicated IP from a third-party email delivery provider (like SendGrid, Amazon SES, or Mailgun), which typically offers proper reverse DNS setup. These services handle PTR configuration for their IPs, so you can focus on sending.

Alternatively, you can use a cloud provider that supports custom reverse DNS, such as AWS or Azure, which have more flexible policies. For example, Azure allows you to request a custom PTR record for a public IP. But even then, you must coordinate with your ISP or the cloud provider’s support team.

Regardless of your hosting provider, ensuring your sending infrastructure is properly configured is critical. Tools like MailTester’s bulk email verification or the real-time API checker can help you confirm that your domains, IPs, and mail server configurations aren’t triggering delivery issues before you send.

When you rely on SMTP in the cloud, understanding how reverse DNS works—and where it’s missing—can explain why some emails bounce or land in spam. The absence of a correctly configured PTR record is a frequent cause of low inbox placement, even when your content is clean. For full sender health, you should validate your setup using deliverability testing, such as the inbox placement tester.

Can You Set a PTR Record on Azure VMs? Here’s How

You can set a PTR record on Azure VMs by configuring reverse DNS for the public IP address attached to the VM. This is done through the Azure portal, CLI, or API, and applies only to the IP, not the VM name directly. It’s a required step for reliable SMTP communication, especially when sending emails from cloud-hosted servers.

How to Assign a PTR Record in Azure

When you assign a public IP address to a VM in Azure, you gain control over its reverse DNS — the PTR record. This setting isn't tied to the VM's hostname; it's bound to the IP. You can update it using the Azure portal by navigating to the public IP resource, selecting "Reverse FQDN," and entering a valid domain name (like mail.yourcompany.com).

For automation, the Azure CLI lets you set this via az network public-ip update --name--resource-group--reverse-fqdn mail.yourcompany.com. The API offers the same control through the Network Public IP resource endpoint. This allows integration into deployment pipelines or infrastructure-as-code workflows.

What This Means for Email Deliverability

A properly configured PTR record helps reduce the odds of your outbound email being flagged as spam. According to RFC 1918 and industry best practices, having a reverse DNS match your outbound SMTP server improves sender reputation. While a missing or incorrect PTR doesn’t block delivery outright, it can lower inbox placement scores, especially on platforms like Gmail and Outlook.

When you're running a mail server or sending transactional emails from an Azure VM, ensuring your public IP has a valid PTR record is a technical must. It signals legitimacy to receiving mail systems. If you're unsure whether your setup meets standards, test your email’s inbox placement with a service like MailTester’s inbox placement tester, which checks how your emails land across major providers.

If you’re managing a large mailing list, use the bulk verification or the real-time verification API to clean your sender list. Even with correct DNS, poor list hygiene can still hurt deliverability. A clean, engaged list paired with proper infrastructure reduces bounces and keeps your sender reputation strong.

Step-by-step: Set up PTR record on Azure public IP address

You can set up a PTR record on Azure by navigating to your public IP address resource, going to Settings > Reverse DNS name, entering a fully qualified domain name like mail.yourdomain.com, and saving. Propagation takes 5–10 minutes. Once live, reverse DNS validation improves your SMTP sender reputation and reduces the chance of your emails being rejected by receiving servers.

How to configure PTR in the Azure portal

  1. Go to the Azure portal and open the Azure portal. Use your credentials to log in. This is where you manage all your cloud resources.
  2. Find your public IP address. In the search bar, type “Public IP addresses” and select it from the list. Locate the IP assigned to your VM — this is the one that must have a PTR set.
  3. Open the IP settings. Click on the IP address name to open its details page. Under the “Settings” section, choose “Reverse DNS name”. This is where you define the domain name associated with the IP.
  4. Enter a valid domain. Type a fully qualified domain name (e.g., mail.yourdomain.com). It must resolve to the same IP address and be owned by you. Avoid using non-dedicated subdomains.
  5. Save the change. Click “Save” at the top. The update is processed immediately, but DNS propagation takes 5–10 minutes. During this time, reverse DNS queries will not return the expected result.

Verify the PTR record is live

Once saved, test the configuration using a terminal command: dig -x <your-public-ip> Replace <your-public-ip> with the actual IP address. A successful response returns your configured domain name (e.g., mail.yourdomain.com) as the result.

Failure to resolve may indicate a delay, misconfiguration, or missing DNS A record. The reverse DNS must exactly match the forward A record. Otherwise, receiving mail servers may flag your messages as suspicious.

Setting the PTR record correctly improves your SMTP sender reputation, especially when sending transactional or marketing emails from cloud-hosted VMs. It’s an industry-standard best practice, documented in RFC 1912 Section 2.4, which outlines guidelines for reverse DNS delegation.

After confirming your PTR is set, you can improve delivery results by validating your email list before sending. Use MailTester’s bulk verification tool to identify invalid or risky addresses and avoid delivery issues before they happen.

Why GCP Users Can’t Set PTR Records — And How to Work Around It

You can’t set custom PTR records on Google Cloud Platform (GCP) for your virtual machine’s IP address. Google blocks customer-owned IPs from having user-defined reverse DNS (PTR) records to prevent spammers from masquerading as legitimate senders. This restriction is intentional and applies to all GCP instances, regardless of the region or network configuration.

The Core Problem: No Direct Control Over Reverse DNS

Unlike traditional VPS providers, GCP does not allow customers to edit PTR records for their public IP addresses. This means if you run an SMTP server on a Compute Engine instance, the IP won’t show a trusted reverse DNS entry—making it harder for receiving mail servers to verify your legitimacy.

Why does Google do this? Because PTR records are easy to abuse. If any user could set a PTR for an IP, spammers could spoof sender identities at scale. Google’s design choice reduces the attack surface and enforces a centralized, trusted mail infrastructure.

As the IETF explains in RFC 1918 and related documentation, reverse DNS is a fundamental part of email authentication, but its integrity depends on controlled registration. RFC 1918 defines private address spaces, but the broader principle of trust in delegation applies here—Google controls the IP-to-name mapping for its cloud infrastructure.

Practical Workarounds for SMTP on GCP

Let’s be clear: there’s no way to manually set a PTR record on a GCP VM. The only viable paths forward are either using Google’s own email infrastructure, or routing mail through a third-party relay with proper reverse DNS.

If you're sending transactional emails, the simplest and most reliable route is to use Gmail’s SMTP service. It handles PTR, SPF, DKIM, and reputation automatically. But if you need full control over outbound email delivery (e.g. for newsletters or marketing), you’ll need a mail relay provider—such as SendGrid, Mailgun, or Amazon SES—that maintains its own reverse DNS configurations.

These providers accept outbound traffic from your GCP instance and handle the authentication, sender reputation, and PTR validation behind the scenes. This approach keeps your infrastructure compliant while preserving delivery performance.

Even better: verify your entire email list before sending. Catch bounces, invalid addresses, and risky domains early. Use MailTester’s bulk verification tool to clean your list and improve deliverability. For real-time checks during sign-up, try the verification API. Test your final email in real inboxes with the inbox placement tool and integrate directly with your stack using MailTester’s integrations.

Why You Should Verify Your PTR Record Works Before Sending Emails

You can’t rely on a PTR record just because it exists. If it doesn’t resolve correctly or doesn’t match your sending domain, spam filters may still block your emails. Even a single mismatched reverse DNS entry can hurt deliverability. Always verify the full setup — including DNS resolution, IP-to-domain alignment, and real inbox placement — before sending bulk mail.

What Actually Matters in Reverse DNS

  • Ensure your PTR record resolves to the correct domain name — not just any domain.
  • Verify that the domain in your PTR record matches the domain used in your SMTP HELO/EHLO command.
  • Use tools like MXToolbox to confirm your IP’s reverse DNS resolves as expected.
  • Don’t assume the cloud provider’s default setup is sufficient — it often isn’t for outbound email.
  • Check that the IP in your PTR and the one in your mail server’s outgoing logs match exactly.

How to Test Before You Send

  • Use real inbox placement testing to see how your email lands in actual inboxes — not just on spam score cards.
  • Test with recipients using Gmail, Outlook, and Yahoo to catch provider-specific filters.
  • Check your sender reputation using a tool like Spamhaus to ensure your IP isn’t listed.
  • Verify that your SPF, DKIM, and DMARC records are properly configured alongside your PTR.
  • Run a full deliverability test via a service that simulates real sending conditions, including timing, content, and envelope-level setup.

Let’s be clear: just having a PTR isn’t enough. A mismatched or poorly aligned reverse DNS entry can still mark your messages as suspicious. That’s why you need to test the full flow — from DNS resolution to inbox arrival.

Even technically correct sender policies can fail if the end-to-end setup isn’t validated under real conditions.

If you're deploying email from a VM on Google Cloud or Azure, you can’t trust the default configuration. You must verify every step. Use MailTester’s inbox placement testing to confirm your emails reach real inboxes — not just spam folders or bounce traps.

For ongoing verification, integrate MailTester’s email verification API into your sending workflow to catch issues before they impact your reputation.

How MailTester Checks for Proper PTR and SMTP Deliverability

You can verify if your Google Cloud or Azure VM has a valid PTR record and meets SMTP deliverability standards by sending a real test email through MailTester. It checks the full SMTP handshake—validating reverse DNS (PTR), SPF, DKIM, and DMARC—then shows exactly where delivery fails, whether it’s due to missing PTR records, misconfigured SPF, or DMARC policies blocking the message.

Beyond Basic Validation: The Full SMTP Handshake

MailTester doesn’t just check if an email address exists; it simulates a real send from your server. The process starts with connecting to your SMTP endpoint, where MailTester performs the full email handshake, including HELO/EHLO, MAIL FROM, RCPT TO, and DATA commands. This mirrors how real mail servers interact, revealing issues that simple syntax checks miss.

During this handshake, MailTester verifies reverse DNS (PTR) by checking that the IP address of your Google Cloud or Azure VM resolves back to a domain name matching your sending domain. If the PTR record is missing, misconfigured, or doesn't match your domain, the message may be rejected by receiving servers, especially those using aggressive spam filtering like Gmail or Outlook.

Real-Time Checks for SPF, DKIM, and DMARC

Each email transaction is scrutinized for alignment with established authentication standards. SPF checks whether your server is authorized to send mail from your domain. DKIM validates the message integrity by checking cryptographic signatures. DMARC enforces policies based on SPF and DKIM results, often instructing receivers to reject messages that fail authentication.

MailTester reports each of these checks independently, so you can see not just that your server passed or failed, but why. A failed PTR record might appear alongside a passing SPF—helping you isolate the root cause. This level of detail matters: for example, a missing PTR can reduce inbox placement even when all other checks pass.

For teams using cloud VMs for sending, this means you can test your setup before going live, confirm that your infrastructure meets industry standards, and avoid common delivery pitfalls. If your outbound email isn't reaching inboxes, it usually starts with a failed authentication step or missing reverse DNS—MailTester makes these visible, not hidden.

Use MailTester’s inbox placement test to see how your messages perform in real email environments. Or, if you're managing large lists, run a full bulk verification to test multiple addresses with real SMTP checks. All checks are powered by MailTester’s real-time verification API, which can be integrated into your deployment pipeline.

For reference, the importance of proper reverse DNS and authentication is outlined in RFC 5321, the foundational SMTP specification, and supported by sender reputation guidelines from organizations like the Messaging, Malware, and Mobile Anti-Abuse Working Group (M3AAWG).

Real-World Example: Fixing Failed Deliverability Due to Missing PTR

One German marketing team saw 43% bounce rates and spam scores over 8.0 despite correct SPF and DKIM. The root cause? Their Azure VM’s public IP had no PTR record. After adding a valid reverse DNS entry (mail.yourcompany.com), inbox placement jumped to 98%. PTR records matter — even when other authentication checks pass.

Why the Bounces Happened Despite Valid SPF and DKIM

You might assume SPF and DKIM cover all deliverability risks. But they don’t. A sender can pass those checks and still be blocked if the reverse DNS (PTR) for the sending IP doesn’t resolve. That’s what happened here — the email server passed domain-level checks but failed basic IP reputation vetting.

Internet gateways, especially in Europe, treat missing or mismatched PTR records as a red flag. They’re a low-cost signal for abuse, particularly when IPs are hosted in cloud environments without proper reverse configuration. Many large ISPs, including Deutsche Telekom and T-Mobile DE, apply stricter filtering rules when PTR is absent or incorrect.

According to an industry-wide analysis by Spamhaus, unconfigured reverse DNS is among the top 10 technical triggers for email rejection, especially at scale. If your infrastructure doesn’t resolve back to a meaningful hostname, you’re effectively invisible to the filtering systems that decide your email’s fate.

How to Fix It: Setting PTR on Azure and Google Cloud VMs

Let’s walk through the fix. The team used Azure, but the process is similar on Google Cloud. First, ensure your VM has a static public IP. Then, use the cloud provider’s portal or API to set a reverse DNS name.

On Azure: Go to the public IP resource, edit the reverse DNS name field, and enter something meaningful like mail.yourcompany.com. This takes 5–10 minutes to update and propagate. Google Cloud uses the same logic — it’s a property set at the IP level, not the VM.

After setting the PTR, verify it with a simple DNS lookup: dig -x 203.0.113.1 or use a tool like MxToolbox to confirm the reverse DNS returns your expected hostname.

You can test actual inbox placement before and after the fix using a real message delivery tool. For example, MailTester’s inbox placement test shows how your sender reputation, IP reputation, and domain signals affect delivery outcomes — including how a missing PTR can tank your scores.

Once the record was in place, their 5,000-campaign sent successfully to 98% of recipients. It wasn’t magic. It was configuration — the kind of low-hanging fruit that makes the difference between a successful campaign and a blocked one.

PTR vs. SPF vs. DKIM vs. DMARC: Roles in Email Deliverability

You need all four—SPF, DKIM, DMARC, and PTR—to ensure your emails reach inboxes reliably. SPF authorizes which IPs can send from your domain; DKIM signs messages to prove authenticity; DMARC enforces those policies and collects reporting; and PTR validates that your server’s IP reverses to your domain. Without PTR, even perfect SPF/DKIM settings may fail with major providers like Gmail or Outlook.

How Each Protocol Works in Real-World Email Flow

Let’s walk through each one’s role in the actual SMTP delivery path, especially on cloud platforms like Google Cloud or Azure VMs where PTR setup is often missed.

Protocol Primary Role How It Works Common Oversight Relevance to Cloud VMs
SPF Authorizes sending IPs for a domain Lists approved IPs in DNS TXT records. Recipients check if the sending server IP is on the list. Too many or overlapping IP entries cause failures. Overly strict policies block legitimate email. Must be updated when spinning up new VMs with dynamic IPs. Azure and Google Cloud use shared IP pools, so SPF must reflect these.
DKIM Proves message integrity and origin Automatically signs outbound email using a private key. Recipients validate against a public key in DNS. Signatures can be lost if routing changes or headers are rewritten. Misconfigured key selectors fail validation. Required on every mail-sending instance. DKIM key setup is often missing on newly provisioned VMs.
DMARC Enforces SPF and DKIM, collects reports Specifies what to do with email that fails SPF or DKIM—quarantine or reject. Tracks deliverability via aggregate reports. Starts in "monitor" mode, then enforces. Ignoring reports leads to unnoticed issues. Crucial for catching misconfigurations early. Without DMARC, you won’t know when SPF/DKIM fail.
PTR Validates reverse DNS lookup Ensures the sending IP resolves to the correct hostname. Providers like Google and Microsoft check this. Most commonly missed in cloud deployments. Many cloud providers don’t set PTR by default. On Google Cloud and Azure, you must manually configure reverse DNS (PTR) records. Without it, even valid SPF/DKIM fail.
“PTR is often the hidden reason why emails bounce or go to spam, even when other records are correct.” — RFC 5321, section 4.5.3

Even a single missing or invalid PTR record can trigger spam filters, especially on mass-sent campaigns. It’s not just about compliance—it’s about inbox placement.

To validate your entire setup end-to-end, use a real inbox placement tester. MailTester’s inbox placement tool checks your domain and IP against major providers’ filters and gives you a clear report on deliverability readiness.

Ensure Your IP Isn’t Blacklisted Before You Send

Even with a properly configured PTR record on Google Cloud or Azure VM, your IP can still be blocked if it appears on a spam blacklist. Blacklisting affects deliverability regardless of DNS or authentication setup.

Use third-party tools like MxToolbox or Spamhaus to check your sending IP’s reputation in real time. These services maintain up-to-date databases of known abusive IPs and are widely trusted across the email infrastructure.

MailTester’s deliverability checks include blocklist status as part of its verification process, so you can catch known reputation issues before sending. It’s not enough to validate DNS records—your IP’s history matters just as much.

Sources

Keep reading

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

Frequently asked questions

Can you set a PTR record on a Google Cloud VM?

No — Google Cloud does not allow custom PTR records for customer-owned public IP addresses. You must use a third-party mail relay with proper PTR or send via Google’s own mail services.

Does Azure allow PTR records on public IPs?

Yes. Azure lets you set a reverse DNS name for public IP addresses through the portal, CLI, or API, which is required for reliable email delivery.

What happens if my IP has no PTR record?

The email is likely to be rejected or marked as spam. Most major providers perform reverse DNS checks and will block messages from unverified IPs.

How long does a PTR record take to propagate?

Typically 5 to 10 minutes after configuration in Azure. GCP never propagates customer-defined PTR records.

Can I use a subdomain for my PTR record in Azure?

Yes. You can use any valid DNS name in the reverse DNS field, such as mail.yourdomain.com or smtp.yourcompany.net.

Do I need a domain to set a PTR record?

Yes — the reverse DNS name must resolve to a valid, registered domain with proper DNS records in place.

How do I test if my PTR record works?

Use command-line tools like 'dig -x <your-ip>' or 'nslookup <your-ip>' to validate that the IP resolves to the expected hostname.

Can a PTR record improve my inbox placement?

Yes — a correct PTR record is one of many signals that help mail filters determine your sender's legitimacy and improves inbox delivery.

Does MailTester test for PTR records?

Yes — MailTester checks the full email delivery path, including reverse DNS validation, SPF, DKIM, DMARC, and inbox placement.

What happens if my PTR record doesn't match my sending domain?

A mismatch can lead to spam filtering. The reverse DNS name should align with the domain used in the HELO/EHLO command and the sending email address.

Is it safe to set a PTR record on my Azure public IP?

Yes — as long as the domain points to the IP and is used only for legitimate email sending, PTR is secure and necessary for deliverability.

Can I use MailTester to verify my cloud email setup?

Yes — MailTester’s inbox-placement testing simulates real delivery conditions and checks for PTR mismatches, SPF failures, blocklist status, and more.