DE3.3 Sender Reputation and Email Anomaly Detection

Why sender reputation alone fails

Email security products evaluate sender reputation on a domain-level model. Is the sending domain in a blocklist? Does it pass SPF, DKIM, and DMARC? Has Microsoft seen high complaint rates from this domain? These are good signals for catching commodity spam and known-bad infrastructure. They fail completely against the most dangerous phishing vector: compromised legitimate accounts.

When an attacker compromises a vendor's email account, through credential theft, OAuth consent abuse, or password spray: every email they send from that account inherits the domain's established reputation. SPF passes because the email originates from the domain's authorized servers. DKIM passes because the domain's mail server signs every outbound message. DMARC passes because both SPF and DKIM align. The sender reputation is genuinely good because the domain is genuinely legitimate. The attacker is using it.

This is not a failure of the reputation system. It is an architectural limitation. Reputation evaluates the sending infrastructure. Spearphishing from compromised accounts exploits trusted infrastructure. You need a different detection layer, one that evaluates the relationship between sender and recipient rather than the sender's domain reputation.

Figure DE3.3a. DE3-002 adds a relationship layer on top of the reputation layer. A single anomaly signal (novel sender) is too noisy for production. Combining three signals, novel sender, targeted recipient selection, and urgency-themed subject, reduces false positives to a manageable volume.

Building the sender-recipient baseline

DE3-002's core signal is relationship novelty, has this specific sender ever emailed anyone in your organization before? To answer that question, the rule needs a baseline of known sender-recipient relationships. You build that baseline from historical EmailEvents data.

The baseline period matters. Thirty days misses quarterly contacts, vendors who email once per quarter, auditors who reach out during reporting cycles. Ninety days captures most legitimate business relationships while keeping the baseline query performant. Run this query to understand the sender diversity in your environment:

// Build 90-day sender-to-org relationship baseline
// Identifies which external senders have established relationships
let BaselinePeriod = 90d;
let OrgDomain = "northgate-eng.com";
EmailEvents
| where TimeGenerated > ago(BaselinePeriod)
| where EmailDirection == "Inbound"
| where SenderFromDomain != OrgDomain
| where DeliveryAction == "Delivered"
| summarize
    FirstSeen = min(TimeGenerated),
    LastSeen = max(TimeGenerated),
    EmailCount = count(),
    UniqueRecipients = dcount(RecipientEmailAddress)
    by SenderFromAddress, SenderFromDomain
| summarize
    TotalSenders = count(),
    NewInLast7d = countif(FirstSeen > ago(7d)),
    SingleEmailSenders = countif(EmailCount == 1),
    AvgRecipientsPerSender = round(avg(UniqueRecipients), 1)

TotalSenders    NewInLast7d    SingleEmailSenders    AvgRecipientsPerSender
────────────    ───────────    ──────────────────    ──────────────────────
4,287           312            1,847                 2.3

In most M365 environments, 10–15% of weekly inbound senders are first-time contacts, and roughly 40% of all external senders have only ever sent a single email to the organization. That volume of novel senders is why sender novelty alone can't be a detection rule, you'd drown the SOC in false positives. The rule needs additional signals to distinguish first-contact phishing from first-contact legitimate business.

The three-signal detection model

DE3-002 combines three independent signals, each with high individual false positive rates, into a single detection with acceptable precision. The three signals are sender novelty, recipient targeting, and urgency indicators.

Sender novelty is the primary signal. A sender address that has never appeared in your inbound email over 90 days is either a new legitimate contact or a threat actor making first contact. Alone, this signal fires on ~15% of daily email volume, far too noisy. It becomes the foundation that the other two signals refine.

Recipient targeting is the precision filter. Spearphishing targets specific individuals chosen for their access level, finance teams for BEC, executives for CEO fraud, IT admins for credential harvesting. Legitimate first-contact senders typically email a generic mailbox (info@, sales@, support@) or a single point of contact. When a novel sender targets 2–5 named individuals who share a business function, and those individuals are not in a shared distribution list: the targeting pattern is a strong signal. The CHAIN-HARVEST phishing targeted three people who handle wire transfers. A legitimate vendor reaching out for the first time does not know who handles wire transfers unless they've done reconnaissance.

Urgency indicators are the confidence booster. Subject lines containing keywords like "urgent," "action required," "password expires," "wire transfer," "invoice overdue," or "verify your account" aren't inherently malicious, legitimate business email uses urgency too. But urgency combined with sender novelty combined with targeted recipients produces a signal that is overwhelmingly phishing. Each signal alone is noisy. The intersection is precise.

Building the production rule

The production query uses a materialized baseline of known senders, then identifies inbound emails from novel senders that match the targeting and urgency criteria. The materialize function prevents the baseline query from executing twice during the join.

// DE3-002: Novel sender with targeted recipients and urgency signals
// Hypothesis: first-contact senders who target specific users
// with urgency-themed subjects are likely spearphishing
let BaselinePeriod = 90d;
let DetectionWindow = 1h;
let OrgDomain = "northgate-eng.com";
let UrgencyTerms = dynamic([
    "urgent", "action required", "immediate",
    "verify", "confirm", "expire",
    "suspend", "invoice", "wire transfer",
    "payment", "overdue", "reset password"]);
// Step 1: Build known sender baseline (90 days)
let KnownSenders = materialize(
    EmailEvents
    | where TimeGenerated between (ago(BaselinePeriod) .. ago(DetectionWindow))
    | where EmailDirection == "Inbound"
    | where SenderFromDomain != OrgDomain
    | distinct SenderFromAddress
);
// Step 2: Find novel senders in the detection window
let NovelSenders =
    EmailEvents
    | where TimeGenerated > ago(DetectionWindow)
    | where EmailDirection == "Inbound"
    | where DeliveryAction == "Delivered"
    | where SenderFromDomain != OrgDomain
    | join kind=leftanti KnownSenders
        on SenderFromAddress;
// Step 3: Apply targeting and urgency filters
NovelSenders
| summarize
    RecipientCount = dcount(RecipientEmailAddress),
    Recipients = make_set(RecipientEmailAddress, 10),
    Subjects = make_set(Subject, 5),
    DeliveryCount = count()
    by SenderFromAddress, SenderFromDomain
| where RecipientCount between (2 .. 5)
| mv-expand SubjectStr = Subjects
| where tostring(SubjectStr) has_any (UrgencyTerms)
| project
    SenderFromAddress, SenderFromDomain,
    RecipientCount, Recipients,
    Subject = tostring(SubjectStr),
    DeliveryCount

Walk through the design decisions. Step 1 builds the baseline using a leftanti join, this is a KQL operator that returns rows from the left table that have no match in the right table. It's the most efficient way to find novel senders because it eliminates the known senders in a single pass rather than filtering with !in() against a large list. The baseline window excludes the detection window itself, preventing a sender who sent their first email 30 minutes ago from being baselined out of the current detection.

Step 2 filters to delivered inbound email from external domains during the detection window. The DeliveryAction == "Delivered" filter matters, emails that Exchange Online Protection quarantined or blocked don't need a custom detection rule because they've already been caught.

Step 3 applies the targeting and urgency filters. The RecipientCount between (2 .. 5) range targets spearphishing's sweet spot, enough recipients to indicate intentional selection, few enough to exclude mass marketing. A novel sender emailing 50 people is more likely a newsletter signup than a targeted campaign. The mv-expand on Subjects lets the rule evaluate urgency keywords against each unique subject line in the sender's email batch: a sender who sends the same urgency-themed message to three targeted individuals produces a higher-confidence signal than one who sends different subjects.

Enriching with authentication details

The EmailEvents table includes an AuthenticationDetails column that records the SPF, DKIM, and DMARC evaluation results for each message. This enrichment helps the analyst triage: a novel sender whose emails pass all three authentication checks is more likely a compromised legitimate account (higher risk) than a sender whose emails fail DMARC (which Exchange Online Protection should already be handling).

// Enrich DE3-002 results with email authentication status
// Compromised accounts pass all checks — that's the danger
EmailEvents
| where SenderFromAddress in ("flagged-sender@example.com")
| where EmailDirection == "Inbound"
| extend AuthParsed = parse_json(AuthenticationDetails)
| extend
    SPF = tostring(AuthParsed.SPF),
    DKIM = tostring(AuthParsed.DKIM),
    DMARC = tostring(AuthParsed.CompAuth)
| project
    TimeGenerated, SenderFromAddress,
    RecipientEmailAddress, Subject,
    SPF, DKIM, DMARC, SenderIPv4

When the analyst sees a DE3-002 alert where SPF, DKIM, and DMARC all pass, the triage priority increases. A compromised sender account that passes all authentication checks is a higher-risk scenario than an unrelated domain with authentication failures, because the compromised account evades every reputation-based defense your organization has.

Tuning for your environment

DE3-002 requires environment-specific tuning on two dimensions: the urgency keyword list and the recipient count threshold.

The default urgency terms list covers common BEC and credential phishing themes. Your environment will have additional terms specific to your industry — "purchase order" for manufacturing, "patient records" for healthcare, "settlement" for legal. Run this hunting query weekly to identify the most common subject line terms in your flagged-but-legitimate novel sender email, then exclude legitimate industry terms that generate false positives:

# Export recent novel sender subjects for keyword analysis
# Run in Azure Cloud Shell or local PowerShell with Az.OperationalInsights
$WorkspaceId = "your-workspace-id"
$Query = @"
EmailEvents
| where TimeGenerated > ago(7d)
| where EmailDirection == "Inbound"
| where DeliveryAction == "Delivered"
| summarize FirstSeen = min(TimeGenerated) by SenderFromAddress
| where FirstSeen > ago(7d)
| join kind=inner (
    EmailEvents
    | where TimeGenerated > ago(7d)
    | where EmailDirection == "Inbound"
) on SenderFromAddress
| summarize count() by Subject
| top 50 by count_
"@
Invoke-AzOperationalInsightsQuery `
    -WorkspaceId $WorkspaceId `
    -Query $Query |
    Select-Object -ExpandProperty Results |
    Export-Csv -Path "novel_sender_subjects.csv" -NoTypeInformation

Review the exported CSV for patterns. Legitimate first-contact subjects cluster around industry-specific terms — "RFQ" for procurement, "meeting request" for calendaring, "introduction" for networking. If those terms appear in your urgency list, they'll generate false positives. Remove them from the UrgencyTerms dynamic array and re-test.

The recipient count threshold of 2–5 works for organizations under 2,000 users. Larger organizations with broader distribution lists may need to raise the upper bound to 8 or 10. The key is that the threshold eliminates mass sends (newsletters, marketing, automated notifications) while capturing targeted campaigns. Test by running DE3-002 against 7 days of historical data and examining the RecipientCount distribution of the results.

The rule specification

Rule ID: DE3-002-Novel-Sender-Targeted-Urgency

Hypothesis: First-time external senders who target 2–5 named recipients with urgency-themed subject lines are likely conducting spearphishing from compromised or purpose-built accounts. The combination of sender novelty, targeted recipient selection, and urgency content produces a high-confidence pre-click detection signal.

ATT&CK: T1566.002. Phishing: Spearphishing Link. Also catches T1566.001 variants where the attachment is secondary to the social engineering.

Data source: EmailEvents (primary). No enrichment join required: all three signals exist in the same table.

Frequency: Every 1 hour with 2-hour lookback. The overlap ensures emails delivered near the boundary aren't missed.

Severity: Medium. Promote to High if the sender domain is less than 30 days old (add a WHOIS lookup enrichment in your SOAR playbook to automate this check).

Entity mapping: SenderFromAddress → Mailbox, Recipients → Account (first recipient), SenderFromDomain → DNS. The analyst sees sender, target, and domain in the investigation graph.

False positive sources: Three primary FP patterns. Recruitment outreach, recruiters email 2–3 hiring managers with urgent job-related subjects. Add your HR team's domain exceptions. Vendor onboarding, new vendors send their first emails during procurement, often with "invoice" or "payment" in the subject. Correlate with your procurement system if available. Sales outreach. SDRs cold-emailing multiple contacts with urgency themes. These are annoying but not malicious, add a suppression list for known sales engagement platforms (Outreach, SalesLoft, HubSpot sender domains).

Response procedure: Quarantine the email before the recipient opens it using Invoke-MgSecurityThreatSubmission or the Defender portal's manual quarantine. If already opened, check UrlClickEvents for any click activity and correlate with DE3-001. If the sender domain is a known partner, notify the partner that their account may be compromised, this is both good security practice and good business relationship management.