Proofpoint Email Security Specialist cheat sheet

SMTP delivery path: sender MTA → receiving MTA → policy/filtering layer → mailbox; each hop adds a Received header read bottom-up as the oldest hop.

Envelope sender (MAIL FROM) differs from header From; SPF evaluates the envelope domain, DMARC aligns the header From, so both must be inspected.

Store-and-forward means filtering can occur at connection time (SMTP rejection), after data (accept-then-drop), or post-delivery (retroactive removal from mailbox).

Inline (synchronous) filtering blocks the SMTP session until verdict; API/ICAP or journaling modes are asynchronous and cannot reject at the gateway.

TLS is opportunistic by default on port 25; MTA-STS and DANE enforce transport encryption but do not authenticate message content.

Common inbound threats: phishing, BEC/impersonation, malware attachments, credential-harvesting URLs, spam, and graymail (bulk but user-tolerated).

Attachment defense layers: signature AV, sandbox detonation, static file-type policy, and archive recursion depth limits.

URL defense layers: reputation lookup, redirect-chain following, time-of-click re-evaluation, and rewrite/wrapping for post-delivery blocking.

Classification pipeline order: connection/reputation → authentication results → content and intent analysis → attachment/URL detonation → final disposition (allow, quarantine, block, tag).

BEC detection keys on identity deception (display-name spoof, lookalike domain, reply-to mismatch) rather than malicious payloads, since BEC messages often carry no URL or attachment.

Lookalike-domain signals: homoglyphs, added/removed characters, alternate TLDs, and cousin domains registered shortly before the campaign.

Sandbox verdicts map to malicious, suspicious, and clean; suspicious detonation typically escalates to quarantine rather than silent delivery.

Impersonation of internal executives is detected by comparing header From against the organization's own domain inventory and known display names.

Confidence scoring combines multiple weak signals; a single low-confidence signal should not alone trigger a block unless policy explicitly says so.

False-positive control: allowlists and safe-sender lists bypass content inspection, so scope them narrowly and review them on a schedule.

Threat intelligence feeds supply domain/IP/URL reputation; stale or over-broad feeds raise false positives, so tune by category.

Policy evaluation is typically top-down with first-match-wins; rule order therefore determines the outcome when conditions overlap.

A rule needs a condition (sender, recipient, IP, header, authentication result, content) and an action (allow, block, quarantine, tag subject, add header, redirect).

Recipient-based policies (per-user, per-group, per-domain) override global defaults; verify the effective policy for a user, not just the global one.

Allow/safe-sender entries usually bypass spam and content scanning but not malware scanning; confirm the exact bypass scope before relying on it.

Quarantine actions differ by endpoint: admin quarantine, user-accessible quarantine, and silent drop; user quarantine requires notification and release settings.

Content rules on subject/body/header use pattern matching; overly broad regex on common words causes mass false positives, so anchor patterns.

DLP and encryption rules trigger on data patterns (SSN, card numbers) and route to TLS enforcement or portal pickup rather than plain delivery.

Change control: export or snapshot the policy set before edits, and stage new rules in monitor/tag-only mode before enforcing.

SPF authorizes sending IPs via DNS TXT record; the check is on the envelope MAIL FROM domain, and the lookup limit is 10 DNS-querying mechanisms per check.

SPF results: pass, fail, softfail (~all), neutral, none, permerror, temperror; only fail/softfail normally affect DMARC.

SPF include: and redirect= each consume lookups; flattening or SPF macros are used when the 10-lookup limit is exceeded.

DKIM signs selected headers plus the body hash with a private key; the selector in the DKIM-Signature (s=) resolves the public key at selector._domainkey.domain.

DKIM failure causes: body modified in transit, header list mismatch, key rotation without DNS update, or canonicalization mismatch.

DMARC requires From-domain alignment with a passing SPF (envelope) or DKIM (d=) identifier, either relaxed (organizational domain) or strict.

DMARC policy p=none (monitor), quarantine, reject; pct sets the applied percentage, and rua/ruf set aggregate and forensic report addresses.

DMARC pass requires alignment plus an authentication pass; SPF pass on an unaligned domain does not satisfy DMARC.

ARC preserves authentication results across forwarders by sealing them; it is a trust chain, not a replacement for DMARC alignment.

Search keys: sender, recipient, subject, message-ID, client IP, and time window; narrow the window first to reduce scan time.

Message-ID is the most precise identifier; it is assigned by the originating system and persists across hops.

Trace fields per hop: timestamp, hostname, IP, queue ID, and delay; large inter-hop delays indicate queuing or greylisting.

Disposition values to distinguish: delivered, quarantined, blocked/rejected, deferred, and dropped after delivery.

Filtered/processed messages show which rule or module fired; the module name maps to the policy section that produced the verdict.

Retroactive actions (pull from inbox, re-scan) require the message to still be retrievable in the archive or tracking store.

Tracking retention is finite; export logs before the retention window closes if evidence is needed for an investigation.

Quarantine types: admin-only, end-user self-service, and message hold; each has separate release permissions and notification behavior.

End-user release should be paired with a report-phish action so released messages still feed tuning and threat intelligence.

Incident phases: detect → scope (who received, when, which campaign) → contain (block sender/URL/domain) → eradicate (pull messages) → recover → lessons learned.

Scoping a campaign uses sender address, subject pattern, URL/domain, attachment hash, and time window together to avoid over- or under-collection.

Credential-phishing response includes forced password reset and session revocation for users who clicked and submitted.

Containment blocks should be scoped to the exact sender/IP/URL first; org-wide blocks on shared infrastructure risk blocking legitimate mail.

Post-incident tuning: convert confirmed indicators into blocklists or rules, and record the false-positive/negative rate for the campaign.

Role separation: super admin, org admin, and read-only/auditor roles; least privilege limits blast radius of a compromised admin account.

MFA on admin accounts is the primary control against console takeover; enforce it before granting write access.

User and group provisioning should be directory-synced so recipient-based policies inherit group membership automatically.

Configuration backup: export policy, allowlists, and rule sets on a schedule; restore drills verify the backup is usable.

Domain and subdomain onboarding requires DNS records for SPF, DKIM selectors, and DMARC before enforcement.

License and seat assignment controls which modules (sandbox, URL defense, DLP, archive) apply to a given user.

Audit logs record admin changes (rule edits, allowlist additions); review them for unauthorized or undocumented changes.

Core operational metrics: message volume, blocked vs delivered ratio, quarantine volume, false-positive rate, and detonation queue depth.

DMARC aggregate (rua) reports show per-source-IP pass/fail and alignment; use them to inventory legitimate senders before moving to reject.

False-positive rate is measured from user-reported releases divided by total quarantined or blocked messages over the same window.

Alerting thresholds should be based on baselines (e.g., deviation in block rate or queue depth), not fixed absolute counts.

Report cadence: daily operational dashboards, weekly trend review, monthly executive summary with incident count and top attack types.

Retention and data residency requirements constrain how long message metadata and reports can be stored.

Capacity signals: detonation queue backlog, delivery latency, and API rate-limit errors indicate scaling or throughput limits.

SMTP envelope vs header From distinction determines which authentication check applies.

Filtering modes: inline rejection, accept-then-quarantine, post-delivery removal.

TLS encrypts transport but does not authenticate content.

Threat categories: phishing, BEC, malware, credential harvesting, spam, graymail.

Attachment defense: AV signatures, sandbox detonation, file-type policy, archive depth.

URL defense: reputation, redirect following, time-of-click, rewriting.

Received headers are read bottom-up, oldest hop first.

Envelope sender is used by SPF; header From is used by DMARC.

Asynchronous modes (journaling, API) cannot reject at the SMTP session.

MTA-STS and DANE enforce transport encryption only.