Behind the scenes of our first major technical incident

This week, some of our users ran into a serious problem: documents shared from There were never reaching their recipients. No error message, no warning on their end. The document was "sent". Just never received.

It took us nearly two days to understand what was actually going on. Here's the full story.

Monday: signals that were hard to read

Monday June 22rd at 10:54am, a user calls us. He sends a document to himself from There and receives nothing. First instinct: check spam. We ask him to share the document with us directly — it works perfectly. We chalk it up to an isolated case.

At 4:40pm, a second report: a recipient couldn't open a sharing link from their email client, with the warning "opening this website may not be safe". We test the link internally on a Windows environment with Windows Defender enabled. No issue. We note the signal, put it down to a false positive.

By evening, more reports come in. Some recipients are receiving documents, others aren't. Something bigger starts to take shape.

Tuesday: we know there's a problem, but not what it is

Tuesday morning, we start investigating in earnest. We quickly establish that the problem is hitting Microsoft email inboxes exclusively — Outlook, Hotmail, Exchange, Microsoft 365. And critically: the emails aren't going to spam. They simply aren't being delivered at all.

What makes the diagnosis so difficult is that on our end, the emails appear as perfectly delivered. Our sending provider (Mandrill) shows no errors. We dig into email content, domain reputation, technical headers.

That's when we contact Mandrill's support team, who tell us there's an ongoing technical incident on their side affecting some outgoing emails. They assure us the issue is theirs to fix and will be resolved shortly. We have a lead. We wait.

From Tuesday morning, we put up an alert banner in the app and keep our status page (status.there.do) updated in real time.

Wednesday: the wrong lead closes, the real problem remains

Wednesday morning, the Mandrill incident is resolved. Ours isn't.

We decide to go further and set up a Windows environment with Microsoft 365 Business internally to test our own emails end to end. This is the step that changes everything.

We find our emails sitting in quarantine inside Microsoft Defender, flagged as a "Phishing" threat.

Everything clicks into place. Monday afternoon's report — "this website may not be safe" — wasn't an isolated false positive. It was the first visible symptom of something that had been happening silently from the start.

After several tests, we confirm: the problem isn't the emails themselves, but the app.there.do/* URLs they contain.Microsoft Defender is treating them as potentially malicious, for reasons Microsoft is not able to explain to us to this day.

We immediately submit our URLs through their reporting tools. Every analysis comes back with "No threats detected". The URLs remain flagged regardless.

Thursday: we work around it

Rather than waiting on Microsoft, we ship an update that replaces all app.there.do/* links in sharing emails with share.there.do/* links, a subdomain that isn't affected by the flagging. Sharing starts working again for Microsoft recipients.

What we take away from this

This incident was particularly hard to handle because it stacked three factors that made diagnosis genuinely difficult.

A third-party infrastructure with no visibility on the recipient side. Emails appeared as delivered on Mandrill's end. No error signals from our side. It was only by rebuilding a full test environment internally that we could see what was actually happening at the recipient's end.

A misleading lead at the worst time. Mandrill's support team confirmed an incident was ongoing on their side, which sent us in the wrong direction for an entire day.

A black box on Microsoft's side. Microsoft cannot tell us why app.there.do started getting flagged overnight. No accessible logs, no notification, no explanation. A healthy domain can get silently filtered, with direct consequences for the businesses that depend on it, and no way for them to know what triggered it. That's the part of this incident we found hardest to come to terms with.

What's next

We're continuing to work with Microsoft to have app.there.do recognised as a trusted domain, but we can't guarantee the situation won't recur in the meantime.

What we can do is strengthen our own infrastructure. The workaround we shipped on Thursday is more than a patch: the intermediate page introduced on share.there.do will let us better distinguish a genuine human opening a document from an automated security bot scan — which is precisely what triggered the false positive with Microsoft Defender. That's a foundation we'll keep building on.

We're also working to bring our sharing emails in line with the latest deliverability standards. That will likely mean a few visible changes in the coming weeks to how sharing notifications arrive for your recipients.

We're genuinely sorry for the disruption this caused. This isn't the level of reliability we want to offer, and this incident has given us concrete reasons to go further.

If you have any questions or would like to take a moment with your technical team, don't hesitate to reach out directly.