SMTP response received
554 Nemesis ESMTP Bad DNS PTR Resource RecordYou received this code because Yahoo Nemesis ESMTP inbound filter refused your connection because your sending IP does not have a valid PTR (reverse DNS) resource record. Yahoo enforces this check aggressively as a baseline anti-spam measure: no PTR, no delivery. The rejection is permanent for that connection but reversible once you publish a proper reverse DNS record at your hosting provider and wait for Yahoo caches to refresh. This is one of the strictest FCrDNS enforcements in the industry, alongside AOL (part of the same Yahoo Mail infrastructure).
๐ In this guide
๐ค Who sees this code
- Operator sending mail to Yahoo, AOL, Rocketmail, or Ymail addresses whose deliverability suddenly dropped
- Ops team debugging a new outbound relay whose IP has no PTR record yet
- Deliverability lead investigating Yahoo-only rejections when Gmail and Microsoft still accept the same mail
๐ง What this guide fixes
- Confirm the sending IP has a missing or invalid PTR record
- Publish a proper PTR record aligned with the sending hostname
- Wait for Yahoo Nemesis cache refresh and verify delivery resumes
โก Do these 3 things first (before diving deeper)
Confirm the sending IP has no PTR or an invalid one
Query the PTR record directly: dig -x YOUR.SENDING.IP.HERE +short. Three possible outcomes signal the Nemesis rejection cause: (1) empty response, no PTR published, (2) a generic hosting hostname like colo-123.provider.example.com unrelated to your sending domain, or (3) a hostname that does not itself resolve back to the same IP (forward mismatch). All three fail Yahoo Nemesis validation. The PTR and rDNS records guide details the resolution flow.
Test forward-confirmed reverse DNS (FCrDNS)
FCrDNS is a two-step check: reverse (IP to hostname) then forward (hostname to IP). Both must return the same IP for the connection to pass Yahoo. Run dig -x YOUR.IP +short to get the hostname, then dig +short A that-hostname to get the IP. The final IP must equal the starting IP. Any mismatch triggers Nemesis rejection. Yahoo Postmaster documentation explicitly requires FCrDNS success for inbound acceptance.
Check whether the issue is Yahoo-specific or affects all receivers
Send test messages to Gmail, Microsoft 365, and Yahoo simultaneously from the same outbound IP. If only Yahoo rejects with Nemesis wording, the PTR issue is real but not yet caught by other receivers who apply lighter FCrDNS checks. If Gmail also rejects (with 550 Reverse DNS Check Failed or similar wording) or Microsoft rejects with 550 5.7.25 PTR reverse DNS, the PTR problem is more severe and needs immediate attention across your outbound.
Common causes of 554
- No PTR record was ever published for the sending IP. The most common cause on new cloud instances and freshly-provisioned VPS. PTR records must be set at the hosting provider level (they control the reverse DNS zone for the IP block), not at your own DNS host. If you provisioned a new outbound server without asking the provider to configure PTR, Yahoo Nemesis catches it on the first connection. All major clouds (AWS, GCP, Azure, DigitalOcean, Hetzner, OVH) support custom PTR configuration through their console or support ticket process, but it is not automatic.
- PTR points to a generic hosting hostname unrelated to your domain. Some providers auto-generate PTR records like
ec2-1-2-3-4.us-east-1.compute.amazonaws.comorstatic.1.2.3.4.clients.your-server.de. These auto-generated PTR values are technically valid DNS entries, but they signal shared hosting or datacenter infrastructure rather than a purpose-built mail server. Yahoo Nemesis and other strict receivers flag them as generic and reject. Publish a custom PTR pointing to your own domain (e.g.,mail.yourdomain.com) to pass. - PTR hostname does not have a matching forward A record. The PTR record can be published correctly but if the hostname it points to does not itself resolve to the same IP, FCrDNS fails. Example: PTR says
mail.yourdomain.com, butdig +short A mail.yourdomain.comreturns a different IP or nothing. This produces the same rejection as no PTR at all because the two-step check fails on the forward leg. Publish the A record at your DNS host to match the PTR value. - PTR mismatches the HELO hostname you announce. Yahoo Nemesis also compares your PTR value to the EHLO/HELO string your MTA sent in the greeting. When they disagree, Nemesis treats the identity as inconsistent and rejects. Fix by aligning both: your MTA HELO configuration and your PTR should point to the same fully-qualified hostname. See our HELO validation playbook for the sender-side configuration.
- Multiple sending IPs, only some have PTR published. Outbound sending pools with multiple IPs commonly have PTR published for the primary IP but missing on secondary IPs. Yahoo Nemesis sees a rotation of connections: some pass, some fail with the PTR rejection. This produces intermittent Yahoo deliverability that is hard to diagnose because your test sends from the primary IP always succeed. Audit every IP in your outbound rotation with
dig -xand publish PTR for all of them.
How to fix 554, step by step
- Publish a PTR record at your hosting provider. Log into your hosting provider console and locate the PTR / reverse DNS configuration for your sending IP. AWS EC2: request PTR via the AWS support form or use Route 53 reverse zones. GCP Compute:
gcloud compute instances create --public-ptr-domain. Azure: Public IP address settings. DigitalOcean: Networking > Reverse DNS. Hetzner: Server dashboard > Networking > Reverse DNS. OVH: IP management > Reverse. Set the PTR to your sending hostname (e.g., mail.yourdomain.com). Provider-specific console steps are covered in our PTR and rDNS records guide. - Publish the matching forward A record. In your domain DNS zone, publish an A record where the hostname (from the PTR value) points to the same sending IP. If PTR says mail.yourdomain.com and your IP is 192.0.2.10, publish
mail.yourdomain.com. IN A 192.0.2.10. Wait for DNS propagation (typically minutes to an hour). Verify withdig +short A mail.yourdomain.com, the returned IP must equal your sending IP. - Align MTA HELO configuration with the new PTR value. Configure your outbound MTA to announce the same hostname as your PTR. In Postfix:
myhostname = mail.yourdomain.comandsmtp_helo_name = $myhostname. In Exim:primary_hostname = mail.yourdomain.comandhelo_data = $primary_hostname. Reload the MTA. Now HELO, forward DNS, and reverse DNS all agree. - Verify FCrDNS with dig from an external network. Run the FCrDNS check from a machine outside your own network to avoid caching artefacts:
dig -x 192.0.2.10 +shortshould return mail.yourdomain.com. Thendig +short A mail.yourdomain.comshould return 192.0.2.10. Both queries must succeed with matching values. If either returns wrong data, the underlying DNS is not yet aligned and Yahoo will still reject. - Wait for Yahoo Nemesis cache refresh. Yahoo caches PTR check results at the connection layer. Even after your DNS is fixed, existing cached rejections can persist for several hours to a day. Do not resume bulk sending immediately after the DNS change. Send a small test batch (10 to 50 messages) to Yahoo addresses first and verify they deliver. If they still bounce with Nemesis wording after 24 hours despite correct DNS, contact Yahoo Postmaster with your evidence:
dig -xoutput showing correct PTR, timestamps of DNS changes, sample bounce Message-IDs. - Complement PTR fix with full authentication stack. Yahoo evaluates PTR alongside SPF, DKIM, and DMARC alignment as part of the composite trust decision. A correct PTR without proper authentication will still see reputation-driven filtering to Yahoo bulk folders even if it stops the outright Nemesis rejection. Publish all three and monitor delivery via Yahoo Feedback Loop (part of Yahoo Postmaster), so any residual issues surface as complaints rather than silent bulk placement.
๐ How each provider sends this exact code
โ How this code differs from adjacent ones
550 Reverse DNS Check Failed553 Bad Reverse DNS554 RDNS FailurePrevention going forward
Yahoo Nemesis PTR enforcement is the strictest baseline in the industry, but it is also the most predictable: publish a proper FCrDNS-aligned PTR record and it never triggers. Preventing recurrence means treating PTR as production infrastructure that ships with every new outbound IP, not something added later.
- Include PTR record configuration in the provisioning checklist for every new outbound IP. Whether spinning up a new server, renting a new VPS, or adding an IP to a warmup pool, PTR must be published before the first send. Our PTR guide covers provider-specific automation.
- Monitor FCrDNS status monthly across every outbound IP. A scripted
dig -xloop over your IP list, comparing against expected PTR values, catches drift when hosting providers rotate infrastructure or auto-generated PTR overrides your custom setting. - Register for Yahoo Postmaster (postmaster.yahooinc.com) and monitor sender reputation there. Yahoo publishes complaint rates, spam rates, and bulk placement stats that correlate with PTR and authentication posture. Any deterioration signals underlying reputation risk before hard bounces surface.
- Publish TLSRPT and monitor TLS delivery reports. Yahoo included in TLSRPT aggregate reports if their inbound gateway supports it, giving you visibility into TLS negotiation and adjacent security signals. See our SSL/TLS setup guide.
- Never send bulk mail from IPs with shared PTR records. Shared PTR (like
colo-123.provider.example.com) will trigger Yahoo Nemesis 100 percent of the time regardless of your authentication posture. Move to dedicated IPs with dedicated PTR, or route through a reputable ESP that handles this layer.
Frequently asked questions about 554
What is Nemesis ESMTP?
How long does Yahoo take to accept my mail after I fix PTR?
Do I need a PTR record for every sending IP?
Does an SPF pass compensate for missing PTR at Yahoo?
Can I use a wildcard PTR record?
Why do Gmail and Microsoft accept mail that Yahoo rejects for PTR?
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.
