‍Companion to: A Practical Guide to Microsoft 365 Email Security & Google Workspace Hardening Against AI-Generated Phishing

Modern email security still hinges on three authentication protocols: SPF, DKIM, and DMARC. Your parent configuration guide is the click-by-click “what to set.” This document is the “why it works,” plus the failure modes and forensics you need when something breaks (deliverability issues, false positives, spoofing reports, vendor mail, forwarding, mailing lists).

Email spoofing persists because SMTP was designed without strong sender identity verification. Attackers exploit that gap in Business Email Compromise (BEC) and higher-quality phishing, including LLM-written messages that look clean enough to slip past content-only filters. The baseline defense is still identity verification and policy enforcement using native protocols.

How to use this doc

• If you want the exact settings: start with the parent guide.
  
• If you’re troubleshooting deliverability: start at Section 5 (Forensics), then jump back to the relevant protocol section.
  
• If you’re investigating spoofing / CEO fraud: start at Section 1 (Envelope vs Header) and Section 4 (DMARC alignment).
  
• If “forwarding” or “mailing lists” are involved: read Section 3.3 and the note on ARC in Section 5.3.
  

1) The core vulnerability: Envelope vs Header

To understand why authentication passes while users still get spoofed, you need to separate the two “sender” identities in every email.

Envelope sender (RFC 5321)

Also called MAIL FROM or Return-Path. This is used by mail servers during transmission (bounces, routing). End users typically do not see it.
SPF evaluates the envelope sender domain.

Header sender (RFC 5322)

This is the visible From: address in Outlook, Gmail, and most clients.
DMARC protects the header From domain.

The attack pattern

Attackers exploit the mismatch. Example:

• Envelope sender: attacker@evil.com (they control this domain and its SPF)
  
• Header From: ceo@yourcompany.com (what the user sees)
  

If you only validate SPF without enforcing alignment, the attacker can pass SPF for their own domain while impersonating yours in the visible header.

2) SPF (Sender Policy Framework)

RFC: 7208
SPF is an IP authorization check. It answers:

“Is this IP allowed to send mail for this domain (as defined by the envelope sender)?”

2.1 Record qualifiers (what the result means)

2.2 Common mechanisms

• ip4 / ip6: Explicit IP ranges. Efficient and predictable.
  
• include: Authorizes third-party senders (example: include:_spf.google.com).
  
• all: Catch-all at the end. Usually paired with -all or ~all.
  

2.3 SPF troubleshooting (the two common failure modes)

Failure mode A: The 10-lookup limit
SPF limits DNS lookups to 10. Too many include statements or nested includes can trigger a PermError, which many receivers treat as a fail.

Failure mode B: Forwarding breaks SPF
SPF validates the last hop IP. If mail is forwarded, the sending IP changes to the forwarder. If the forwarder is not authorized in the original sender’s SPF, SPF fails even for legitimate mail.

Practical takeaway: SPF is useful, but it is brittle in forwarded and list-served paths. You need DKIM and DMARC to get consistent outcomes.

3) DKIM (DomainKeys Identified Mail)

RFC: 6376
DKIM adds a cryptographic signature to the message. It proves:

• Integrity: the message has not been altered since signing
  
• Domain-level identity: independent of the sending IP
  

3.1 The DKIM-Signature header (what to look for)

When troubleshooting, find DKIM-Signature: and pay attention to:

• d= (domain): the signing domain (important for DMARC alignment)
  
• s= (selector): points to the public key in DNS
  
• h= (headers): which headers are covered by the signature
  
• bh= (body hash): the body content hash
  

3.2 What breaks DKIM in real life

DKIM can fail when intermediaries modify the message. Common causes:

• Mailing lists that rewrite headers or body
  
• Security tools that rewrite links
  
• Footers/disclaimers inserted after signing
  
• Some gateways that re-encode content
  

3.3 Advanced: oversigning (header injection defense)

Oversigning is a technique to prevent attackers from adding extra headers to an otherwise validly signed message.

How it works: you list a header more times in h= than it appears in the message, for example:

• h=From:From:To:Subject
  

That asserts “there is only one From header,” so attempts to inject another can break signature verification.

Use this when you need stronger guarantees against header manipulation and you understand the compatibility tradeoffs.

4) DMARC (Domain-based Message Authentication, Reporting, and Conformance)

RFC: 7489
DMARC is the policy and enforcement layer. It resolves the envelope/header mismatch by requiring identifier alignment.

DMARC passes only if:

1. SPF or DKIM passes, and
   
2. the authenticated domain aligns with the visible Header From domain.
   

4.1 Alignment (the concept that stops spoofing)

Practical takeaway: alignment is what makes DMARC effective against “looks internal” spoofing and CEO fraud.

4.2 The p=none trap

p=none is monitoring only. It does not block spoofing. Receivers can log failures and still deliver messages.

If you want protection, you need an enforcement posture (typically staged):

• p=none (instrumentation)
  
• p=quarantine (controlled enforcement)
  
• p=reject (spoofing is blocked by policy)
  

Note: rollout needs vendor inventory and testing. This is why the DMARC rollout deserves its own playbook.

5) Forensics: reading headers in the field

When someone reports a spoof or a message is blocked unexpectedly, start with the receiver’s Authentication-Results header (naming varies by platform). It summarizes SPF/DKIM/DMARC outcomes.

5.1 Scenario A: Spoof attempt where DMARC does its job

Authentication-Results: mx.google.com;

  spf=pass (domain of attacker@evil.com designates 1.2.3.4 as permitted sender)

  dkim=pass header.i=@evil.com;

  dmarc=fail (p=reject) header.from=bank.com

What happened

• SPF passed for evil.com (attacker controls the sending infrastructure)
  
• DKIM passed for evil.com (attacker signed with their key)
  
• DMARC failed because the visible From: bank.com did not align with evil.com
  

Verdict
DMARC blocks or quarantines based on policy, preventing a clean spoof from reaching users.

5.2 Scenario B: Legitimate mail breaks due to forwarding

Authentication-Results: protection.outlook.com;

  spf=fail (sender IP is 5.6.7.8)

  dkim=fail (body hash did not verify)

  dmarc=fail

‍What happened

• SPF failed because the message was forwarded (last hop IP changed)
  
• DKIM failed because the forwarder modified the body or headers
  
• DMARC failed because neither SPF nor DKIM produced aligned success
  

Verdict
This is a common cause of false positives and “why did this vendor suddenly fail?” tickets.

5.3 Where ARC fits (forwarding and mailing lists)

ARC (Authenticated Received Chain) can preserve authentication context across forwarding and list flows. If your environment relies heavily on forwarding or listservs, ARC is often the cleanest path to reduce breakage while keeping enforcement strict.

ARC is not a replacement for SPF/DKIM/DMARC. It is a way to carry forward verifiable authentication results through intermediaries.

6) Testing tools (safe, controlled validation)

Security teams often use swaks (Swiss Army Knife for SMTP) to simulate scenarios. Only test in environments where you have permission and you understand the impact.

6.1 Test SPF authorization (basic IP check)

swaks --to user@target.com --from valid@example.com --server 1.2.3.4

Interpretation: checks whether 1.2.3.4 is authorized to send for example.com based on SPF.

6.2 Simulate envelope vs header mismatch (alignment enforcement)

swaks --to admin@target.com \

  --from "CEO <ceo@target.com>" \

  --h-From: "CEO <ceo@target.com>" \

  --envelope-from attacker@evil.com \

  --server mail.target.com

Interpretation: tests whether the receiving environment enforces DMARC alignment when the envelope and header sender domains differ.

7) FAQ (technical deep dive)

Q: Can DMARC replace a Secure Email Gateway (SEG)?
A: DMARC can eliminate a large portion of spoofing and impersonation risk when it is enforced correctly and your sender ecosystem is clean. It does not replace link and attachment analysis, detonation, advanced phishing detection, or post-delivery remediation. Many orgs get meaningful risk reduction by maximizing native controls first, then evaluating what gaps remain.

Q: Why does SPF fail even though my IP is listed?
A: The most common cause is forwarding. SPF validates the last hop IP, not the original sender’s infrastructure. If mail is forwarded or passed through a list, SPF often fails even when the original sender is legitimate. DKIM is usually more resilient, and DMARC can pass if aligned DKIM passes.

Q: How does DMARC stop CEO fraud (BEC)?
A: CEO fraud relies on making the visible From address look internal. DMARC requires that the authenticated domain aligns with the Header From domain. If an attacker spoofs your domain, the message fails alignment and can be blocked by policy.

Q: What is the SPF 10-lookup limit?
A: SPF restricts DNS lookups to 10 to prevent abuse. Complex vendor ecosystems can exceed this through nested include records, causing PermError outcomes that weaken authentication.

Q: Is “AI phishing” different from standard phishing?
A: The delivery mechanics are the same, but the content quality is higher and less dependent on known signatures. That shifts defenders toward stronger identity verification (SPF/DKIM/DMARC), policy enforcement, and behavioral indicators instead of relying only on text-based detection.