The answer was in the bounce: an email delivery diagnosis

“Clearly the issue is with us”

That was the owner’s own verdict. A five-person interior design studio on Microsoft 365 was getting bounce-backs daily, and she had reached the end of her tether: “I am about to have a breakdown as we can not work like this, emails are not being sent to people. I am serious.” She had also decided, firmly, that it was impossible for anyone else’s email to be causing it.

That conclusion is the normal one. When mail starts bouncing, the instinct is that you are the problem — that your domain has been blacklisted, your records are wrong, or your provider has broken something. It is a horrible feeling for anyone whose work arrives and leaves by email, and a design studio sending drawings, schedules and quotes to clients and suppliers is precisely that kind of business.

Reading what the bounce actually said

A bounce is not a failure notice. It is a report, and it names the machine that refused the message and the reason it gave. So rather than start changing settings, our team went to the non-delivery reports and read the headers properly.

Two things came out of that. First, the studio’s own email authentication was fine — SPF, DKIM and DMARC all passed. Those three records are how a receiving server decides whether mail claiming to come from your domain really does. If they had been failing, that would have been the story, and it would have been fixable at her end. They were not failing.

Second, the reason the messages were being rejected was written into the report in plain text: a 550 5.4.310 response, meaning the recipient’s DNS domain does not exist. The address she was writing to was on a domain that had gone. No amount of work on her mail setup could deliver a message to somewhere that had stopped existing.

What we could honestly tell her

We could show her where the fault sat, and it was not with her. The records she had been told to worry about were passing. The bounce she was reading as an accusation was a receiving system telling her a destination had disappeared.

We are not going to dress that up as a triumphant fix, because it wasn’t one. Nobody at this end could restore someone else’s domain. What changed was that she stopped spending her days trying to repair something that was not broken — which, when you are in that state about your email, is worth a good deal on its own. If you want the plain-English version of what those three records do, we’ve written it up as SPF, DKIM and DMARC explained.

About this case study

This was one visit in an ongoing relationship — the same studio had earlier had a workstation crawling under heavy AutoCAD work, which is how we came to know their setup. The client is anonymised and the quote is used with her identity removed, but the message, the headers and the finding are real, and the work was done by our team. Diagnosis before intervention is most of what good email setup and troubleshooting is, and it is the habit we bring to ongoing IT support generally: read the evidence in front of you before you touch anything.