Dissecting a Phishing Email: A Technical Walkthrough of Headers, IoCs, and Authentication Failures

PHISHING EMAIL ANALYSIS

By Debbie A. · Cybersecurity Analyst · March 2026

Phishing remains the single most common initial access vector in cybersecurity incidents worldwide. Despite being one of the oldest attack techniques, it continues to evolve — and it continues to work. In this post, I walk through a real-format simulated phishing email analysis I conducted as part of a structured security module, covering everything from raw header forensics to Indicators of Compromise (IoC) assessment and authentication failure interpretation.

This is not a surface-level overview. We are going deep.

The Email: What We Were Given

The subject of analysis was an email purportedly sent from security@vitalcarehealthsolutions.com, addressed to a recipient named Joy, with the subject line:

“Urgent: Action Required for Your VitalCare Health Solutions Account”

On the surface, it reads like a standard account security notification — the kind most people receive and act on without a second thought. It warns of “unusual activity,” demands credential verification within 24 hours, and threatens account suspension as the consequence of non-compliance. A link labelled “Verify My Account Now” is embedded in the body.

Classic phishing playbook. But let us look at what the headers and metadata actually tell us.

📸 [Screenshot: Full raw email headers as received in the mail client]

Step 1 — Reading the Authentication Results Header

The first place any analyst should look is the Authentication-Results header, injected by the receiving mail server (in this case, Google's mx.google.com). This single header tells you whether the three core email authentication mechanisms — SPF, DKIM, and DMARC — passed or failed.

Here is what I found:

Authentication-Results: mx.google.com;
    spf=fail (google.com: domain of security@vitalcarehealthsolutions.com
              does not designate 192.168.1.1 as a permitted sender)
              smtp.mailfrom=security@vitalcarehealthsolutions.com;
    dkim=fail (signature did not verify)
              header.i=@vitalcarehealthsolutions.com header.s=google;
    dmarc=fail (p=NONE sp=NONE dis=NONE)
              header.from=vitalcarehealthsolutions.com

All three failed. Let me break down what each failure means.

Step 2 — SPF: The Sender Is Not Who They Claim To Be

SPF (Sender Policy Framework) is a DNS record that a domain owner publishes to specify which IP addresses are authorised to send email on their behalf. When a receiving server gets an email, it checks whether the sending IP matches the domain’s SPF record.

In this case:

• Claimed sender domain: vitalcarehealthsolutions.com
• Actual sending IP: 192.168.1.1
• SPF result: FAIL

The SPF record for vitalcarehealthsolutions.com does not list 192.168.1.1 as an authorised sender — so the check fails. But the real red flag here goes further than a simple SPF mismatch.

**192.168.1.1 is an RFC 1918 private address.**

RFC 1918 defines three blocks of IP address space reserved for private networks — local LANs, home routers, internal infrastructure. These addresses are:

• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16

None of these addresses are routable on the public internet. It is technically impossible for a legitimate external mail server to originate from 192.168.1.1. This address belongs to someone's internal network — likely a default home or office router gateway. The presence of this IP as the claimed sending address is conclusive evidence of header manipulation and sender spoofing.

📸 [Screenshot: X-Received-SPF header showing client-ip=192.168.1.1 and SPF=fail result — mxtoolbox]

Step 3 — DKIM: The Cryptographic Chain Is Broken

DKIM (DomainKeys Identified Mail) uses asymmetric cryptography to sign outgoing emails. The sending server applies a private key signature to the message headers and body; the receiving server retrieves the corresponding public key from the domain’s DNS records and verifies the signature. If the signature checks out, it proves two things: the message was authorised by the domain owner, and the content was not tampered with in transit.

Result here: dkim=fail (signature did not verify)

This means one of two things:

1. The message was modified after signing, breaking the cryptographic integrity, or
2. No valid DKIM key exists for the google selector on vitalcarehealthsolutions.com, meaning the signature was fabricated or the domain never properly configured DKIM signing.

Either way, the cryptographic chain of trust is completely broken. There is no verifiable proof that vitalcarehealthsolutions.com authorised this email.

📸 [Screenshot: Authentication-Results header highlighting the dkim=fail line]

Step 4 — DMARC: Failed, But With No Teeth

DMARC (Domain-based Message Authentication, Reporting & Conformance) builds on top of SPF and DKIM. It allows domain owners to publish a policy instructing receiving servers what to do when an email fails authentication — none (do nothing), quarantine (send to spam), or reject (block entirely). It also enables reporting back to the domain owner.

Result: dmarc=fail (p=NONE sp=NONE dis=NONE)

DMARC failed — which is expected given that both SPF and DKIM failed. However, the critical detail here is p=NONE. This means the domain owner has configured DMARC in monitoring-only mode, with no enforcement. As a result, despite the authentication failures, the receiving server took no action and delivered the email to the inbox.

This is a significant configuration gap. Had the policy been p=quarantine or p=reject, this email would have been automatically filtered or blocked before ever reaching Joy's inbox.

Step 5 — Structural Header Anomalies

Beyond the authentication failures, a careful read of the full raw headers reveals several structural anomalies that are inconsistent with legitimate mail:

Duplicate header fields. The Content-Type, MIME-Version, and Date fields appear multiple times across the header block — outside the expected MIME boundary structure. Legitimate mail clients and servers generate clean, non-redundant headers. Duplication suggests the headers were manually constructed or generated by a script.

Static, sequential Message-ID. The Message-ID was <1234567890@vitalcarehealthsolutions.com> — a sequential numeric string. Real mail servers generate Message-IDs with randomised components (timestamps, hashes, unique identifiers). A purely numeric, sequential ID is a hallmark of automated phishing tooling.

Exact midnight timestamp. The Date header reads Tue, 6 Mar 2026 00:00:00 +0000. A send time of precisely midnight UTC, down to the second, is statistically improbable for a human-initiated email and is a common indicator of automated generation.

Placeholder Google header. The X-Google-Smtp-Source field contained [Google Source IP Address] — a literal placeholder rather than a real identifier, suggesting the header was manually assembled rather than generated by an actual Google mail server.

Step 6 — Indicators of Compromise (IoCs)

With the header analysis complete, I catalogued the IoCs extracted from the email:

IoC 1 — IP Address: 192.168.1.1

• Type: Source IP (spoofed)
• Classification: RFC 1918 private address
• Risk: Critical — cannot originate external mail; confirms header forgery
• Lookup: AbuseIPDB, VirusTotal (IP reputation)

IoC 2 — URL: [http://malicious-link.com](http://malicious-link.com)

• Type: Payload URL (embedded in email body as “Verify My Account Now”)
• Protocol: HTTP — no TLS/SSL encryption
• Risk: Critical — likely credential harvesting page; any credentials submitted would be transmitted in plaintext
• Lookup: URLScan.io (page screenshot + DOM analysis), VirusTotal (multi-engine URL scan), ANY.RUN (interactive sandbox detonation)

IoC 3 — Domain: vitalcarehealthsolutions.com

• Type: Sender domain (impersonated)
• Risk: High — domain failed all authentication checks; may be newly registered or spoofed
• Lookup: WHOIS (registration age, registrant), MXToolbox (SPF/DMARC record validation, blacklist check)

Step 7 — Social Engineering Dissection

Technical indicators aside, the email body itself is a textbook example of social engineering. Every line is constructed to bypass rational decision-making and trigger an emotional, impulsive response.

Let us map the tactics:

Tactic Implementation in the Email

Urgency & Deadline “Failure to do so within 24 hours will result in temporary suspension”

Fear of Loss Threat of account suspension creates anxiety and motivates action

Authority Impersonation Poses as an official Security Team in a healthcare context — a sector associated with high sensitivity

False Reassurance “The VitalCare team will never ask for sensitive information through email” — stated while simultaneously requesting credential verification. A deliberately contradictory trust signal designed to pre-empt scepticism.

Vague Threat “Unusual activity detected” — non-specific, unverifiable, designed to raise alarm

Artificial Scarcity “The link will expire in 24 hours” — reinforces urgency and limits time for reflection or verification

The most insidious of these is the false reassurance tactic. By stating that they would never ask for sensitive information via email, the attackers appear to acknowledge a well-known phishing red flag — thereby disarming the recipient’s instinct to question the request. It is a sophisticated misdirection.

📸 [Screenshot: Email body HTML rendered, with annotations on the social engineering elements]

Tools Used and Recommended

For a complete investigation of this email, the following tools are recommended. Note that tool familiarity alone is not enough — applying them in the context of a structured analytical workflow is what produces actionable intelligence.

• VirusTotal — URL and IP multi-engine blacklist and behavioural analysis
• URLScan.io — Passive and active scanning of malicious-link.com; produces a full page screenshot, DOM tree, network requests, and redirects without requiring you to visit the site directly
• AbuseIPDB — Community-sourced IP reputation; reveals past abuse reports, confidence score, and attack categories associated with the IP
• MXToolbox — SPF and DMARC record validation for the sender domain; DNS blacklist checks
• ANY.RUN — Interactive sandbox for dynamic analysis of the URL; captures JavaScript execution, form submissions, and outbound network calls
• WHOIS Lookup — Domain registration age and registrant details; newly registered domains are a strong phishing indicator

Key Takeaways

This analysis reinforced several principles I now apply consistently in email threat investigation:

1. Never trust the From field. The From header is trivially spoofable. Authentication results — SPF, DKIM, DMARC — are the ground truth. A passing From address with failing authentication is always suspicious.

2. A private IP as a sending source is an immediate red flag. 192.168.1.1 cannot send email across the public internet. Its presence as the client-ip in the SPF check is definitive evidence of header forgery.

3. DMARC p=NONE is not protection — it is a gap. Monitoring mode is a valid starting point for new deployments, but leaving it there indefinitely creates an open door for domain spoofing. Any organisation serious about email security should progress to p=quarantine and ultimately p=reject.

4. Static and dynamic analysis are complementary, not interchangeable. Static analysis — header inspection, link extraction, MIME structure review — can conclusively identify a phishing email without ever visiting the malicious URL. Dynamic analysis via sandbox tools adds a further layer by revealing what the page actually does. Knowing when to use each approach, and in what order, is a core analyst skill.

5. Social engineering is as dangerous as the technical payload. A technically sophisticated attacker still needs the user to click. Understanding the psychological levers being pulled — urgency, authority, fear, false reassurance — is essential for both analyst awareness and user education.

Final Verdict

Indicator Finding

SPF ❌ FAIL DKIM ❌ FAIL DMARC ❌ FAIL (p=NONE — not enforced) Source IP ❌ Private RFC 1918 address — spoofed Payload URL ❌ HTTP, non-affiliated domain Social Engineering ❌ Multiple high-confidence tactics detected

Overall Verdict 🔴 HIGH CONFIDENCE PHISHING

Closing Thoughts

Phishing is not going away. If anything, as perimeter defences mature, attackers are doubling down on the human layer — and on building emails credible enough to slip past automated filters and land in the inbox. The analysis in this post is a reminder that the tools and techniques to detect these attacks exist and are accessible. The gap, more often than not, is in the systematic application of them.

If you are building a security portfolio or working your way into a blue team role, email header analysis is one of the most transferable and immediately demonstrable skills you can develop. Pick up a phishing sample from a resource like PhishTank or any.run’s public feed, open the raw headers, and work through the authentication chain. The patterns become recognisable quickly.

As always — stay curious, stay sceptical, and verify everything.

Debbie is a Cybersecurity Analyst with a focus on defensive securiy operations.