The day Microsoft blocked our whole subnet

You have done everything a serious sender is asked to do. Your domain states which servers may send mail on its behalf. Every message is signed. Your server introduces itself under a name that matches what the DNS publishes.

In short, your identity is known and can be verified.

And still, your messages do not reach Outlook.

Not in the junk folder. Not a few minutes late. They are refused before they are ever accepted.

That is what happened to us on 7 and 8 August 2026, on the sending infrastructure behind Spore. Every attempt to reach a Microsoft address came back with the same code: S3140.

What authentication guarantees — and what it does not

Send email in any volume and three acronyms turn up everywhere: SPF, DKIM and DMARC.

They are worth stating plainly.

• —SPF lists, in the domain DNS, which servers are allowed to send on its behalf.
• —DKIM adds a cryptographic signature to every message. The receiving server checks it against a public key published in the DNS.
• —DMARC sets the policy to apply when the two checks above fail, or do not match the expected domain.

Together they answer one question: is the sender really who it claims to be?

They leave another one untouched, and it matters just as much: does this mail deserve to be accepted?

A spammer can hold a clean SPF record, a valid DKIM signature and a correct DMARC policy.

Authentication does not prove a message is wanted. It proves its origin can be checked.

Authentication is a prerequisite, never a pass. It makes you identifiable, and therefore accountable.

The filters only start working after that.

Google, Yahoo and Microsoft are trying to decide whether they can trust what you send. To do it they look at the sending IP address, how long it has existed, how much it sends, the complaints it draws, its delivery failures — and sometimes the reputation of the entire network range it sits in.

The neighbourhood problem

Our IP address had not necessarily done anything wrong.

The problem was its neighbourhood.

An IP address is never truly on its own. It belongs to a range held by a hosting provider and used by many other customers.

When an operator decides that part of that range has sent unwanted mail too often, it can choose to distrust the whole of it.

So you can hold a perfectly clean address and still carry the consequences of what others did.

The logic makes sense.

If filters only ever punished a single address, a malicious sender would simply move to another one. At most hosting providers that takes a few minutes.

Blocking a whole range makes that game more expensive.

The method has an obvious side effect: it also penalises honest senders who happened to settle in the wrong place.

They did nothing in particular, have almost no way of checking their neighbourhood before using the address, and find out once the service is already in production.

Three operators, three ways of judging

Google, Yahoo and Microsoft are often lumped together. In practice their methods differ a great deal.

	Google	Yahoo	Microsoft
Signal watched most closely	Overall reputation and how recipients behave	Complaints and reputation	Reputation of the IP address and its network
When something goes wrong	The message may land in spam	Throttling or refusal	Explicit refusal, with a code
Tools offered	Postmaster Tools	Feedback loop	SNDS and JMRP
How to respond	Fix it and wait	Contact support	Request a block removal

Google is often the hardest to make sense of.

The server can accept your message without error, then file it as junk. As far as your logs are concerned, everything went fine.

The message was delivered, technically.

It simply stands almost no chance of being read.

Microsoft is blunter, and clearer for it. When a message is refused, the refusal shows up in the logs immediately, with a code attached.

At least you know there is a problem.

The administrative maze

Once the block is understood, you still have to find someone to talk to.

And there the technical problem turns into an administrative one.

Search engines point very quickly to a Microsoft portal for deliverability problems. Except the one that surfaces first is mostly about business mailboxes.

Our problem concerned consumer addresses: Outlook.com and Hotmail.

Different service. Different form.

And nothing really tells you so.

You fill in the wrong form, you send your request, and nothing happens.

Nobody replies to say you knocked on the wrong door.

You have to work out that another desk exists, then manage to find it.

We eventually filed with the support team that handles deliverability for consumer mailboxes, with the IP addresses concerned, our sending logs and the configuration details.

Request sent on 9 August. Reply the next day:

Mitigated. These IP(s) have been unblocked but may be subject to low daily email limits until they have established a good reputation.

In other words: the addresses were unblocked, but Microsoft will keep capping their volume until they have built up enough history.

Lifting the block does not reset the counters.

From there you have to send gradually, cleanly, without incident, until the address earns more trust.

And the decision does not necessarily reach every part of Microsoft’s infrastructure at once. For several hours, sometimes longer, some servers may still refuse your messages.

What three days of blocking actually cost

Three days passed between the first refusal and the block being lifted.

The galling part is that there was almost nothing to fix.

The configuration had been correct from the start. SPF, DKIM, DMARC, reverse DNS: all of it conformant. Checking took about an hour.

The rest of the time went into understanding the problem and finding the right person.

It took:

• —working out that an unfamiliar rejection code pointed at a reputation problem, not a configuration error;
• —ruling out the DNS leads one by one;
• —realising the first form we found was not the right one;
• —tracking down the team that actually handles Outlook.com and Hotmail mailboxes;
• —gathering the IP addresses, timestamped logs and raw error messages;
• —waiting for the reply, then waiting again for the unblocking to propagate.

No feature came out of those hours.

Nothing was made better for anyone using the product.

We simply spent three days restoring something that should have worked from the outset.

That is exactly the kind of work you do not want surfacing in the middle of building a product.

What we changed afterwards

At the time, a single IP address carried most of our traffic.

When it was blocked at Microsoft, every message bound for Microsoft went down with it — while 84 other messages were still being delivered normally to other operators.

A problem on one address could have consequences for every one of our customers.

We changed that.

Messages are now split by what they are. Strictly transactional mail no longer shares an address with heavier sending. A new account is not mixed straight into established traffic.

The aim is simple: stop a local incident turning into a general outage.

We also wired up automatic reporting of delivery receipts and rejections.

When a remote server refuses a message, that now comes straight back into our own system.

It no longer ends up in a mailbox nobody thinks to open.

Above all, we learned something no technical documentation really gives you: how the administrative side of these large operators works.

We now know who to contact, what to send and what to have ready.

Next time, the diagnosis will not take three days.

That is part of the service too.

We run the sending infrastructure ourselves: the servers, the IP addresses, the signatures, the logs.

And with that infrastructure come the reputation problems, the unblocking requests and the exchanges with operators.

We take those on.

A server’s reputation is not built at the moment something goes wrong, either. It is maintained with every message sent.

That means verified domains, correct signatures, addresses that no longer exist removed automatically, rejections analysed, and a precise history kept of every attempt.

Our servers are in France. Your domains stay yours. And we bill the messages you send, not the number of contacts sitting in a database.

A sender starting out faces another problem: almost no history.

At a few dozen messages a day, a new address stays hard for filters to judge for a long time. Building a good reputation takes steady traffic and stable behaviour.

This is where the story turns around.

A Spore customer does not land on an address created that morning.

They get infrastructure that is already in use, maintained daily and closely monitored.

Every message delivered properly helps keep that shared reputation up.

You, meanwhile, send your message.

One request.

And off it goes.