Why AWS SES Needs PTR Record

What happens when AWS SES rejects your email due to a PTR mismatch?

You sent an email through AWS SES. It worked last week. Now it’s bouncing with a hard failure. Not a typo. Not a spam filter. The error says: “Reverse DNS (PTR) record does not match sending hostname.” You’re not sure what that means—but you know it’s blocking your messages.

Here’s the raw truth: AWS SES won’t let you send if your IP’s reverse DNS doesn’t match your configured sending domain. It’s not a glitch. It’s not arbitrary. It’s a core part of how Amazon enforces sender identity to protect its reputation and keep spam out. If your PTR record doesn’t resolve to your sending hostname—your message won’t go through.

Understanding why AWS SES requires reverse DNS PTR record to match sending hostname isn’t just technical trivia. It’s the difference between sending mail reliably and being stuck in a delivery black hole.

Key takeaways

AWS SES requires the reverse DNS (PTR) record for your sending IP to match the hostname you configure in the SES interface—failure to do so results in immediate email rejection.
Even if your emails pass SPF, DKIM, and domain authentication, a PTR mismatch will block delivery because Amazon enforces sender identity at the IP level.
Setting up a valid PTR record is mandatory for outbound email via AWS SES and must be coordinated with your ISP or hosting provider, not just managed in your DNS zone.

How does reverse DNS PTR record verification work in AWS SES?

When you send email through AWS SES—whether from a verified mailbox or via SMTP—Amazon checks that the IP address used to send the message has a reverse DNS (PTR) record that matches the sending hostname you’ve declared. This isn’t optional. If the PTR record doesn’t match exactly, your message is rejected with a hard bounce, usually logged as 550 5.7.1 Message rejected due to missing or invalid reverse DNS. This is Amazon’s way of enforcing sender authenticity at the network level.

What AWS SES Checks During Send

Here’s how it works: when you configure SES to send from a domain like mail.yourcompany.com, you must also ensure that the underlying IP address (used to deliver your message) has a PTR record pointing back to that same hostname. Amazon performs this check in real time during the SMTP handshake. If the IP's PTR doesn't resolve to mail.yourcompany.com, the connection is dropped.

This is a cryptographic check, not just a name match. The reverse lookup must return a hostname that corresponds to the one you declared in SES. A mismatch—even a slight one, like using mail.yourcompany.com vs. smtp.yourcompany.com—will trigger rejection. It’s a strict, automated enforcement of the sender’s identity.

Why This Matters for Deliverability

Reverse DNS alignment prevents spoofing and confirms that the sending infrastructure belongs to the domain claiming it. This is a core principle of email authentication, documented in RFC 2821, which outlines the SMTP protocol's requirements for sender validation. Major providers like Gmail, Yahoo, and Microsoft depend on PTR records for inbox placement decisions, which is why AWS enforces it.

If you’re setting up SES and see 550 errors with “invalid reverse DNS,” the issue is almost always a missing or misconfigured PTR record. You can verify this using tools like MXToolbox or the dig command. If your ISP or cloud provider doesn’t allow PTR setup, you’ll need to use a dedicated IP address with reverse DNS configured before sending in bulk.

Before you send high-volume campaigns, test your sending infrastructure with a real inbox-placement tool to catch these issues early. MailTester’s inbox placement tests simulate delivery across major providers and expose authentication mismatches like this one, so you can fix them before they hurt your reputation.

Why does AWS SES require PTR records—security or spam control?

AWS SES requires a reverse DNS (PTR) record matching the sending hostname to reduce abuse on shared infrastructure. Without it, attackers could spoof trusted domains from known IP addresses, evading basic detection. PTR acts as a weak but essential signal that the IP is managed by the domain owner—not a random third party—helping block impersonation and spam.

It’s about preventing spoofing, not just spam filtering

Let’s be clear: this isn’t just about spam control. It’s about accountability. When you send mail from AWS SES, you’re using a shared pool of IP addresses. If anyone could send from any IP and claim to be a legitimate domain, malicious actors could impersonate banks, retailers, or even government bodies. A PTR record ties the IP back to the domain you’re sending from—creating a basic audit trail.

Without a valid PTR, no email provider will trust that your sending infrastructure is genuinely associated with the domain. It’s not foolproof—spammers can still bypass it with fake PTRs—but it stops casual abuse. The requirement is rooted in industry practice, not arbitrary policy.

The SMTP specification (RFC 5321) sets a baseline for how mail servers should validate incoming connections. While it doesn’t mandate PTR checks, it acknowledges that reverse DNS is a foundational layer in sender reputation. Providers like AWS SES implement it to protect both their network and the broader ecosystem.

Why a weak signal matters

Yes, PTR is a weak signal—it can be forged, updated, or misconfigured. But in the context of shared infrastructure like AWS SES, it’s a necessary baseline. It ensures that only someone who can control the DNS record for a domain can send from its claimed identity, reducing the risk of unauthorized use.

Without this check, spoofing would be trivial. Imagine a threat actor using a well-known IP address associated with a trusted service, yet claiming to be your company. With a PTR record tied to your domain, AWS SES can validate this before sending. That alone reduces the chance of your brand being used in phishing or spam campaigns.

If you’re managing your own sending infrastructure or using a third-party service that doesn’t enforce this, you’re leaving gaps. But even if your delivery isn’t blocked today, you’re trading long-term inbox placement for short-term convenience. That’s why tools like MailTester’s bulk verification help you catch invalid, misconfigured, or risky addresses before they impact your sender reputation.

What happens if your PTR record doesn't match your sending hostname?

If your PTR record doesn’t match your sending hostname, AWS SES will reject the email at the network level before any content filtering or spam scoring occurs. This results in a hard bounce—delivery fails completely, your sender reputation remains untouched, but your message never reaches the inbox. You won’t see this failure in typical email logs unless you’re monitoring raw SMTP responses or using tools like MailTester to test deliverability.

Rejection happens before content checks

Reverse DNS (PTR) validation is part of the SMTP handshake. When AWS SES receives a connection, it checks the remote IP’s PTR record to confirm it resolves to a domain matching the HELO/EHLO hostname you used to initiate the session. If there’s a mismatch—say, your IP points to mail.example.com but you claim to be sending from smtp.amazon.com—the connection is dropped immediately.

This happens before any spam score, sender reputation check, or content analysis. The email is treated as a network-level failure, not a content or reputation issue. As a result, you get no feedback on message content or domain standing—just a hard bounce.

Why this is harder to detect

Because the rejection occurs early in the SMTP process, most standard email tracking tools only record a bounce after the session ends. Without access to raw SMTP logs or a specialized test suite, you might believe your emails are being delivered when they’re actually being blocked before processing.

Tools like MailTester’s inbox placement tester can simulate real sender sessions and reveal these network-level failures, helping you catch PTR mismatches before they impact campaigns. This is especially important for high-volume senders relying on AWS SES.

The practice is rooted in industry standards: RFC 5321 (SMTP) requires that the PTR record of a sending IP match the HELO identifier, though enforcement varies between providers. According to the Messaging, Malware, and Mobile Anti-Abuse Working Group (M3AAWG), misaligned HELO/PTR records are a common indicator of spoofing or compromised infrastructure.

How to verify if your PTR record matches your sending hostname

You can verify if your PTR record matches your AWS SES sending hostname by querying your public IP address using command-line tools like dig -x or nslookup. The resulting hostname must match the one you configured in AWS SES exactly—no variations in subdomains or syntax. If it doesn’t, update the reverse DNS record with your cloud provider.

Step-by-step verification process

Find your AWS SES sending IP address. This is typically the public IP your SES outbound mail is sent from. You can find it in the AWS SES console under "Sending Statistics" or via the SES API.
Run dig -x <your-ip> or nslookup <your-ip>. Replace <your-ip> with the actual IP. This queries the reverse DNS (PTR) record associated with your IP address. It returns a hostname linked to that IP.
Compare the result to your configured sending hostname. The output must match exactly—e.g., if you set mail.example.com in SES, the PTR record must resolve to mail.example.com. A mismatch like smtp.example.com or example.com will trigger deliverability issues.
If the match fails, contact your cloud provider. AWS itself does not allow you to manage PTR records for its IP ranges. You must contact your cloud network administrator or hosting provider (like AWS EC2, Elastic IPs, or a VPC with custom routing) to request the PTR update.

Why alignment matters

Many ISPs and email providers check the PTR record as part of sender reputation validation. A mismatch creates a red flag—spammers often spoof IPs without valid reverse DNS. This can result in your emails being rejected or marked as spam. The SMTP RFC 5321 mandates that servers validate sending IP addresses, and PTR records are a standard part of that process.

The 4 steps described in “Step-by-step verification process”, in order.

If you’re not confident in setting up the correct reverse DNS, you can test your configuration with a tool like MxToolbox, which offers free IP and domain diagnostics. For deeper validation, especially before scaling outbound emails, you can use deliverability testing tools like MailTester’s inbox placement test to see how your messages perform across real email providers.

Once verified, the alignment between your PTR record and sending hostname reduces bounce risk, supports long-term sender reputation, and improves inbox placement. This is not optional—it’s a core requirement for reliable email delivery at scale.

Common configuration mistakes that cause PTR mismatches

Using AWS SES without a properly configured reverse DNS (PTR) record that matches your sending hostname often results in rejected emails or poor deliverability. The most frequent issues stem from shared IPs without valid PTRs, mismatched domains in the hostname and PTR, or deploying from a region with unverified outbound IPs. Let’s break down what goes wrong — and how to fix it.

Shared IPs without PTRs

You're using a low-tier VPS or shared hosting provider that doesn’t allow custom reverse DNS, so your outbound IP has no PTR record.
Without a PTR, AWS SES’s outbound mail fails validation checks on receiving servers. This is a common barrier for small teams testing email delivery.
For reference, RFC 1918 defines private IP ranges, but proper reverse DNS is required for public email infrastructure — a standard enforced by major ISPs and mail providers.

Misaligned hostname and PTR domain

You set a sending hostname like newsletter.yourcompany.com in SES but your PTR record points to mail.vps-provider.com.
Even if the IP is correct, a domain mismatch breaks the alignment required by DMARC and SPF checks.
Let’s say your email uses smtp.yourcompany.com as the sending hostname, but the PTR says hosting.provider.net — the receiving server will reject it as suspicious. You can test this behavior yourself using tools like MxToolbox or dmarcian.com’s PTR checker.

Deploying without pre-validating the outbound IP

You launch SES from a new region (like ap-southeast-2) using the default outgoing IP without verifying the reverse DNS ahead of time.
Amazon uses regional IPs, and not all are pre-verified. A fresh IP without a matching PTR will trigger greylisting or blocklist flags.
Proactively check your IP's reputation with Spamhaus or similar systems before sending volume.

These issues aren't just technical quirks — they’re deliverability triggers. Your email may land in spam, be rejected outright, or never reach the inbox. The fix starts with validating the PTR record before sending. Use a dedicated IP, ensure your hostname matches the PTR domain, and verify reverse DNS with your hosting provider.

You can verify whether an email will pass these checks before sending by using a real-time email validation tool. Test the full path — address, domain, MX, and reverse DNS — early. Try checking one address at a time with our email checker or bulk-verify your list beforehand with bulk verification. Preventing delivery failures starts with checking what can go wrong.

What happens if you ignore PTR requirements in AWS SES?

If you skip setting up a reverse DNS (PTR) record that matches your AWS SES sending hostname, your messages will be permanently rejected with a hard bounce. This is a network-level block enforced by AWS—not a deliverability filter you can work around with DKIM, SPF, or warm-up. No amount of domain verification, sending history, or email content tweaks will override this. You cannot bypass it, even with a verified identity.

Why the PTR check is non-negotiable

Amazon SES enforces reverse DNS as a gatekeeper for sending reputation. A PTR record maps an IP address back to its owning hostname. If the hostname in the PTR doesn’t match the one AWS SES uses to identify your sending identity, the system treats the connection as untrustworthy. This isn’t an optional step—it’s baked into AWS’s SMTP handshake process.

Even if you’ve fully verified your domain, set up SPF correctly, and signed every message with DKIM, the rejection will still occur at the TCP level. The server drops the connection before any email content is processed. This isn’t a bounce you can fix by retrying or adjusting headers. It’s a hard rejection enforced during the connection phase.

How to avoid this failure

Let’s go over the fix: when you configure AWS SES to send from a custom domain, the system assigns it a sending hostname like mail-123-456-789.aws.com. You must create a PTR record for the IP address associated with that hostname, pointing back to the exact same hostname. This is typically done through your hosting provider or ISP, since most cloud providers don’t allow direct PTR changes.

Without this alignment, AWS SES won’t allow your outbound mail. It’s not a best practice—it’s a mandatory condition. Misconfigurations here are among the top reasons for failed deliveries in AWS SES setups, especially for senders managing high volume or automated campaigns.

To catch invalid or misconfigured addresses early—before they trigger SES rejections—use a tool that checks email validity at scale. Our bulk email verification service tests entire lists for syntax, domain, and mailbox validity, so you can spot risky addresses before sending. It catches issues like outdated domains, catch-all accounts, or temporary failures that might otherwise break your campaign.

How to test if your SES configuration passes PTR validation

You can verify if your AWS SES setup passes PTR validation by sending a test email to a real inbox and checking the SMTP response for rejection codes like 550 or 553—these indicate a failing PTR check. Use MailTester’s inbox-placement testing to simulate real-world delivery conditions and confirm whether your messages reach inboxes or get blocked. For confirmation that your endpoint is ready, run a real-time verification API call with a valid, deliverable email address.

Step-by-step validation process

Send a test email from AWS SES using a verified identity. Use the full email address you intend to send from (e.g., [email protected]) and send it to a real mailbox. This triggers the full mail flow through AWS SES and your domain’s mail infrastructure.
Inspect the raw SMTP response for PTR rejection codes. If the email is rejected, check the delivery logs or SMTP trace. Look for error messages indicating "PTR record mismatch" or response codes like 550-553. This confirms that your reverse DNS configuration doesn't align with the sending hostname. According to RFC 5321, the receiving server may reject messages if the PTR record doesn’t match the sending domain.
Use MailTester’s inbox-placement testing to simulate real delivery. Send a test message through your SES setup to a mailbox managed by MailTester, which checks not just delivery but inbox placement, spam flags, and filtering behavior—conditions that reflect actual user inboxes. This reveals whether your PTR misconfiguration is causing delivery failures before you scale out.
Verify the target email’s endpoint readiness with the real-time API. Before you rely on an address in your list, use the MailTester API to check whether the address is valid and accept mail. This confirms that the recipient's server is operational and not blacklisted, reducing false positives from rejected sends.

Why each step matters

Testing with a real mailbox is essential because simulated or fake addresses won’t trigger the full validation chain. Only real endpoints enforce SMTP-level checks, including PTR verification. The raw SMTP response is the definitive source of truth—no dashboard or status page can replace it. MailTester’s inbox placement tests replicate how real email providers evaluate messages, including reputation, content, and sender alignment.

Finally, using the real-time API ensures you’re not just relying on a domain’s reputation, but confirming that individual addresses are currently active and accepting mail. This reduces bounce rates and protects your sender reputation in the long term. Let’s be precise—because when your deliverability depends on it, there’s no room for assumption.

Is there a workaround for missing or invalid PTR records?

You cannot bypass AWS SES’s requirement for a valid reverse DNS (PTR) record matching your sending hostname. Any service claiming to skip this check—like third-party SMTP relays or email gateways—is either insecure, against AWS’s terms of service, or will fail in production. Even if you use a different email provider, your sending IP must still pass AWS SES’s DNS validation, including a matching PTR record. There is no known technical or policy workaround.

Why bypassing PTR is not safe or allowed

Let’s be clear: trying to route around PTR checks—via unverified proxy servers, unregistered gateways, or shared IPs—leads to immediate deliverability failure and can result in your AWS account being suspended. AWS SES enforces this rule to prevent abuse and ensure sender legitimacy. The requirement is documented in AWS’s own guidelines, which reference standard email authentication practices from RFC 5321 and other industry standards.

Using a third-party SMTP service that claims to handle PTR validation for you might seem convenient, but it doesn’t eliminate the underlying requirement. If that service sends from an IP without a valid, reverse-matching PTR, AWS SES will still reject it. Some providers may offer "proxy" solutions, but they effectively shift the problem—your IP still needs to be properly configured. You cannot outsource responsibility for DNS records that AWS explicitly checks.

What works instead: fix your DNS configuration

The only real solution is to set up the PTR record correctly. AWS requires the reverse DNS record (PTR) on the sending IP to point directly to the hostname you use in sending (e.g., mail.yourdomain.com). If your domain uses a shared hosting platform or provider that doesn’t allow custom PTR records, you cannot send through AWS SES with that IP.

Most ISPs and cloud providers control PTR records. If you’re using a dedicated IP with AWS SES, the PTR record must be set up through the provider that owns the IP address. For instance, if you’re using a dedicated elastic IP from AWS, you can set the reverse DNS via the AWS console. This requires coordination with AWS to ensure it matches your sending hostname.

In short: no workaround exists. Validating PTR is not a suggestion—it’s mandatory. If you’re unsure how to check or set up your PTR, use tools that test email infrastructure, like MXToolbox or MailTester’s inbox placement tool, to validate your setup before sending at scale.

How does MailTester help you catch PTR and delivery issues before they happen?

You can prevent delivery failures caused by mismatched PTR records and infrastructure-level blocks by testing your sending setup in real-world conditions. MailTester’s inbox-placement tests simulate delivery across major providers’ infrastructure, including checks for PTR alignment, DKIM, and SPF, so you catch issues before they hit your reputation. This is especially critical with AWS SES, where a misconfigured PTR can trigger automatic rejection.

Spot PTR and infrastructure problems in real mail servers

Use MailTester’s inbox-placement tester to send a test email to real inboxes across Gmail, Yahoo, Outlook, and other major providers—this includes checks that validate whether your sending domain’s PTR record matches your sending hostname.
MailTester doesn’t just check syntax—it evaluates delivery readiness on actual infrastructure, revealing whether your setup would pass checks like reverse DNS, IP reputation, and spam filtering.
For services like AWS SES, where PTR must match the sending hostname, this validation catches misconfigurations before you send to a real audience.

Verify addresses and lists with real-time confidence

Check individual email addresses for deliverability before sending with the real-time email checker, including validity, bounce risk, and catch-all detection.
Run bulk list verification on thousands of addresses using MailTester’s bulk verification tool—it flags invalid, risky, and catch-all addresses, reducing bounce rates and protecting sender reputation.
Integrate MailTester into your stack via API (email verification API) to validate addresses on signup or before sending campaigns.
With a 98.9% accuracy rate, MailTester provides reliable results across all major email domains, including disposable, role, and catch-all emails that commonly fail delivery.

While no tool can force your ISP to provision a correct PTR, MailTester gives you full visibility into whether your setup would pass real-world checks—before you send.

Protect your sender reputation and inbox placement

High bounce rates from invalid or catch-all addresses degrade sender reputation. MailTester removes these from your lists before sending.
By simulating delivery across real environments, you ensure your messages aren’t blocked by infrastructure checks like PTR mismatches, IP blacklists, or domain reputation signals.
For AWS SES users especially, consistent validation ensures your sending hostname aligns with your PTR and mail server setup—meeting AWS’s documented requirements.

For further reading on mail server validation, RFC 5321 (SMTP) and RFC 4408 (SPF) provide the technical foundation for sender policies. These protocols define how receivers validate sending servers, making pre-sending checks like MailTester’s essential for reliable delivery.

Final takeaway: PTR is not optional—it’s enforcement

AWS SES does not treat reverse DNS (PTR) validation as a recommendation. It is a hard requirement. If the PTR record for your sending IP does not resolve to your configured sending hostname, your message will be rejected at the SMTP level, regardless of proper SPF, DKIM, or DMARC setup.

Even with flawless authentication, a mismatched PTR record will block delivery. This is not a configuration quirk—it’s a deliberate and enforced part of AWS SES’s sender reputation and abuse prevention stack.

Prevention is better than recovery

Test your PTR configuration before sending to production lists.
Verify sender identities and email addresses at scale using tools like MailTester.
Use inbox placement testing to validate delivery before launching campaigns.

Sources

Gmail delivered 87.2% of commercial email to the inbox in 2024 while sending 6.8% to spam — the best inbox rate of the four major mailbox providers. — Validity 2025 Email Deliverability Benchmark Report (2025)
Gmail requires bulk senders to keep user-reported spam rates below 0.3%, warning that rates above 0.1% already hurt inbox delivery — just 3 complaints per 1,000 emails crosses the line. — Google Email Sender Guidelines FAQ (2024)

Keep reading

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

Frequently asked questions

Does AWS SES require PTR record for every sending domain?

Yes. The PTR must match the hostname used in the SES configuration, regardless of the domain sending the email.

Can I use a domain alias for the PTR record?

No. The DNS record must resolve exactly to the sending hostname declared in AWS SES. Aliases and CNAMEs are not allowed in PTR records.

What if my hosting provider doesn’t support custom PTR records?

You cannot use AWS SES from that provider’s IP range without modifying the hosting configuration. Consider switching to a provider that allows outbound SMTP with validated PTR.

Does the PTR record need to be set on the same domain as the sending address?

No. The PTR must match the sending hostname, not the sender domain. For example, mail.example.com can have a PTR pointing to a different domain.

Can I test PTR validity before setting up AWS SES?

Yes. Use standard DNS tools like dig or nslookup to verify your IP’s reverse DNS before activation.

What happens if the PTR record is misconfigured but returns the correct domain?

The email is still rejected if the hostname doesn’t match exactly the one listed in AWS SES.

Why are PTR records not widely documented by AWS?

AWS documents the requirement in policy and technical guides, but it’s often missed because it’s a network-level check not visible in email content.

Is PTR the only requirement for AWS SES delivery?

No. You must also have valid SPF, DKIM, and DMARC records, and follow warm-up procedures for new domains.

Can MailTester detect if my PTR record is missing?

Yes. MailTester's inbox-placement testing simulates real delivery conditions, including infrastructure-level checks like PTR validation.

How many free verifications does MailTester offer?

100 free verifications to start, with no expiry on purchased credits.

What is MailTester’s accuracy rate?

98.9% accuracy across bulk and real-time email verification.

Can I integrate MailTester with SendGrid or HubSpot?

Yes. MailTester integrates with SendGrid, HubSpot, Mailchimp, and Klaviyo to verify and clean lists before sending.