This tool answers one question: how did this message get here, and what did the servers along the way conclude about it. It reconstructs the route, times each leg, and surfaces the authentication verdicts.
It does not decode encoded text. If a Subject reads as =?UTF-8?B?...?=, or a sender domain is written in punycode as xn--..., that is a different question with a different answer — the header decoder handles those, including flagging lookalike characters in the decoded result. Use the analyzer to establish the path, the decoder to read what a value actually says.
Trust the receiver, not the sender
The most important habit when reading headers: lines added by the receiving infrastructure can be trusted, and lines that existed before the message arrived cannot. A sender is free to invent Received headers, so the early hops in a chain may be pure fiction.
Authentication-Results is the exception worth relying on. It was written by the server that actually performed the checks, at the moment it performed them, which is why a recorded DMARC failure carries far more weight than anything the message claims about itself.
If the verdicts point at a configuration problem rather than a forgery, the SPF checker, DKIM checker and DMARC checker inspect the sending domain's published records directly.