Receiving servers do not read your subject line before deciding whether to accept your connection. They decide at the banner. Proofpoint returns a 554 before EHLO, which means the message has not been opened, parsed, or scanned for content. There is no subject line yet. No personalisation yet. No offer. The verdict was reached on the identity that opened the socket.
Microsoft 365 behaves the same way at the source IP level, returning 550 5.7.606 through 649, Access denied, banned sending IP, before message content is considered.
That ordering is the entire point. Copy, subject lines and personalisation sit downstream of a decision that has already happened. A blocked IP never gets to show its copy. A sender who spends the week rewriting subject lines while the connection is being refused at the banner is optimising a layer that never runs.
Four gates, judged separately
It helps to stop treating deliverability as one thing. There are four gates: IP, identity, domain, recipients. Each is evaluated on its own, and each can fail on its own.
The IP gate
This is about the address that opens the socket. If that address carries a bad reputation with the receiving provider, nothing downstream gets a hearing. The message is refused before it exists as a message.
The identity gate
This is about who you claim to be when you send: your authentication records, whether they align with the domain you are sending as, and the reputation attached to the sending identity rather than the domain alone. Misalignment here is quiet. Mail still leaves your side. It just does not land.
The domain gate
This is about the domain in the From header and the domains in your links. A domain with a broken authentication record will struggle even when the IP is pristine, because the receiver is judging the two things independently.
The recipient gate
This is about who you are actually mailing, how engaged those people are, and how the provider reads your pattern of sending to them. A perfect setup aimed at a list that does not want the mail fails here.
These failure modes do not substitute for each other. A clean domain does not save a blocked IP. A well-built list does not save a domain with a broken authentication record. Fixing one gate while another stays closed gets you nothing, which is why "we fixed deliverability" is rarely a complete statement. It usually means one gate was patched and the others were never inspected.
The direction of the check
You do not check blocklists. The receiver checks you.
That is the line worth sitting with, and it was the part of the original post that stayed with me. Most sender-side checklist advice is written as though you are the one doing the inspecting, and it is pointed the wrong way. A sender can work through every item on the list, tick every box, and still see nothing but silence, because none of those items measured what the receiving server actually measured.
Blocklists are not something you consult and clear. They are something you appear on, or do not, based on behaviour the receivers observe over time. Same with IP reputation, same with domain posture. The scoreboard is on their side of the wall.
Watch the identity, not the draft
If the gate is checked before the message, then the thing worth monitoring is the sending identity itself. Continuously, across every mailbox provider and every domain you send from.
This is a monitoring problem before it is a copy problem. The useful questions are about state, not creativity. Is this IP accepted by this provider right now? Is this domain aligned right now? Is this identity's reputation holding or drifting? Is this provider's posture toward us changing week over week, and would we notice before the replies stop?
Mailheight covers that ground, tracking sender health across Google Workspace, Microsoft 365 and every domain you send from, powered by dnspulse.hamcut.in.
The question to answer honestly
Which gate is your last campaign actually failing at, and would you know from the data you have?
Most teams cannot answer the first half with confidence and cannot answer the second half at all. They know the campaign underperformed. They do not know whether the connection was refused at the banner, whether the domain was misaligned, or whether the list was simply cold. Those are three different problems with three different fixes, and guessing between them is how quarters disappear.
The full post is worth reading in its original form here on LinkedIn.
Start with the gate that runs first. If the IP is refused at the banner, the subject line was never the problem, and it will not be the solution either.