What is the difference between header fields and metadata shown to users?

Open any email and you see From, To, Date, and Subject. That's the cleaned-up version your email client wants you to see. Behind that, there's a full set of header fields with routing data, authentication results, spam scores, and server hops. Most email clients hide those by default because they're technical and dense.

Here's what's actually in the full header that you never see:

• Received: headers (one for every mail server the message passed through)
• Return-Path: (where bounces go, often different from the From address)
• DKIM-Signature: (cryptographic proof the email wasn't tampered with)
• SPF and DMARC results (authentication pass/fail)
• X-headers (custom fields added by spam filters, ESPs, or internal tools)
• Message-ID: (unique identifier for the email)

The user-facing metadata is defined by RFC 5322, the standard that governs internet email format. It's the same standard that created the From, To, Subject, and Date fields everyone knows. But RFC 5322 also allows for dozens of optional header fields that serve technical purposes rather than human ones.

Why the gap? Email clients simplify the view because most people don't need to see routing paths or authentication results. But when you're troubleshooting delivery, diagnosing spoofing, or tracking down why an email landed in spam, the full header is where the answers live. Gmail calls it "Show original." Outlook calls it "View message source." Same thing: the raw technical data behind the cleaned-up version.

If you're debugging an email, grab the full header and paste it into our Email Header Analyzer. It'll decode the routing path, show authentication results, and flag any issues. Or check out why display names don't always match the actual sender address.