Fundamentals

Email Security Architecture for Analysts

How email security works from an analyst's perspective — SPF, DKIM, DMARC, email gateways, threat detection, and investigating malicious email traffic in the SOC.

View on Graph

The Email Architecture Every Analyst Must Know

Email security relies on multiple layers working together. Understanding this architecture helps analysts triage email threats faster and reduces false positive fatigue from misconfigured email controls.

Email Flow Through Security Controls

Sender → MTA → SPF Check → DKIM Verify → DMARC Policy
         → Email Gateway (anti-spam, anti-malware, URL filtering)
         → Sandbox (attachment detonation)
         → Recipient Inbox → Mimecast/Proofpoint/Defender link rewrite

Each layer generates distinct log sources that analysts use during investigation:

LayerWhat It DoesLog SourceWhat Analysts Check
SPFVerifies sender IP is authorized to send for the domainDMARC reports, MTA logsDid the email pass SPF? Was the sender IP in the SPF record?
DKIMVerifies email integrity and authenticity via digital signatureDKIM headers, MTA logsDid DKIM pass? Does the signing domain match the From header?
DMARCPolicy handler — tells receivers what to do with emails that fail SPF/DKIMDMARC aggregate/forensic reportsWhat is the DMARC policy (none/quarantine/reject)?
Email gatewayFilters spam, malware, and malicious URLsGateway audit logsWas the email flagged? What was the threat score?
SandboxDetonates attachments in isolated environmentSandbox analysis reportDid the attachment exhibit malicious behavior?
Link rewriteRewrites URLs for post-delivery click protectionClick logs, threat statusDid the user click? Was the URL malicious at time of click?

SPF — Sender Policy Framework

What SPF Does

SPF allows a domain owner to publish a DNS record listing the servers authorized to send email for that domain. When a receiving mail server gets an email, it checks the SPF record to see if the sender’s IP is in the authorized list.

SPF record example:

v=spf1 ip4:192.0.2.0/24 include:_spf.google.com ~all
MechanismMeaning
ip4:192.0.2.0/24Servers in this IP range are authorized
include:_spf.google.comInclude Google’s SPF record
~allSoft-fail — mark as suspicious but accept (recommended during migration)
-allHard-fail — reject emails not matching the SPF record (strict policy)

Why SPF Fails and What It Means

SPF ResultMeaningInvestigation Action
PassSender IP is authorizedNormal — no SPF issue
FailSender IP is NOT authorizedPossible spoofing. Check the sending infrastructure.
SoftFailSender IP is weakly unauthorizedUsually a configuration issue — email is accepted but marked
NeutralSPF record does not explicitly authorize or denyThe domain has no explicit SPF policy — common for small domains
NoneNo SPF record exists for the domainDomain lacks email authentication entirely
TempErrorDNS resolution failureTransient — retry may succeed
PermErrorSPF record is malformedDomain misconfiguration — should be corrected by the domain owner

SPF Limitations

SPF has a 10 DNS lookup limit — including lookups from include and redirect mechanisms. Domains that exceed this limit will have their SPF checks fail. This is a common configuration error in organizations that use multiple email providers.

DKIM — DomainKeys Identified Mail

What DKIM Does

DKIM adds a digital signature to email headers. The signature is created using the sending domain’s private key, and the receiving server verifies it using the public key published in the domain’s DNS.

DKIM signature header example:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1;
 bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
 h=From:To:Subject:Date; b=ABC123...XYZ789
DKIM ParameterMeaning
v=1DKIM version
a=rsa-sha256Signing algorithm
d=example.comSigning domain
s=selector1DNS selector — determines where the public key is published
bh=Body hash — ensures body integrity
h=Signed headers — ensures header integrity
b=The digital signature itself

Why DKIM Fails and What It Means

DKIM ResultMeaningInvestigation Action
PassSignature verifiedNormal — email integrity is intact
FailSignature does not matchEmail was modified in transit, or the signature was forged
PermErrorDKIM record is invalidDomain misconfiguration
TempErrorDNS lookup failedTransient — retry may succeed

DKIM and Forwarding

Email forwarding breaks DKIM. When an email is forwarded from one server to another, the forwarder may modify headers or the body, invalidating the original DKIM signature. This is why SPF and DMARC work together — DKIM failure from forwarding is expected, but SPF may still pass (with ARC or SRS).

DMARC — Domain-Based Message Authentication, Reporting, and Conformance

What DMARC Does

DMARC tells receiving servers what to do with emails that fail both SPF and DKIM. It also provides reporting so domain owners can see who is sending email on their behalf.

DMARC record example:

_dmarc.example.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:dmarc-forensic@example.com; pct=100; sp=reject"
TagMeaningValues
pPolicy for the domainnone (monitor only), quarantine (mark as spam), reject (block email)
spPolicy for subdomainsSame as p values
ruaAggregate report addressWhere daily XML reports are sent
rufForensic report addressWhere individual failure reports are sent
pctPercentage of emails to apply the policy to1-100
adkimDKIM alignmentr (relaxed — domain match), s (strict — exact match)
aspfSPF alignmentr (relaxed), s (strict)

DMARC Policy Progression

Organizations typically progress through these DMARC policies:

p=none → p=quarantine → p=reject
↑ Monitor      ↑ Mark spam      ↑ Block

Analysts should know that a DMARC p=reject policy does not mean all email from that domain is safe — it means the domain has good email authentication posture. Legitimate services that send email on the domain’s behalf must be properly configured in SPF, DKIM, or both.

Email Gateway Analysis — Investigating Malicious Email

Key Email Headers for Investigation

HeaderWhat It Tells YouHow to Access
ReceivedThe full relay path — each server that handled the emailFirst Received header at the bottom = origin
Return-PathWhere bounces go — different from FromAny email client
Authentication-ResultsSPF, DKIM, and DMARC results from the receiving serverEmail headers
X-MailerThe email client used to sendHeader analysis
Message-IDUnique identifier — useful for cross-referencing across systemsAny email client
DKIM-SignatureDKIM verification informationEmail headers
ARC-Seal/ARC-Message-SignatureAuthentication chain for forwarded emailEmail headers

Analyzing a Suspicious Email — Step-by-Step

  1. Check SPF/DKIM/DMARC results in the Authentication-Results header. If all three pass, the sender identity is authentic. If any fail, the email is spoofed or forwarded.
  2. Examine the Received headers from bottom to top. The bottommost Received header is the original sender’s server. Look for IP addresses and reverse DNS hostnames that don’t match the claimed sender.
  3. Check the Reply-To header. If Reply-To differs from From, this is a social engineering red flag — the attacker wants replies to go to a different address.
  4. Inspect URLs without clicking. Hover over links to see the actual destination URL. Use a URL scanner (VirusTotal, URLScan.io) to check the domain.
  5. Analyze attachments — check file extension, hash the attachment, and query threat intelligence feeds (VirusTotal, Hybrid Analysis). Do not open attachments on your workstation.

KQL query — find emails from suspicious domains:

EmailEvents
| where Timestamp > ago(7d)
| where AuthenticationResults !contains "dmarc=pass" or AuthenticationResults contains "spf=fail"
| project Timestamp, SenderFromAddress, RecipientEmailAddress, Subject, AuthenticationResults, ThreatTypes
| order by Timestamp desc

Common Email Security Issues Analysts See

IssueCauseHow to Diagnose
Legitimate email marked as spamSPF failure due to forwarding, DKIM breakage, or misconfigured DMARCCheck Authentication-Results — SPF/DKIM failures from forwarding are normal
Phishing email that passed authenticationLegitimate domain was compromised, or the attacker used a look-alike domainCheck the domain carefully — rnicrosoft.com vs microsoft.com
DMARC aggregate report shows unknown sendersShadow IT, marketing tools, or malicious senders using the domainInvestigate each unknown source IP against known vendors and tools
DKIM signature breakage from mailing listsMailing list modifies headers or contentARC seals can preserve the authentication chain
SPF permerror (too many DNS lookups)Organization uses multiple email providersUse SPF macros or reduce the number of include statements

Sources