SERVFAIL is somewhat hard to troubleshoot.
(I've recently explained that in another post in German).
Luckily, more often then not, these failures are only temporarily, some of them disappearing as early as for the very next repeated DNS request. It is not uncommon for Pi-hole to encounter a SERVFAIL every once in a while without you even noticing it.
SERVFAIL is just a generic error message indicating a server side resolution failure. Until recently, there was no indication as to the reason for failure or what server in the chain of DNS servers caused.
RFC 8914 is the most recent attempt at changing that by supplying Extended DNS Error codes.
As that standard is comparably new (dating Oct 2020), implementation support is still lacking. Currently, I am only aware of Cloudflare DNS returning those codes.
In case you encounter another persistent SERVFAIL, you could try a dig for the failed domain against Cloudflare's DNS, e.g.
dig @1.1.1.1 presence.teams.microsoft.com
Look for the OPT return codes similiar like this (taken from a sample query, not from the above dig)
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; OPT=15: 00 06 ("..")
OPT=15 indicates an EDE (Extended DNS Error), followed by the error code, 06 for DNSSEC Bogus in this case.
Newer versions of dig may supply textual outpout straight away.
Note that Cloudflare still may show no errors while your actual DNS lookup fails, or vice versa.
So the diagnostic value of such a query is not very high.
Still, it may reveal systematic failures of the same DNS server present in both resolution chains.
Though that would potentially give you a reason for the failure, it would be up to the DNS server maintainers to address that.
There is nothing you can do about the root cause, save from changing your upstream, maybe.