SMTP response received
554 rDNS failureYou received this code because the receiving mail server refused the connection permanently because reverse DNS (rDNS / PTR) lookup on your sending IP failed. Either no PTR record is published, the PTR points to a hostname that does not resolve back to the same IP, or the PTR value is generic hosting infrastructure that the receiver flags as untrusted. This is a hard rejection at the SMTP connection layer, before any message envelope is evaluated, and it applies uniformly at strict receivers including Comcast, AT&T, Charter, Cox, and enterprise Postfix installations. The fix requires DNS changes at your hosting provider, not authentication or content tuning.
๐ In this guide
๐ค Who sees this code
- Operator of a new outbound relay whose PTR record was never published
- Ops team migrating servers whose new IP inherits generic hosting PTR instead of custom domain PTR
- Deliverability lead whose mail bounces at ISP mailboxes (Comcast, AT&T, Charter) while cloud receivers still accept
๐ง What this guide fixes
- Confirm the exact rDNS state of the sending IP
- Publish a domain-aligned PTR record at your hosting provider
- Verify FCrDNS success and monitor delivery across strict ISP receivers
โก Do these 3 things first (before diving deeper)
Query the reverse DNS for your sending IP
Direct lookup: dig -x YOUR.SENDING.IP.HERE +short. Three failure modes trigger 554 rDNS failure: empty response (no PTR published at your hosting provider), a generic auto-generated hostname (like ec2-1-2-3-4.compute-1.amazonaws.com), or a PTR whose forward A record does not resolve back to your IP. Take the exact output as your diagnostic starting point. See our PTR and rDNS records guide for the interpretation cheat sheet.
Test forward-confirmed reverse DNS (FCrDNS)
FCrDNS validates the round-trip: reverse then forward must yield the same IP. Run dig -x YOUR.IP +short to get the hostname (call it H), then dig +short A H to get the forward IP. That forward IP must equal YOUR.IP. Any mismatch or missing forward record triggers the receiver rejection. This test is definitive, strict receivers implement exactly this check.
Determine which receiver categories reject vs accept
Send a small test batch to Gmail, Microsoft 365, Yahoo, and a Comcast address. Yahoo Nemesis and Comcast reject aggressively on rDNS failures (see our Yahoo Nemesis playbook and Comcast bosimpinc variant). Gmail and Microsoft may accept but apply reputation penalties. If Comcast/Yahoo reject and cloud providers accept, the rDNS problem is real but not yet reflected in cloud reputation systems, fix it before the reputation catches up.
Common causes of 554
- No PTR record published at the hosting provider. PTR records live in the reverse DNS zone controlled by whoever owns the IP block, typically your hosting provider. If you provisioned a server and never explicitly configured the PTR, most providers leave it empty or provide a generic hostname. Strict receivers reject on both cases. This is the leading cause of 554 rDNS failure on newly provisioned outbound infrastructure. Every major cloud (AWS, GCP, Azure) and reputable VPS provider (Hetzner, OVH, Linode, DigitalOcean) supports custom PTR, you have to ask for it.
- PTR points to a generic auto-generated hostname. Providers like AWS EC2 auto-generate PTR values that describe the datacenter infrastructure rather than your domain. Values like
ec2-1-2-3-4.us-east-1.compute.amazonaws.comorstatic.1.2.3.4.clients.your-server.deare technically valid PTR responses but strict receivers pattern-match them as generic/shared infrastructure and reject. Publish a custom PTR pointing to your own domain (mail.yourdomain.com) to override. - Forward A record for the PTR hostname is missing or wrong. A common half-configured state: PTR is set correctly (mail.yourdomain.com) but no A record exists in your domain DNS zone for that hostname. FCrDNS fails on the forward leg, the receiver looks up mail.yourdomain.com, gets nothing, and rejects. Fix by publishing the A record at your DNS host so mail.yourdomain.com resolves back to your sending IP.
- PTR was correct but hosting provider infrastructure change reverted it. Hosting providers occasionally rotate infrastructure, new hypervisor, new subnet, new PTR zone owner, and auto-generated PTR values overwrite the custom PTR you had configured. This surfaces as 554 rDNS failure appearing weeks or months after the original setup was verified working. Audit periodically with
dig -xand monitor for changes. Some providers require re-submitting the PTR request after certain infrastructure events. - Multiple outbound IPs with inconsistent PTR configuration. Outbound sending pools distribute connections across multiple IPs. If PTR is set on the primary IP but missing on additional IPs added to the pool, some connections pass and others fail with 554 rDNS. This produces mysterious intermittent bounces at strict receivers that are hard to diagnose because test sends from the primary IP always succeed. Audit every IP in the pool. If any IP has missing or generic PTR, publish a proper one before that IP handles production traffic.
How to fix 554, step by step
- Publish a domain-aligned PTR at your hosting provider. Console-based: AWS Route 53 reverse zones or AWS support form for EC2, GCP Compute Engine
--public-ptr-domain, Azure Public IP address reverse DNS, DigitalOcean Networking > Reverse DNS, Hetzner Server dashboard > Reverse DNS, OVH IP management, Linode Networking > Public IPs. Set the PTR value to your canonical sending hostname (e.g., mail.yourdomain.com). Provider-specific step-by-step in our PTR and rDNS guide. - Publish the matching forward A record. In your domain DNS zone:
mail.yourdomain.com. IN A 192.0.2.10. The hostname on the left must match your PTR value exactly, and the IP on the right must be your actual sending IP. Wait for DNS propagation (typically minutes to an hour, occasionally longer at ISPs with aggressive caching like Comcast). Verify:dig +short A mail.yourdomain.com. - Align MTA HELO to match the PTR value. Configure your outbound MTA to announce the same hostname in EHLO/HELO as your PTR resolves to. In Postfix:
myhostname = mail.yourdomain.comandsmtp_helo_name = $myhostname. In Exim:primary_hostname = mail.yourdomain.com. In Sendmail:confDOMAIN_NAME. See the HELO validation playbook for the sender-side discipline that complements rDNS fixes. - Verify FCrDNS from an external machine. Run the FCrDNS round-trip from a machine outside your network:
dig -x 192.0.2.10 +shortreturns mail.yourdomain.com. Thendig +short A mail.yourdomain.comreturns 192.0.2.10. Both must succeed and values must match. External validation avoids caching artefacts on your own resolvers. - Send test messages to a rejection sample and confirm delivery. Before resuming production, send a small test batch (10 to 50 messages) to the receiver categories that were rejecting. If Comcast, Yahoo, or AT&T rejected before, confirm they accept now. Watch for any residual 554 responses, those indicate incomplete DNS propagation or a specific receiver cache still holding the old rejection. Give propagation 24 hours before resuming full volume.
- Combine PTR fix with full authentication stack. PTR fixes the connection-layer rejection. Reputation-driven bulk-folder placement is a separate concern addressed by SPF, DKIM, and DMARC alignment. Publish all three so your delivered mail also lands in the inbox, not just the door. Cross-check with the Authentication-Results header at receivers.
๐ How each provider sends this exact code
โ How this code differs from adjacent ones
554 Nemesis ESMTP Bad DNS PTR553 Bad Reverse DNS421 No Reverse DNSPrevention going forward
rDNS failures fall into a predictable pattern: hosting infrastructure changes or new IP provisioning without PTR configuration. Preventing recurrence means treating PTR as ship-day-one infrastructure and monitoring for drift.
- Every new outbound IP goes through PTR configuration on the same day it is provisioned, before any production mail flows through it. Include PTR in your infrastructure automation or provisioning checklist. Our PTR guide shows provider-specific automation examples.
- Monitor FCrDNS status monthly with a scripted
dig -xloop across all outbound IPs, comparing observed values against expected. Alert on any mismatch. Hosting providers occasionally rotate infrastructure or revert auto-generated PTR values that override your custom settings. - Track deliverability by receiver category. Comcast, Yahoo, AT&T and similar strict ISPs are your rDNS canary. If deliverability drops at ISP mailboxes while cloud receivers are still accepting, PTR drift is the most likely cause. Set up receiver-segmented dashboards.
- When adding new IPs to your outbound pool, verify each one has valid FCrDNS before releasing it into rotation. Half-configured pools produce intermittent bounces that look like reputation problems but are actually structural PTR gaps.
- For sites that cannot maintain PTR discipline in-house, route outbound mail through a reputable ESP or transactional relay (SendGrid, Mailgun, Postmark, SES) that handles the connection-layer identity concerns. Trade infrastructure control for deliverability discipline. If bulk sending from own infrastructure remains a strategic requirement, our IP warmup schedule guide covers the operational cadence.
Frequently asked questions about 554
What is the difference between rDNS and PTR?
Why does Comcast reject my mail when Gmail accepts it?
554 rdns failure. Gmail applies rDNS as a reputation signal rather than a hard block for most senders, so mail with poor rDNS still delivers to Gmail but eventually to bulk. If Comcast rejects and Gmail accepts, Comcast is the honest canary telling you PTR is broken. Fix it before Gmail reputation degrades too.How long does it take for a PTR fix to propagate?
dig -x from multiple resolvers to confirm propagation reached authoritative servers.Can I use a CNAME instead of a PTR to alias my rDNS?
Does IPv6 have PTR records too?
What if my PTR keeps getting reset to a generic value?
--public-ptr-domain persists through instance restarts but not across IP changes. Provider-specific persistence details in our PTR guide.Stop 554 bounces before they happen.
SMTPing catches invalid addresses, disposables, catch-all traps, role accounts and dead mailboxes before you send. Fewer bounces means less firefighting and a healthier sender reputation. 13 validation types, 25 free daily, no card required.
๐ Deep dive on related codes
550 5.7.25PTR reverse DNS missingFCrDNS setup coordination with hosting provider
550 5.4.1Office 365 tenant policyRecipient address rejected at Microsoft โ auth or reputation cause
550 5.1.1User unknownRecipient address does not exist โ suppress immediately
550 5.7.1Relaying deniedSender-side SMTP AUTH failure โ fix your outbound config
About the Author
Alaa ยท LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. Iโve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
