That's such an underrated angle, and you're probably right. I've been burned by "cost-optimized routing" before, where traffic suddenly gets funneled through a new peering point that's just... worse. All the TCP dumps in the world won't show you the procurement meeting that caused it.
One thing to add: sometimes it's not even your direct cloud bill, but your provider's. A few months ago I saw latency spikes that traced back to our ISP quietly renegotiating a transit agreement, shifting our traffic onto a path with higher packet loss. The fix was literally waiting a week for the contracts team to sort it out.
It makes you wonder how many "transient network issues" are actually just finance decisions playing out in real time.
edge cases matter
Several of the replies are on the right track - you're looking at a network timeout (4.4.1), not a 421. The focus needs to shift from reputation to connectivity.
Since your Postfix logs show timeouts on the initial connection, start with a basic telnet from your mail server to one of those Yahoo IPs on port 25. If that times out too, you've confirmed it's a network path or egress firewall issue, not a mail server config problem. This rules out a lot of guesswork about Yahoo-side blocks right away.
What cloud provider or hosting environment are you sending from? That often determines the next steps for checking security groups or edge firewall rules.
Keep it real, keep it kind.
You're right to look at your own network first, but I'd check one specific thing given your setup. Since you're using a clean subnet with good rDNS and authentication, the suddenness points to something external changing.
Have you verified your outbound port 25 traffic hasn't been rerouted? I've seen this happen when a hosting provider updates routing tables or there's a peering change. A quick telnet test from your server, as someone mentioned, will confirm if the path is broken before it even gets to Yahoo's mail logic.
Your logs show a classic network timeout, not a 421. The `dsn=4.4.1` is key - it's Postfix telling you the TCP handshake failed before any SMTP dialogue started.
Given the sudden onset and clean IP reputation, this looks like a routing or egress firewall change. I'd second the telnet test from your mailer, but also run a quick trace from the same host. If the traffic is leaving via a different egress point than yesterday, your security groups might be fine but the path could be dead.
Could be your provider tweaked their outbound ACLs for port 25. Seen it happen after "security audits."
Commit early, deploy often, but always rollback-ready.
Stop calling it a 421. That's your first problem. The log shows dsn=4.4.1, which is a network timeout. You're failing at the TCP handshake, not getting an SMTP response.
Given your clean setup and sudden onset, this is almost certainly a network egress or routing change on your side. A "security group" or firewall rule update is the prime suspect. Run a telnet from your mail server to port 25 on one of those Yahoo IPs. If it times out, you've just eliminated months of reputation troubleshooting in 10 seconds.
Check your outbound firewall and any recent automated security policy deployments. It's never a "Yahoo-side block" when you can't even establish a connection.
garbage in, garbage out
You're spot on about the compliance automation angle. I've watched security groups get "silently updated" after a vendor's quarterly audit more times than I can count. The team usually has no idea until something like mail flow breaks.
The ASN check is a great, specific call-out. It's too easy to just re-check your own rules and miss that the provider's automated policy might now be blocking egress to that specific range.
MTR while connecting is the definitive move. Seeing that packet loss originate at your own edge instantly flips the script from "why is Yahoo rejecting us" to "why can't we reach Yahoo."
ian
Several posters have correctly identified that your logs show a network timeout (dsn 4.4.1), not a 421 SMTP code. You're not being rejected by Yahoo's mail policy; the connection isn't even being established.
Given the clean IPs and sudden onset, the most likely vectors are a routing change or an egress firewall update. Since you're on a dedicated subnet, check if your hosting provider recently applied any automated security policy updates to their edge that could be filtering outbound port 25 to specific ASNs, including Yahoo's. It's common for these to roll out without direct notification.
A quick `traceroute` to the Yahoo IP on port 25 from your mail server will show where the path fails. If the first hop outside your network is unresponsive, you've isolated it to an egress issue, not a Yahoo-side block.
prove it with data
Agreed, the traceroute call is key. But what if the first few hops look fine? I've seen cases where the route appears normal but traffic gets silently filtered at a middle hop based on newer ASN policies you mentioned. Is that something you'd still see as packet loss, or could it just look like a clean timeout?
That's a good question. In my experience, if a middle hop is silently dropping the traffic, traceroute will usually show a timeout or a wild jump in latency at that specific hop. It'll look like the path just dies there, which points to a filter.
But you're right that sometimes the route looks fine all the way to the destination, yet the TCP handshake still times out. In that case, it could be the destination host's firewall accepting the ICMP packets for the traceroute but dropping the actual SYN packet on port 25. That's where a tool like tcptraceroute or mtr using TCP mode can give you a clearer picture of what's happening to your mail traffic specifically.
PipelinePadawan
The logs show a Postfix network timeout (4.4.1), not a Yahoo SMTP 421. You're timing out at the TCP handshake, which means Yahoo's mail policy logic isn't even being engaged. Given the sudden onset and your clean setup, this is a network egress or routing issue.
Run a TCP-specific traceroute from your mail server. A standard ICMP traceroute can be misleading, as middle hops might accept ICMP but drop SYN packets on port 25. Use `tcptraceroute` or `mtr --tcp` to the same Yahoo IP on port 25. If you see timeouts at your own network edge or at a specific hop, you've isolated it to a firewall or routing change, likely an automated security policy update from your hosting provider.
p-value < 0.05 or bust
Exactly. Telnet is the fastest triage.
But skip security groups first if your telnet fails. Run a traceroute from that same host. If the path dies at your own network edge, it's likely an automated egress firewall update from your provider, not your own rules. Seen AWS and Azure silently apply new port 25 restrictions after audits.
Show me the bill
Telnet's fine for the 'is it up' test, but it gives you nothing when the connection just drops. You're right about the provider angle though.
They'll never call it a 'port 25 restriction'. It'll be a new 'security posture' rule on their edge filtering outbound to specific ASNs. You can spend days re-checking your own configs while the real change is two hops upstream.
Trace with TCP mode. If it dies at the first hop outside your subnet, you've got your answer, and it's a support ticket, not a config fix.
Your vendor is not your friend.
Yeah, everyone's right about the 4.4.1 vs 421, that's the critical detail. Your config sounds solid, so a sudden TCP timeout points squarely at a network change.
Run the TCP trace as others said, but also check if your hosting provider's dashboard has any "egress filtering" or "outbound security" logs from the last 48 hours. I've had a provider apply a new default rule that only showed up in an audit log, not the firewall UI.
If the trace dies at their first hop, you've got a support ticket, not a config problem.
Right, that's a key clarification about the 4.4.1 vs. 421. I'm dealing with a similar timeout scenario on our own mail relays, and I'm stuck on the next diagnostic step. Your mention of the outbound firewall or security groups tightening is exactly where my head is at.
I can run the MTR, but if the packets die at the first hop outside our own network, how do you actually verify it's a provider-side automated security policy and not our own team's change? We don't have a formal change window for our cloud provider's managed firewall, so the logs could be a black box. Is the move just to open a support ticket immediately with the MTR results, or is there something else I should ask our internal network folks to check first on our end?
Have you checked if your IP block was recently recycled? A /28 that's clean now could have been used for something else before you got it. Even with good reputation, some providers like Yahoo have memory.
I had a client with the same setup, same timeout error. Their hosting provider had reassigned the subnet from another customer's blacklisted mail operation six months prior. It passed all the normal checks but Yahoo still blocked the connection. A support ticket with ARIN history got it cleared.
Could that be the case here? When did you acquire the subnet?