Lab PH.2 — Email Authentication Check

Lab Overview

The Scenario

Your organization's security team is updating its email security posture. Before recommending changes, you've been asked to audit the email authentication records of three domains: your own company domain, a trusted vendor, and a domain that recently appeared in a phishing campaign. By comparing the three, you'll understand the spectrum from well-protected to dangerously exposed.

Part 1: SPF Record Deep-Dive

SPF (Sender Policy Framework) is a DNS TXT record that lists which IP addresses and mail servers are authorized to send email on behalf of a domain.

SPF Syntax Reference

Exercise: Query Three SPF Records

Navigate to MXToolbox SPF Lookup and query each domain:

Domain 1: google.com

Record: v=spf1 include:_spf.google.com ~all

Document:

• How many include: mechanisms are present?
• What is the qualifier on the all mechanism?
• Follow the include chain — how many total IPs are authorized?

Domain 2: microsoft.com

Record: v=spf1 include:_spf-a.microsoft.com include:_spf-b.microsoft.com include:_spf-c.microsoft.com include:_spf-ssg-a.msft.net ip4:147.243.128.24 ip4:147.243.128.26 ip4:147.243.1.153 ip4:147.243.1.47 -all

Document:

• How many include mechanisms vs direct IP mechanisms?
• What does -all (hard fail) mean compared to Google's ~all (soft fail)?
• Which domain has a stricter SPF policy?

Domain 3: example-phishing-domain.com (simulated)

For this exercise, imagine querying a domain that returns:

Record: v=spf1 +all

Document:

• What does +all mean?
• Why is this the most dangerous SPF record possible?
• Would any IP address on the internet pass SPF for this domain?

Part 2: DKIM Record Analysis

DKIM (DomainKeys Identified Mail) uses public-key cryptography. The sending server signs outgoing emails with a private key, and the public key is published in DNS for receivers to verify.

DKIM Record Structure

DKIM records are TXT records at [selector]._domainkey.[domain]. The selector is specified in the email's DKIM-Signature header.

Navigate to MXToolbox DKIM Lookup and query:

Domain: google.com, Selector: 20230601

Expected fields:
  v=DKIM1
  k=rsa
  p=[base64-encoded public key]

Document:

• What key type does Google use? (RSA, Ed25519, etc.)
• Is the key length 1024-bit or 2048-bit? (Longer keys are more secure)
• What happens if you query a wrong selector (e.g., "test123")?

What Happens Without DKIM

If a domain has no DKIM record:

• Emails from that domain cannot be cryptographically verified
• Any server can claim to be sending on behalf of the domain
• DMARC alignment on DKIM will always fail
• The receiving server can only rely on SPF and IP reputation

Click to enlarge

Part 3: DMARC Policy Analysis

DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together with a policy that tells receivers what to do with failing messages.

DMARC Tag Reference

Exercise: Query Three DMARC Records

Navigate to MXToolbox DMARC Lookup:

Domain 1: google.com

v=DMARC1; p=reject; sp=reject; rua=mailto:mailauth-reports@google.com

Domain 2: A domain with p=none

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Domain 3: A domain with no DMARC record

No DMARC record found

For each, answer:

• What happens to a spoofed email that fails authentication?
• Is the domain collecting reports?
• Would an attacker choose to spoof this domain? Why or why not?

Part 4: Authentication Scenario Evaluation

For each scenario below, determine the SPF, DKIM, and DMARC result. Write PASS, FAIL, or NONE for each.

Scenario 1: Legitimate Marketing Email

• Sent from: marketing@company.com via SendGrid (include:sendgrid.net is in SPF)
• DKIM signed with company.com selector
• DMARC policy: p=quarantine

Scenario 2: Spoofed Email from Attacker Server

• From header: ceo@company.com
• Sent from IP: 185.220.101.42 (not in SPF record)
• No DKIM signature
• DMARC policy: p=reject

Scenario 3: Forwarded Legitimate Email

• Originally from: partner@vendor.com (SPF includes their mail server)
• Forwarded by: employee@company.com mail server (different IP, breaks SPF)
• DKIM signature intact (signatures survive forwarding)
• DMARC policy: p=quarantine; adkim=r

Scenario 4: Subdomain Spoofing

• From header: support@billing.company.com
• company.com DMARC: p=reject; sp=none
• No SPF or DKIM for billing.company.com

Scenario 5: Cousin Domain Attack

• From header: finance@cornpany.com (note: "rn" looks like "m")
• Legitimate SPF for cornpany.com (v=spf1 +all)
• DKIM signed for cornpany.com
• DMARC: p=none

Click to enlarge

Part 5: Compile Your Findings

Create an authentication audit report:

EMAIL AUTHENTICATION AUDIT REPORT
═══════════════════════════════════
Analyst: [Your Name]
Date: [Today's Date]

DOMAIN AUDIT SUMMARY
─────────────────────
Domain            SPF Policy    DKIM    DMARC Policy    Risk Level
google.com        ~all          Yes     p=reject        LOW
microsoft.com     -all          Yes     p=reject        LOW
[phishing domain] +all          No      p=none          CRITICAL

SCENARIO EVALUATION SUMMARY
────────────────────────────
Scenario 1: [PASS/FAIL] — [one-line explanation]
Scenario 2: [PASS/FAIL] — [one-line explanation]
Scenario 3: [PASS/FAIL] — [one-line explanation]
Scenario 4: [PASS/FAIL] — [one-line explanation]
Scenario 5: [PASS/FAIL] — [one-line explanation]

KEY RECOMMENDATIONS
───────────────────
1. [Your recommendation for your organization]
2. [Your recommendation for vendor assessment]
3. [Your recommendation for phishing defense]

Deliverable Checklist

Before completing the lab, ensure you have:

• SPF Records Queried — All 3 domains analyzed with mechanism breakdown
• DKIM Record Verified — Google's DKIM key found and key type documented
• DMARC Records Compared — 3 domains with policy implications documented
• 5 Scenarios Evaluated — SPF/DKIM/DMARC results for each with reasoning
• Audit Report Complete — Risk levels assigned and recommendations written

What's Next

In Lab PH.3 — Classify the Phish, you'll apply your header analysis and authentication knowledge to classify five realistic email scenarios. You'll determine whether each is spam, phishing, spear phishing, BEC, or legitimate — building the classification skills that SOC analysts use daily in triage.