421 No Reverse DNS: Causes, Solutions, and How to Fix It

SMTP error code 421: causes, retry logic, and the sender-side fix. No Reverse DNS: Causes, Solutions, and How to Fix It.
SMTPedia editorial team
Email infrastructure & deliverability editor
3 min read Jun 26, 2026 40 views
Code421
Bounce typeSoft bounce
RetryableYes (after fix)
Action neededSet PTR record
Typical error message
421 4.7.1 Service unavailable: no reverse DNS for [x.x.x.x]

What does 421 No reverse DNS mean?

The receiving server performed a reverse DNS (PTR) lookup on your sending IP and found no result. Rather than rejecting the message permanently, the server returns a 421 soft bounce, which tells your MTA to retry later in case the lookup was a transient DNS issue. If the PTR record is genuinely missing, every retry will return the same 421 until the record is configured. Many MTAs treat absence of PTR as a strong spam signal because legitimate mail servers always have reverse DNS configured to match a forward A record (forward-confirmed reverse DNS, or FCrDNS).

Is this a soft or hard bounce?

⚠️
Soft bounce, but no retry will succeed until PTR is set

Your MTA will keep retrying for up to 5 days. Configure the PTR record now to fix the entire backlog at once. See also 550 client rejected: no rDNS for the hard-bounce variant servers use after exhausting patience.

Common causes

No PTR record configured

Default state for many cloud VMs, VPS instances, and home connections. The hosting provider must configure PTR on the IP, not the customer (PTR is set on the IP owner side, not via your DNS).

⚠️
PTR exists but does not resolve forward

FCrDNS requires the PTR hostname to also have an A record pointing back to the same IP. Mismatched forward and reverse records fail the check.

🏠
Sending from a dynamic IP range

Residential and dynamic IPs typically have generic PTR records or none at all. Use an authenticated SMTP relay instead of sending direct.

How to fix it

1
Identify your sending IP

Check your MTA configuration or use dig +short myip.opendns.com @resolver1.opendns.com. Confirm which IP is actually used for outbound port 25.

2
Verify current PTR with dig

Run dig -x <your-ip>. If the result is empty, no PTR exists. If it returns a hostname, run dig <hostname> to confirm forward resolution back to the same IP.

3
Configure PTR through your IP owner

PTR records are set by the IP owner, not by your domain registrar. For AWS use the request form in EC2. For DigitalOcean, set the droplet name to the FQDN. For dedicated hosts contact your hosting provider.

4
Verify and resume sending

After PTR propagates (usually within minutes, occasionally up to 24h), the MTA will retry queued messages automatically. See 450 4.7.1 client host rejected for the related Postfix variant.

Provider-specific notes

MTABehavior
PostfixReturns 421 4.7.1 when reject_unknown_reverse_client_hostname is in smtpd_client_restrictions. After retries exhaust, escalates to 550 client rejected: no rDNS.
EximReturns 421 with the no-rDNS check in helo_try_verify_hosts. Soft fails by default.
SendmailReturns 421 if the configuration sets a temporary failure for PTR lookups. Switching to permanent (550) is common after sustained issues.
Pre-bounce verification

Prevent the bounces that hurt your sender IP

PTR-based rejections often coincide with weak IP reputation. SMTPing catches invalid addresses before you send, so your reputation stays strong while you fix DNS. 25 free checks daily, no card required.

Try SMTPing free →

About the Author

Alaa - SMTPedia 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.