When troubleshooting missing emails, unexpected spam classification, or delivery delays, reviewing the rendered message in Gmail is rarely enough. The actual forensic trail lives inside the raw RFC 5322 email headers. Gmail’s “Original Message” tool exposes this hidden metadata, detailing the exact server-by-server route the message took, authentication results (SPF, DKIM, and DMARC), and latency at every network hop. Learning to read these headers allows you to isolate why an email failed authentication or where it stalled in transit.
Quick Answer
In Gmail webmail, open the email, click the three vertical dots next to the “Reply” button, and select “Show original”. The top summary table shows immediate PASS or FAIL results for SPF, DKIM, and DMARC. Below it, read the raw
Received:header lines from bottom to top to trace the message’s delivery path.
Accessing the Raw Headers in Gmail
To access the raw message metadata:
- Open Gmail on a desktop browser.
- Open the email message you need to diagnose.
- Click the More icon (three vertical dots) located in the upper-right corner of the message body (next to the Reply arrow).
- Click Show original.
- A new browser tab will open displaying two distinct sections:
- The Diagnostic Summary Card: A formatted table providing high-level authentication statuses.
- The Raw Header Block: The unformatted plain-text headers and MIME message body. You can use the Copy to clipboard or Download Original buttons for further analysis.
[Inbox Message Body] ──► Click Three Dots ──► Select "Show original"
│
▼
┌──────────────────────────────────────────────────┐
│ GMAIL SUMMARY CARD │
│ • Message ID, Created Date, From, To, Subject │
│ • SPF: PASS / FAIL / SOFTFAIL │
│ • DKIM: PASS / FAIL │
│ • DMARC: PASS / FAIL │
└─────────────────────────┬────────────────────────┘
│
▼
┌──────────────────────────────────────────────────┐
│ RAW RFC 5322 HEADERS (Read Bottom-to-Top) │
│ [Hop 3: Final Delivery] Received: by mx.google │
│ [Hop 2: Security Filter] Received: by gateway │
│ [Hop 1: Originating MTA] Received: by mail.orig │
│ │
│ Authentication-Results: mx.google.com; ... │
│ Return-Path: <bounces@sender.com> │
└──────────────────────────────────────────────────┘
Step 1: Decode the Summary Card
The summary card at the top provides an immediate snapshot of the email’s core identity checks:
- SPF: Indicates whether the connecting mail server’s IP was authorized to send on behalf of the envelope domain.
- DKIM: Shows whether the digital cryptographic signature generated by the sender was verified by Google.
- DMARC: Confirms whether the email passed SPF or DKIM with identifier alignment against the visible
From:address.
If any of these values display red warnings or read FAIL, delivery issues and spam placement are almost certainly tied to domain authentication errors. For guidance on resolving DMARC-level rejections, see “Message rejected due to DMARC policy”.
Step 2: Trace the Server Route Using Received: Headers
The raw text beneath the summary card contains the chronological record of every server that handled the message.
Critical Rule: Received: headers are added to the top of the message as it moves across the internet. To trace an email chronologically, you must read from the bottom up.
Anatomy of a Received: Header
Received: from mail.sender.com (mail.sender.com. [198.51.100.25])
by mx.google.com with ESMTPS id abc123xyz
for <recipient@example.com>
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384);
Wed, 23 Sep 2026 09:14:22 -0700 (PDT)
Each entry tells you:
from: The hostname and IP address of the server sending the message at this step.by: The hostname of the server receiving the message at this step.with: The protocol used (e.g., ESMTPS indicates transport-layer encryption was active).- Timestamp: The date and time the receiving server took custody of the email.
How to Spot Latency and Bottlenecks
To determine why an email arrived late:
- Locate the bottom-most
Received:line and note its timestamp (when the sender submitted the email). - Move upward to the next
Received:line and compare the timestamp. - Calculate the time difference between each hop. If Hop 1 stamped the message at
09:00:00and Hop 2 stamped it at09:45:00, the delay occurred while sitting in the queue of the Hop 1 server, not within Google’s network.
Step 3: Analyze the Authentication-Results Header
While the summary card gives a simplified pass/fail score, the Authentication-Results header contains the technical details Google used to reach that conclusion:
Authentication-Results: mx.google.com;
dkim=pass header.i=@example.com header.s=google header.b=AbC123;
spf=pass (google.com: domain of sender@example.com designates 198.51.100.25 as permitted sender) smtp.mailfrom=sender@example.com;
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com
Key forensic components:
smtp.mailfrom=(orReturn-Path): The domain used during the SMTP envelope handshake. This is the domain evaluated for SPF.client-ip=: The exact public IP address that connected to Google’s mail server.header.s=: The DKIM selector used to look up the public key in DNS.header.i=/header.d=: The domain that signed the email.header.from=: The human-readable domain displayed in the user’s inbox.
If SPF displays a softfail, the IP was not listed in the sender’s DNS record; see Resolving SPF “Softfail” vs. “Hardfail”. If SPF shows a fail with an invalid setup, consult How to Fix Gmail Error 550 5.7.26: SPF Missing/Invalid.
Step 4: Compare From: vs. Return-Path
A primary cause of spoofing alerts is a mismatch between what the user sees and what the mail servers processed:
From:Header: The address visible in the Gmail user interface (e.g.,ceo@yourcompany.com).Return-Path:Header: The underlying technical address where delivery bounce-backs are sent (e.g.,marketing@mailplatform.net).
If the domains in these two headers do not match, SPF cannot achieve DMARC alignment. If the message also lacks a valid DKIM signature matching yourcompany.com, Gmail will flag the email with a warning banner; see Gmail “Safety Warning” for Spoofed Emails.