Architecting an SMTP-Reputation-First Verification Pipeline Why Policy Rejections Are Often an Infrastructure Problem

Eleven days of debugging. Rohan wasn't a beginner. He read raw server logs, understood SMTP response codes, and wrote retry logic most engineers wouldn't bother with. His hard block rate on Microsoft 365 addresses had climbed to 23%, so he did what careful engineers do: he checked his sending domain's authentication records (valid), audited retry intervals and connection timeouts, and rewrote his 5xx handler to sort responses by subtype into separate retry queues.

This post explains how to tell whether a 5xx is about your software or about the origin your queries come from, and how to design a pipeline that accounts for the difference.

01What a 5xx tells you, and what it doesn't

A 5xx response means the receiving server has rejected the attempt. Unlike a 4xx deferral, it isn't an invitation to retry. But the number alone doesn't tell you why. Two broad categories matter for verification:

• A result about the address. The classic example is 550 5.1.1, meaning the mailbox doesn't exist. The server answered, evaluated the recipient and gave a definitive result. That's a successful verification.
• A result about the sender. Codes like 550 5.7.1 and 554 5.7.1 generally signal a policy rejection of the connecting origin, not a judgement on the address. Providers use varied enhanced codes and wording, so read the full response text rather than relying on the code alone.

Rohan treated 5.7.1 rejections as verification results and built three retry queues for them, at 15 minutes, 45 minutes and two hours. If the rejection is about the origin, retrying from the same origin at a different time rarely changes the outcome — what the server knows about that IP hasn't changed. What changes is how much traffic it sees from that IP.

Whether that extra traffic worsens his reputation signal depends on how each provider scores it, which no provider publishes. But it certainly doesn't help.

02A diagnostic that separates the causes

Before building any retry strategy, run these checks. They take around an hour in total and rule out the most common causes in order.

1. Rule out basic sender hygiene Many 5.7.1 rejections have mundane causes unrelated to query history:
   • Blocklist listings. Check each sending IP against major blocklists. Some ranges, especially residential and cloud ones, are listed by default.
   • Reverse DNS. The IP should have a PTR record that resolves sensibly, and the name should resolve back to the same IP.
   • HELO/EHLO. The name you announce should be valid and consistent with your DNS.
   • Authentication records. SPF, DKIM and DMARC matter for sending mail. Many verification probes never send message content, so check whether they're relevant to your queries before treating them as the cause.
   If any of these fail, fix them first — they'd explain a policy rejection regardless of IP age.
2. Read the response text The numeric code won't separate the cases, but the message often does. Reputation-related rejections tend to mention the IP, the sender or a score threshold. Configuration-related ones tend to name a specific missing or failing element. Log the full text, not just the code.
3. Compare origins on a random control sample Take 100 addresses chosen at random from your Microsoft 365 traffic. Don't hand-pick addresses that previously failed — a set chosen for rejection will tend to look better on a second try regardless of origin. Query the same set at the same time of day from two origins: your own IPs and an IP with an established verification history.
4. Compare your own IPs by age If you run several IPs, pull the 5.7.1 rate per IP on comparable traffic and sort by how long each has been querying. Check that they share a network block, volume and configuration — any of those could explain a difference. Per-IP differences can also come from per-IP problems such as a missing PTR record, so go back to step 1 if the pattern is unclear.

03Why new IPs often get higher rejection rates

Large mail providers evaluate the senders that connect to them. Nobody outside the provider knows exactly how, but the general idea is well established: an IP with no history gives the provider nothing to judge it on, and many systems treat unknown origins cautiously until they've seen consistent, ordinary behaviour.

Across pipelines we've worked with, Proxy25 sees rejection rates on Microsoft 365 addresses follow roughly this pattern:

Proxy25's own observations, not published provider behaviour. Individual results vary widely.

If your own measurements look similar, the practical conclusion is that query history is a factor you build over time, not one you tune in code. Better pacing, batching and retry logic won't give an IP a history it doesn't have.

04What Rohan changed

Rohan's architecture was sound. His subtype categorisation, his routing and his per-IP instrumentation were all better than average. The constraint sat one layer below the code. He made two changes:

• Stop retrying policy rejections from the same origin. He disabled retries for 5.7.1 responses. Retries still apply to 4xx deferrals and configuration-based failures, where timing can matter. This brought his apparent connection volume to enterprise servers back down to his true volume.
• Route enterprise domains through origins with established history. For Microsoft 365 and Google Workspace addresses (61% of his list), he used infrastructure with over a year of clean verification history. His own IPs kept handling other domains, where new IPs generally face less scrutiny, and built history as they went.

He treated this as a ramp rather than a permanent split. As his own IPs aged, he planned to move enterprise traffic back in stages, watching the block rate at each step.

A fair caution: he made both changes together, so the improvement can't be split between them. A cleaner approach is to make the changes one at a time and measure after each.

05Your options

Teams in this position have three realistic paths:

• Build history yourself. Warm up new IPs gradually, with consistent volume and no sudden spikes, and expect the 9–18 month timeline above. The cheapest option and the slowest.
• Use infrastructure with existing history. This is what Proxy25 provides: IPs with verified SMTP query history against major mail environments. It gives faster results on enterprise domains, but you depend on a provider and should check how the IPs are sourced.
• Reduce what you ask of the servers. Cache results, deduplicate, skip addresses you don't need to verify, and use signals other than live SMTP checks where they're good enough. This lowers volume whichever path you choose.

Whatever you pick, follow providers' rate limits and acceptable-use policies. These controls exist to stop address harvesting, and a verification service that behaves like a harvester will be treated like one.

06The short version

• A 5xx isn't automatically a verification result. Work out whether it's about the address or about your origin.
• Rule out blocklists, reverse DNS and HELO issues before concluding the problem is query history.
• Test with a random sample, not a hand-picked one.
• Don't retry policy rejections from the same origin.
• Treat query history as infrastructure you build or connect to, and make changes one at a time so you know what worked.