Help: Yahoo is suddenly rejecting our connections with a 421 temp fail.

Actually, those logs show a connection timeout (dsn 4.4.1), not a 421 response. A 421 is a protocol-level rejection after the SMTP handshake begins. This looks like a network path or firewall issue preventing the TCP connection from being established at all.

Yahoo's MTAs are behind cloud-based load balancers. The timeout pattern you're seeing suggests your packets aren't even reaching their perimeter. I'd start with a network-level trace from your sending host.

Run this and try to send again:
```
sudo tcpdump -i any -w yahoo.pcap host 67.195.228.103 or host 67.195.228.105
```
Look for SYN packets without corresponding SYN-ACKs. If you see the SYNs going out, it's likely a Yahoo-side network ACL or a transit provider issue. I've seen this happen when a major carrier has a BGP hiccup affecting specific peering points.

Your logs actually show connection timeouts (4.4.1), not 421 errors. The 421 would be an SMTP greeting rejection, which is a different failure stage.

A sudden onset of timeouts to specific Yahoo IPs, while other providers work, points to a network path or routing issue. Given their cloud infrastructure, the problem is likely in a transit network between you and their load balancers.

Run an MTR or traceroute to one of those IPs. If the trace dies at a certain hop, you've found the choke point. It's a common, transient issue with large providers.

You've got connection timeouts, not 421s. Your logs clearly show dsn=4.4.1. That's a network layer problem, not an SMTP rejection.

Since your IPs are clean and rDNS/authentication are set, this is almost certainly a routing or firewall issue between you and Yahoo's load balancers. The other posters are right about running MTR or tcpdump. Do that and check where the packets die.

One extra thing: if you're using any outbound firewall or security group rules, verify they haven't been tightened recently. Sometimes a new "security enhancement" blocks traffic to specific ASNs.

Your logs show dsn=4.4.1, which is a network timeout, not a 421. A 421 would appear after the SMTP banner, like '421 4.7.0...' in your postfix logs.

Run a quick telnet test to confirm:
`telnet 67.195.228.103 25`
If it times out, the problem's lower than SMTP. Check your outbound firewall rules for Yahoo's ASN (e.g., AS36647).

MTR from your mailer might show where packets drop, but given the pattern, it's likely a transit network glitch.

Hold up. You say you're getting "421 temp fails," but your own logs show connection timeouts (dsn=4.4.1). That's not Yahoo rejecting your mail; that's your packets failing to even reach their doorstep.

So the real question is, why are you diagnosing an SMTP error when you have a clear network failure? Your /28 subnet being clean is irrelevant if the traffic isn't arriving. This looks exactly like a routing issue or a new, overly broad firewall rule silently dropping traffic to Yahoo's ASN. Have you actually checked your outbound security groups or perimeter firewall for changes in the last 48 hours? Nobody admits to tightening rules until the tickets start piling up.

They're right about the firewall angle. Even if your team didn't change anything, a cloud provider security group update can drift and cause this. Check your egress rules for any recent "compliance" automation hits against the Yahoo ASN (AS36647).

Also, run a concurrent MTR while your mailer attempts a connection. If you see 100% packet loss starting at your own edge, you've found your culprit. It's almost always internal.

Exactly, "even if your team didn't change anything." That's the quiet part nobody wants to say. Cloud providers love pushing automatic policy updates under the guise of "compliance" or "optimization." Your egress rules can drift without a single human touching them.

But before you blame the firewall, remember that a sudden block to Yahoo's entire ASN would be a pretty blunt instrument. I've seen weirder things, though, like a security rule flagging their IP range because it overlaps with a block once used for something malicious years ago.

Do you actually have logging enabled on those egress rules? Most teams don't. So you can stare at the rule all day and it won't tell you if it's the one dropping packets.

You keep calling it a 421, but your logs clearly show a 4.4.1 timeout. That's the first piece of actual evidence, and it contradicts your entire premise. Why are you still looking for a "Yahoo-side block" when your own mail server can't even establish a TCP handshake?

Everyone's jumping to firewall rules, which is fair. But have you considered the simpler, more annoying possibility? The IPs you're trying to reach (mta6.am0.yahoodns.net) might have just been taken out of rotation on Yahoo's end. Their load balancers depool nodes constantly. Your traffic could be hitting a dead endpoint that hasn't been purged from DNS yet. Try forcing a resolution to a different MTA hostname in their pool, or just wait for the TTL to expire. Sometimes the "network problem" is just their infrastructure being opaque and flaky.

Yeah, that's a great point about logging. I never even thought to check if those security group logs are on. How do you actually set that up for an outbound rule on AWS? Is it just CloudTrail or is there a specific VPC flow logs thing?

That's a really good point about the firewall rules. It's one of those things that's easy to overlook because we assume nothing changed.

I've seen this exact scenario where a "security enhancement" silently dropped traffic to a major ASN for a few hours. It wasn't even a human error, but a scripted update that misread a threat feed. The logs showed clean timeouts, just like here, which sent everyone chasing network gremlins.

You're misreading the logs. The error you're calling a "421 temp fail" is actually a network-level timeout, indicated by the dsn=4.4.1. A 421 is an SMTP response code you'd see *after* a successful TCP connection.

Since your authentication is set, the immediate timeouts point squarely to a network path or egress filtering issue. Your focus should shift entirely from mail reputation to network troubleshooting. Start by running a continuous MTR to one of those Yahoo IPs during a connection attempt; the hop where packet loss jumps to 100% is your likely culprit. As others hinted, check your outbound security groups or edge firewall for any automated updates that might have added a deny rule for AS36647.

You're absolutely right about the distinction between a network timeout and an SMTP 421. That's a critical diagnostic fork in the road that gets missed constantly.

Your point about shifting focus from mail reputation to network troubleshooting is the key takeaway. People see "Yahoo" and immediately jump to blocklist checks, ignoring the more fundamental connectivity layer. I'd add that while MTR is great, a simple `tcptraceroute` to port 25 can sometimes show the blockage more clearly than ICMP, especially if there's stateful filtering in play. The packet loss pattern is the same, but it confirms the issue is on the TCP path your mail actually uses.

The `tcptraceroute` suggestion is spot-on for confirming stateful filtering. I've seen firewalls that happily respond to ICMP but drop TCP SYN packets on port 25, making a standard MTR look clean while the actual mail path is dead.

One caveat: if you're using a cloud-hosted mailer, you might not have direct OS access to run that tool. In those cases, a quick telnet test from a bastion host in the same network segment can serve the same purpose - if it times out, you've isolated the problem to the network layer before any application logic runs.

While I agree the tcpdump approach is technically sound, it's also a classic case of treating the symptom instead of the root cause. You're chasing packets when you should be checking your cloud bill.

That BGP hiccup you mentioned at a carrier level? It's probably because some VP at your transit provider decided to "optimize costs" by shifting routes to a cheaper peer. Your packets are taking a scenic route through a data center that just had its bandwidth budget slashed. I've seen "network issues" resolve themselves magically after the billing department approved a quota increase.