Email &
message security SMTP was designed in 1982 with no authentication whatsoever. Every control since — SPF, DKIM, DMARC, ARC, BIMI — is a patch bolted onto that. Understand the original protocol and the patches stop being a checklist and start being a system you can reason about.

SMTP has two layers, and they carry different sender addresses. Every authentication mechanism below depends on knowing which one it checks.

The envelope is the addressed sack the postal service reads; the message headers are the letterhead inside, which the sender writes freely. Nothing in SMTP prevents me typing any From address I like. That is not a bug being fixed — it is the protocol.

A raw SMTP conversation

220 mx.google.com ESMTP ready
EHLO mailer.acme.com
250-mx.google.com at your service
250-STARTTLS
STARTTLS                       upgrade to TLS — opportunistic!
MAIL FROM:<bounces@mailer.acme.com>    envelope sender → SPF
250 2.1.0 OK
RCPT TO:<jdoe@example.com>
250 2.1.5 OK
DATA
From: "Acme Billing" <billing@acme.com>      header From → DMARC
Subject: Invoice 4471
.
250 2.0.0 OK  queued as 4A2F...

# dig acme.com TXT
v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 ~all

SPF checks the envelope sender (Return-Path), not the From header the user sees. This is the crucial limitation: an attacker can pass SPF perfectly for their own domain while displaying billing@acme.com in From. SPF alone stops nothing that a user would notice.

Two operational traps

• The 10-lookup limit. SPF evaluation permits a maximum of 10 DNS lookups; exceed it and the result is permerror, which many receivers treat as a failure. Every new SaaS that sends on your behalf adds an include:. Audit this regularly and use flattening services carefully.
• SPF breaks on forwarding. A forwarded message arrives from the forwarder's IP, which is not in your SPF. This is exactly what ARC exists to repair.

The sending server signs selected headers and the body with a private key; the public key lives in DNS at <selector>._domainkey.<domain>. The receiver fetches it and verifies.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=acme.com;            the signing domain — DMARC aligns on this
  s=selector1;           which key to fetch
  h=from:to:subject:date;  headers covered by the signature
  bh=...; b=...          body hash; signature

Because the signature travels with the message, DKIM survives forwarding as long as nothing modifies the signed headers or body (mailing lists that append footers break it).

# dig _dmarc.acme.com TXT
v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; pct=100;
rua=mailto:dmarc@acme.com; ruf=mailto:forensic@acme.com

DMARC does two things SPF and DKIM cannot:

1. Alignment — it requires the domain in the visible From header to match the domain that passed SPF (the Return-Path) or the DKIM d=. Passing SPF for attacker.net no longer helps if From says acme.com.
2. Policy and reporting — tells receivers what to do on failure, and sends you aggregate reports about every source sending as your domain.

Rollout that does not break your own mail

• ARC (Authenticated Received Chain) — each intermediary that modifies a message stamps the original authentication results and signs them, so a final receiver can see "this failed SPF, but Google verified it passed before forwarding". Google Workspace both applies and honours ARC, which is why mailing-list mail from your domain usually still lands.
• BIMI — displays your brand logo in supporting clients, gated on DMARC at enforcement (and usually a VMC certificate). Useful mainly as an internal lever to justify finishing the DMARC project.
• MTA-STS / DANE / TLS-RPT — enforce transport encryption between servers, as above.

In Gmail: ⋮ → Show original gives the full source plus Google's own SPF/DKIM/DMARC verdicts. Read Received: headers bottom to top — the bottom one is the earliest hop, and everything below the first server you trust can be forged.

Return-Path: <bounce@mailer-xyz.top>        envelope sender — mismatch is a flag
Received: from mailer-xyz.top (198.51.100.9)
   by mx.google.com ... Tue, 12 Aug 2025 09:14:02
Authentication-Results: mx.google.com;
   spf=pass (google.com: domain of bounce@mailer-xyz.top designates
        198.51.100.9 as permitted sender);
   dkim=pass header.d=mailer-xyz.top;
   dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=acme.com
From: "Acme Billing" <billing@acme.com>
Reply-To: ap@acme-invoices.net              the payload
Message-ID: <...@mailer-xyz.top>
X-Originating-IP: ...

Read that block properly and the story is complete: SPF and DKIM both pass — for the attacker's own domain — while DMARC fails because the visible From claims acme.com. The Reply-To sends any response to a domain the attacker controls. "SPF passed" in isolation means almost nothing.

Triage checklist for a reported phish

1. Compare Return-Path, From and Reply-To. Any divergence is a story.
2. Read Authentication-Results — specifically the DMARC verdict and header.from.
3. Check the sending domain's age (WHOIS creation date) — days-old domains are a strong signal.
4. Expand links without clicking; look for redirectors, punycode and lookalike hosts.
5. Search the tenant for other recipients of the same campaign; remediate in bulk.
6. If anyone interacted: treat it as identity compromise — revoke sessions, check rules, forwarding, delegation, app passwords and OAuth grants.

• Email log search (Reporting → Email Log Search) — trace delivery of a specific message by recipient, subject or Message-ID; shows the actual disposition.
• Security investigation tool — bulk search across Gmail, Drive, devices and logins; the place you remediate a campaign (delete from all mailboxes, mark as phishing).
• Gmail safety settings — attachment protections, link and external image protection, spoofing and authentication warnings, and the banner for external senders.
• Routing and compliance rules — content compliance, objectionable content, and the routing rules that matter most for security architecture: whether a third-party gateway sits before or after Google.
• Allowlists — the inbound gateway and IP allow-lists are the most dangerous settings in the console. An over-broad entry silently disables spam and authentication checks for whoever is on it.
• Alert centre — Google's own suspicious-login, phishing and malware alerts; make sure they route somewhere staffed.

Note what none of these steps involve: an attachment, a malicious URL, or a signature to match. Content filtering has nothing to grab hold of. What does catch it is behaviour — this sender has never emailed this recipient, the reply-to differs from the from, the domain was registered eleven days ago, the tone and timing are anomalous, and finance is being asked to change payment details.

The modern pattern — and the one Abnormal implements — is to let Google's native filtering handle the volume of commodity spam and malware, then layer an API-integrated behavioural product that reads the whole tenant to catch what content inspection structurally cannot: BEC, account takeover, vendor fraud and internal lateral phishing.

Layering question to answer explicitly: which system is authoritative for quarantine, and where do users report suspicious mail? Two quarantines with two release processes is a reliable source of both user frustration and missed detections.

• Message delivered/quarantined events with sender, recipient, subject hash, verdict and URLs.
• Mail rule creation, forwarding and delegation changes — the single highest-value Workspace audit event for account takeover.
• OAuth grant events for high-risk scopes.
• Suspicious login events from Workspace correlated with proxy and EDR data.

The correlations that earn their keep: phish delivered → user clicked (proxy log) → login from new ASN (IdP) → inbox rule created (Workspace). Any one alone is ambiguous; together they are an incident, and building that chain is exactly what a SIEM is for.