AD2.13 Check My Knowledge

EOP anti-phishing — No. EOP evaluated the URL at delivery time (09:00) when it was clean. EOP does not re-evaluate URLs after delivery.

Safe Attachments — No. Safe Attachments scans file attachments, not URLs. URL protection is handled by Safe Links.

Safe Links — Correct. Safe Links scans the URL at click time (14:00), not delivery time. By 14:00, the phishing page is active. Safe Links detects the credential harvesting page and shows the user a warning. The user never reaches the phishing site.

DMARC — No. DMARC validates sender domain authentication. It does not scan URLs within email content.

The email is held entirely until scanning completes — the user sees nothing for 1-5 minutes — No. That's "Block" mode, not Dynamic Delivery. Dynamic Delivery separates the email body from the attachment.

The email body is delivered immediately with a placeholder where the attachment will appear. After 1-5 minutes, the attachment is either delivered (clean) or blocked (malicious) — Correct. Dynamic Delivery gives users the email body instantly. The attachment is held in the sandbox. If clean, it appears automatically. If malicious, it's replaced with a notification. Users experience minimal delay.

The email is delivered with the attachment, but the attachment is scanned when the user tries to open it — No. Safe Attachments scans BEFORE delivery, not when the user opens the file. The scanning happens server-side in Microsoft's sandbox, not on the user's device.

The attachment is removed and the user receives the email body only with a note to request the attachment from the sender — No. That's "Replace" mode. Dynamic Delivery delivers the attachment after scanning confirms it's clean.

SPF — No. SPF validates the sending server. Gmail's servers are legitimate, so SPF passes for Gmail.

DMARC — No. DMARC validates that the FROM domain aligns with SPF/DKIM. The email is FROM gmail.com, SPF and DKIM verify for gmail.com, so DMARC passes. DMARC only catches spoofing of YOUR domain, not impersonation from legitimate domains.

Safe Links — No. BEC emails typically don't contain malicious links — they request an action (wire transfer) through plain text.

Anti-phishing impersonation protection — Correct. The display name "James Morrison" matches a protected user (your CEO). The sender domain (gmail.com) doesn't match your company domain. Impersonation protection flags the mismatch and quarantines the email. The first contact safety tip also triggers because the finance team has never received email from this Gmail address. This is exactly the BEC scenario that impersonation protection is designed to catch.

p=none — monitor and collect reports without affecting email delivery — Correct. Start with p=none to collect aggregate reports showing which emails pass and fail authentication. This reveals any legitimate sending services you forgot to include in SPF or DKIM. After 2-4 weeks of clean reports, progress to p=quarantine, then p=reject. Deploying p=reject on day one risks blocking legitimate email from services you haven't authorized.

p=reject — maximum protection from day one — Too aggressive for initial deployment. If any legitimate email source fails authentication (a forgotten marketing platform, a CRM, a scanning device), p=reject blocks those emails entirely. Start with p=none and progress through quarantine to reject after verifying all legitimate sources pass.

p=quarantine — balance between protection and safety — Still too aggressive for initial deployment. p=quarantine sends failing emails to junk, which is less disruptive than p=reject but still affects legitimate email that hasn't been authorized. Start with p=none.

Don't deploy DMARC until you're sure every email source is authenticated — Counterproductive. The purpose of p=none is specifically to DISCOVER which sources need authentication. You deploy DMARC at p=none to find the gaps, fix them, and then progress to enforcement. Waiting for certainty before deploying the discovery mechanism is circular.

Mailchimp is sending spam and the filter is correctly catching it — No. The newsletters are legitimate business communications. The issue is authentication, not content.

Mailchimp sends as your domain but their servers aren't in your SPF record — SPF fails, causing recipients' mail servers to treat the newsletters as spoofed email — Correct. Your SPF record only authorizes M365 servers. Mailchimp sends from their own servers. When the recipient's mail server checks SPF, it sees that Mailchimp's IP isn't authorized → SPF fails → the email is treated as potentially spoofed → delivered to spam. Fix: add `include:servers.mcsv.net` to your SPF record.

DMARC is blocking the emails — Only if your DMARC policy is p=quarantine or p=reject. At p=none, DMARC doesn't affect delivery. But SPF failure alone can cause spam classification at many receiving servers, even without DMARC enforcement.

The newsletters need DKIM signing through Mailchimp — DKIM would help but SPF is the primary issue here. Adding Mailchimp to your SPF record is the immediate fix. Setting up DKIM through Mailchimp is a good additional step.

Remove the phishing email from all 40 inboxes — Important but not the first action. The email is a latent threat (users might still click), but the compromised account is an active threat (attacker is in the mailbox right now).

Block the phishing URL in the Tenant Allow/Block List — Useful but Safe Links is already blocking for most users. The 1 user who got through was before Safe Links classified the URL. Blocking it now helps but doesn't address the active compromise.

Contain the compromised account immediately — revoke sessions, reset password — then remove the email from remaining inboxes — Correct. The compromised account is the immediate priority. The attacker is active right now — every second of investigation before containment extends the attacker's access. Revoke sessions (10 seconds), reset password (30 seconds), then purge the email from the other 39 inboxes (5 minutes). Active compromise first, latent threat second.

Send an organization-wide alert warning users not to click the link — Helpful as a secondary action but doesn't contain the active compromise. An alert reduces the chance of additional clicks, but the user whose account is already compromised needs immediate containment.

Your email protection is misconfigured — Possible but not the most likely explanation. If all other emails are being filtered correctly, a single bypass doesn't indicate misconfiguration.

Safe Links is broken — Safe Links protects URLs, not email delivery. The email reaching the inbox doesn't mean Safe Links failed — it means the email itself wasn't caught by content or sender filtering. Safe Links still protects if the user clicks a link in the email.

DMARC only works if the recipient's email system checks it — True but most major email systems honor DMARC. This would explain bypass only if the phishing email spoofed your domain and the recipient's system ignored DMARC — unlikely for email delivered TO your M365 tenant.

No email filtering system catches 100% of phishing — the attacker used a technique that bypassed all layers (e.g., compromised a trusted account, used a legitimate service for hosting, or crafted content that didn't match any detection signature) — Correct. Email protection reduces phishing volume dramatically but never reaches 100%. Attackers continuously evolve techniques to bypass filters — using compromised accounts (passes SPF/DKIM/DMARC because the sender IS legitimate), hosting phishing on trusted platforms (SharePoint, Google Forms), or using image-based content that text analysis can't parse. This is why user reporting (AD2.9) and the investigation procedure (AD2.10) exist — they catch what automated filters miss.

The number of Safe Links and Safe Attachments policies you created — Not useful for management. The number of policies is an implementation detail, not a business metric.

Phishing emails blocked (total and by type), user click rate on phishing links (before and after Safe Links), DMARC deployment status (current policy level and progression plan), and user-reported phishing volume — Correct. These are the metrics that matter: threats stopped, user behavior improvement, domain protection status, and user engagement with reporting. Each metric has a before/after comparison that demonstrates the impact of the controls you deployed. Add these alongside the identity metrics from Module AD1 for a complete picture.

A complete list of every phishing email that was blocked — Too detailed for management. Aggregate numbers (total blocked, total delivered, total clicked) tell the story. Individual email details belong in the incident log, not the quarterly report.

The technical configuration of each policy — Not relevant for management. Management cares about outcomes (threats stopped, risk reduced), not configurations (Safe Links real-time scanning enabled, bulk threshold at 6).