Case study

Mail that never reached Microsoft 365, and a site nobody would wait for

Their website was crawling and their email was disappearing. The web server still considered itself the mail exchanger for a domain whose mail lives in Microsoft 365, so everything the site sent was delivered into a mailbox on the web server: reported as sent, never bounced, never seen. Meanwhile a web application firewall in front of the site had page loads reaching 140 seconds, and with it switched off the site still took 3.59 seconds to paint. The client was reporting a drop in sales over the same period.

All case studies

Client

Industrial supplier

Industrial Supply & Distribution

Faster to first paint: 13×
Largest Contentful Paint, was 3.59s: 0.27s
Mail reaching Microsoft 365 again: Delivered

What we found

Mail the website sent was reported as delivered and never arrived in Microsoft 365. A bounce tells you something failed. This told them everything had worked, which is the version nobody catches until a customer asks why they were ignored.
The cause: the domain's mail lives in Microsoft 365, but the web server still treated itself as the mail exchanger for that domain, so anything the site sent to an address there was delivered into a local mailbox on the web server. On that platform the domain could not be switched to a remote exchanger, so there was no way to make it hand the mail over.
A web application firewall in front of the site pushing page loads as high as 140 seconds, to the point where it had to be switched off entirely just to leave the site usable.
Even with the firewall gone, 3.59 seconds to paint the main content, which is well past the point where visitors stop waiting.
The client reporting a drop in sales over the same period.

What we did

Told them to log the mail fault with their existing provider first. A migration is not a diagnosis, and we would rather lose the job than sell one as the fix for something that might be a support ticket. They chose to move.
Migrated onto LiteSpeed on Fire-IT's premium WordPress hosting, where the domain can be set to deliver to a remote exchanger, so mail the website generates is handed to Microsoft 365 instead of to a mailbox on the web server.
Rebuilt the outbound path around that, so messages authenticate properly and arrive, and can be traced at both ends rather than trusted from a success message.
Put the environment behind a FortiGate firewall with Imunify360 on the server for malware detection and virtual patching, so the protection sits where it can be tuned instead of in front of every request from every visitor.

What changed

Largest Contentful Paint measured at 0.27 seconds, down from 3.59: roughly thirteen times faster to show a visitor anything at all.
Layout stability stayed inside Google's good band across the move.
Mail arriving in Microsoft 365, and verifiable at both ends rather than trusted from a success message.
Site, mail and security on infrastructure Fire-IT runs and can be held to.

Services delivered

Next case study

Off a third-party platform onto colocated hardware that runs 20× faster

Read it

Engage

Let's scope your environment.

Tell us what you're running today. We'll map the gaps and quote a path forward, no obligation.

Build a solution Talk to us or call 012 004 0615

Mail that never reached Microsoft 365, and a site nobody would wait for

What we found

Mail the website sent was reported as delivered and never arrived in Microsoft 365. A bounce tells you something failed. This told them everything had worked, which is the version nobody catches until a customer asks why they were ignored.

The cause: the domain's mail lives in Microsoft 365, but the web server still treated itself as the mail exchanger for that domain, so anything the site sent to an address there was delivered into a local mailbox on the web server. On that platform the domain could not be switched to a remote exchanger, so there was no way to make it hand the mail over.

A web application firewall in front of the site pushing page loads as high as 140 seconds, to the point where it had to be switched off entirely just to leave the site usable.

Even with the firewall gone, 3.59 seconds to paint the main content, which is well past the point where visitors stop waiting.

The client reporting a drop in sales over the same period.

What we did

Told them to log the mail fault with their existing provider first. A migration is not a diagnosis, and we would rather lose the job than sell one as the fix for something that might be a support ticket. They chose to move.

Migrated onto LiteSpeed on Fire-IT's premium WordPress hosting, where the domain can be set to deliver to a remote exchanger, so mail the website generates is handed to Microsoft 365 instead of to a mailbox on the web server.

Rebuilt the outbound path around that, so messages authenticate properly and arrive, and can be traced at both ends rather than trusted from a success message.

Put the environment behind a FortiGate firewall with Imunify360 on the server for malware detection and virtual patching, so the protection sits where it can be tuned instead of in front of every request from every visitor.

What changed

Largest Contentful Paint measured at 0.27 seconds, down from 3.59: roughly thirteen times faster to show a visitor anything at all.

Layout stability stayed inside Google's good band across the move.

Mail arriving in Microsoft 365, and verifiable at both ends rather than trusted from a success message.

Site, mail and security on infrastructure Fire-IT runs and can be held to.