What is IP reputation?

Every connection announces an IP before anything else happens. That address is the first thing a receiving filter looks up, and it carries whatever the previous traffic from it earned.

On shared infrastructure you inherit the neighbors. One customer of the same platform running a bad campaign moves the number you are judged on, and you have no lever to pull.

A dedicated address puts the history entirely in your hands, which helps only if you can keep volume steady. Below roughly 50,000 messages a month there is too little signal for receivers to build a picture, and the shared pool usually performs better.

The number decays. Go quiet for two months and a dedicated address needs warming again, because absence reads as a dormant address suddenly waking up.

This is where IP reputation touches verification directly. Say a verifier runs from a cloud provider's address range and asks a Microsoft 365 domain about a recipient. It may never get as far as the question. The refusal arrives early and reads something like 550 5.7.606 Access denied, banned sending IP, followed by the address.

Look at what that reply is about. It doesn't mention the recipient, and it would have been identical for any mailbox at any domain behind that service. A careless tool records a 550 and marks a working address as invalid.

Run the identical probe from an address with a clean history and proper reverse DNS, and the server answers the actual question. The mailbox hasn't changed between the two attempts. This is why a verifier's coverage depends on its infrastructure, and why a refusal aimed at the prober has to come back as unknown.

If your own mail is being refused, start with reverse DNS. Run dig -x on your sending address and you should get a hostname back. Look up that hostname and it should return the same address. Mail servers call this forward-confirmed reverse DNS, and a mismatch gets you scored down before anything else is considered.

Next, read the refusal text for a named blocklist or a provider error code, then query that list for your address. After that, check whether the problem exists at one provider or all of them, since a block at one points at their internal data and not at a public list.

Only then think about the address itself. On a shared pool, ask your platform whether other customers are affected. If they are, moving you to a different pool is their job and takes them minutes. Buying a dedicated address to solve a shared-pool problem mostly trades a bad history for no history.