E-signature emails weren't arriving, and two vendors each blamed the other - how do you find out which side is actually wrong?

One day, “please sign” emails sent through a third-party e-signature service stopped arriving entirely for recipients on two of the company’s own Microsoft 365 tenants - no bounce, no error, nothing unusual in the service’s own activity log. The same request sent to the same person’s personal Gmail address, though, arrived normally. This class of “some recipients get it, some don’t, and nobody’s logs show an error” problem has one uniquely frustrating property: both vendors’ own system logs show everything working fine on their end.

Cross-testing first: turn a guess into data

Before contacting either vendor’s support, a few rounds of cross-testing were run, so the eventual conversation could point to concrete data instead of a vague “emails aren’t arriving”:

• Sent to the same recipient’s personal Gmail address → received;
• Sent to Company A’s M365 tenant address → not received;
• Sent to Company B’s (a related entity’s) M365 tenant address → also not received;
• The e-signature service’s own Activity log → no bounce notification of any kind.

This set of results was already strongly suggestive: the failure only occurred for the specific combination of “delivered to one of our own M365 tenants,” independent of who the recipient was or what device they used to check mail.

When both sides say “not my problem,” the cross-test data is the only thing that actually settles it

Two vendors, two versions of “no evidence it’s my fault”

Contacting the e-signature service’s support produced this answer: if the problem were on their end, a bounce would show up in the activity log; since there’s no bounce record and personal mailboxes receive it fine, the issue most likely sits in the recipient’s Microsoft 365 mail server configuration. That logic isn’t wrong on its own - but it also meant the next step was opening a ticket with the other vendor (Microsoft), carrying this same set of cross-test evidence and effectively repeating the burden of proof from scratch.

This kind of “each vendor points at the other” situation is common, especially when a problem crosses the delivery path between two independent systems: each side can only see its own internal logs, and neither has visibility into the full path. Both can honestly say “nothing errors on our side,” while neither can prove the fault genuinely isn’t theirs.

The approach: treat the cross-test record as a handoff document

Facing this kind of stalemate, arguing further with the first vendor is less useful than compiling the cross-tests already completed into a clean record, and using that as the evidence base for the ticket with the second vendor, rather than re-describing the problem from scratch. The advantage: the second vendor doesn’t receive a one-line “emails aren’t arriving” report - they receive a structured set of evidence that has already ruled out external factors (recipient’s network, device, no bounce from vendor A’s system), letting them point their own investigation at their actual configuration faster.

Lessons

1. For a problem spanning two independent systems, cross-test data is more persuasive than either vendor’s own conclusion. Each vendor’s conclusion is only based on the slice of logs they can see - only a cross-system comparison test can actually establish where the problem really occurs;
2. “No error logged” doesn’t mean “this side has no problem.” The e-signature service’s logs showing nothing unusual only rules out the send action itself - it says nothing about whether other parts of the delivery chain (like the recipient’s mail gateway filtering rules) are involved;
3. When two vendors each point at the other, rather than repeating the problem description, structure the investigation already completed and reuse it directly as evidence for the next escalation. That way, each escalation starts further along than the last, instead of explaining everything from zero every time.