In Gmail open the message, click the three-dot menu and choose Show original. In Outlook double-click the message, then File and Properties — the headers are in the Internet headers box. In Yahoo Mail use More and View raw message. In Apple Mail use View, Message, All Headers. Copy everything and paste it into the box above.

No, and neither can any header analyzer. Messages sent through Gmail, Microsoft 365 or a commercial ESP show the provider's server IP, not the sender's device. The origin IP identifies the sending platform and sometimes the region of its data center. Only the sending provider, under legal process, can map a message to an account.

DNS shows intent; Authentication-Results shows the outcome. It records the SPF, DKIM and DMARC evaluation the receiving server actually performed on that specific message, including which domains were checked. If DNS looks correct but real messages show a fail, the header tells you which identity broke — usually a Return-Path or signing domain that does not align with the From domain.

Yes. The parser runs entirely in your browser with no network requests — headers are never uploaded, stored or logged. If you are still cautious, strip the Subject and body before pasting; the routing and authentication analysis only needs the Received, Authentication-Results, DKIM-Signature, From and Return-Path lines.

Open the message, view its raw source, and paste the headers above. The Authentication-Results header written by the receiving server carries the verdicts — spf=, dkim= and dmarc= — along with the domain each was evaluated against. That last part matters most: a pass against the wrong domain does nothing for DMARC.

Open the message, click the three-dot menu at the top right of the message itself rather than the toolbar, and choose Show original. That opens the full raw source in a new tab, which you can copy in one go. Outlook on the web calls the same thing View message source.

The signature was cryptographically valid, but the domain that signed it — the d= value — is not your From domain, so it cannot satisfy DMARC alignment. This is the default behaviour of many sending platforms, which sign with their own domain until you publish their keys under yours. Fixing it means publishing DKIM in your own DNS.

SPF is evaluated against the Return-Path, which recipients never see and which your sending platform often sets to its own domain. DMARC requires the passing domain to align with the visible From domain. If the platform supplies the Return-Path, SPF passes for them and DMARC still fails for you — unless DKIM is aligned instead.

They tell you which platform, not which person. The first public IP in the chain belongs to Gmail, Microsoft or the ESP that handled the message — webmail providers stopped exposing the originating client's IP years ago. For judging whether a message is legitimate, the platform plus the authentication verdicts is usually the more useful answer anyway.

Each Received line carries a timestamp, so the gap between two hops is measurable. A multi-minute pause at one specific hop usually means greylisting on first contact, a scanning gateway holding the message for inspection, or queuing at a throttled relay. Healthy end-to-end transit is a few seconds.

Parsing happens entirely in your browser — the headers are not uploaded anywhere. That said, headers can contain recipient addresses and internal hostnames, so apply the same judgement you would to any tool handling client data.