Reading Headers, Links, and URLs with AI

Under every email is a hidden layer most people never see: the headers, a block of technical text that records where the message really came from and how it traveled. Attackers can fake the friendly parts of an email, but headers and URLs leave fingerprints. In this lesson you'll use AI to decode these fingerprints in plain English, so you can catch fakes that look convincing on the surface.

What You'll Learn

• What email headers are and which lines matter for triage
• How to read the three key authentication checks: SPF, DKIM, and DMARC
• How to dissect a suspicious URL to find its real destination
• Prompts that turn intimidating technical text into a clear verdict

What Are Email Headers?

Every email carries a header: metadata added by each mail server it passes through. In Gmail you find it under "Show original"; in Outlook under "View message details" or "Properties." It looks like a wall of cryptic lines, which is exactly why AI is so useful here. You don't need to memorize the format; you need to know what to ask.

The lines that matter most for triage are:

• From / Return-Path — the claimed sender and the address bounces go to. If these disagree, be suspicious.
• Received — the chain of servers the email passed through, read bottom to top. The bottom-most shows the true origin.
• Authentication-Results — the verdict of the automated checks (SPF, DKIM, DMARC). This is gold.

SPF, DKIM, DMARC: The Three Guards

These three mechanisms let a receiving mail server judge whether an email is really from the domain it claims. You don't need to configure them; you need to read their results.

• SPF (Sender Policy Framework) checks whether the sending server is authorized to send for that domain. spf=pass is good; spf=fail or softfail is a warning.
• DKIM (DomainKeys Identified Mail) checks a cryptographic signature proving the message wasn't tampered with and came from the domain. dkim=pass is good.
• DMARC ties SPF and DKIM together and tells servers what to do on failure. dmarc=pass is good; dmarc=fail is a strong red flag, especially for a well-known brand.

A simple rule: an email claiming to be from a big, reputable company that shows spf=fail and dmarc=fail is very likely spoofed. Real companies configure these correctly.

Try It Now: Decode a Header with AI

Here's a fictional, trimmed header. Paste it into ChatGPT, Claude, or Gemini with the prompt below:

Role: Email security analyst.
Task: Explain what this email header tells us and whether the
message is likely spoofed. Focus on SPF, DKIM, DMARC, and any
mismatch between From and Return-Path.
Format: Plain-English summary + a Safe/Suspicious/Malicious lean.

Header:
From: "Your Bank" <alerts@yourbank.com>
Return-Path: <bounce@shady-mailer.biz>
Received: from shady-mailer.biz (192.0.2.55)
Authentication-Results: spf=fail dkim=none dmarc=fail

The AI should flag it hard: the Return-Path domain doesn't match the claimed sender, the originating server is unrelated to the bank, and all three authentication checks failed. That combination points to spoofing. You just read a header without knowing header syntax, because you let the AI translate.

Dissecting Suspicious URLs

Links are where victims actually get hurt, so learn to read a URL like an analyst. The most important part is the registered domain: the part right before the final country/.com piece, plus that piece.

Consider http://secure.yourbank.com.login-verify.ru/account. Beginners see "yourbank.com" and relax. But read it right to left: the real domain is login-verify.ru, and yourbank.com is just a subdomain an attacker added to fool you. The whole thing is controlled by login-verify.ru. This trick, burying a trusted name as a subdomain of an attacker domain, is extremely common.

Other URL red flags to ask AI about:

• Look-alike domains: paypa1.com, g00gle.com, micros0ft-support.net
• Raw IP addresses instead of a domain: http://192.0.2.10/login
• URL shorteners hiding the true destination: bit.ly/xyz (not always bad, but opaque)
• Mismatched link text vs destination: text says one thing, the underlying href says another
• Odd top-level domains for a brand: a "bank" link ending in .zip, .click, or a random country code

Never visit a suspicious link to "check it." Analyze the text of the URL, or use a sandboxed URL-inspection service your team approves. Curiosity clicks are how incidents start.

Try It Now: URL Verdict

Paste these fictional URLs and ask for a verdict on each:

Role: SOC analyst.
Task: For each URL, identify the real registered domain and say
whether it looks safe or suspicious, with one reason.
Format: A table: URL | Real domain | Verdict | Reason.

1. https://account.microsoft.com/security
2. http://microsoft.com.account-verify.ru/login
3. https://paypa1-secure.com/verify
4. http://198.51.100.7/reset-password

Check the AI's reasoning against what you now know. Numbers 2, 3, and 4 are all suspicious for the reasons above; number 1 is the genuine domain. If the AI and your own read agree, you've got a solid verdict.

A Word of Caution on AI and Technical Data

AI is excellent at explaining headers and URLs, but it can occasionally misread a detail or state something with false confidence. Use it to translate and to catch things you'd miss, then verify the critical facts yourself (does the domain really end where the AI says? do the auth results really say fail?). The pattern is always the same: AI accelerates, you confirm.

Key Takeaways

• Email headers record where a message truly came from; the key lines are From/Return-Path, Received, and Authentication-Results.
• SPF, DKIM, and DMARC are automated checks; multiple 'fail' results on a message from a big brand strongly suggest spoofing.
• Read URLs right to left to find the real registered domain; a trusted name can be a mere subdomain of an attacker's domain.
• Watch for look-alike domains, raw IP links, shorteners, and mismatched link text, and never click a suspicious link to test it.
• Let AI translate the technical text, then verify the critical details yourself.