DMARC Failure Trend

Hunt Hypothesis

Adversaries may be spoofing email addresses to bypass DMARC policies and exfiltrate data or spread phishing payloads. SOC teams should proactively hunt for this behavior in Azure Sentinel to identify potential spear-phishing campaigns and mitigate data exfiltration risks.

KQL Query

let TimeStart = startofday(ago(30d));
let TimeEnd = startofday(now());
EmailEvents
| extend DMARCFail = AuthenticationDetails has_any ('DMARC":"fail') 
| make-series Count= count() default = 0 on Timestamp from TimeStart to TimeEnd step 1d
| render timechart

Analytic Rule Definition

id: 26ca6908-d5f1-43fa-a12b-103ba59841b5
name: DMARC Failure Trend
description: |
  This query visualises total emails with Spoof - DMARC fails summarizing the data daily.
description-detailed: |
  This query visualises total emails with Spoof - DMARC fails summarizing the data daily.
  Query is also included as part of the Defender for Office 365 solution in Sentinel: https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/part-2-build-custom-email-security-reports-and-dashboards-with-workbooks-in-micr/4411303
requiredDataConnectors:
- connectorId: MicrosoftThreatProtection
  dataTypes:
  - EmailEvents
tactics:
  - InitialAccess
relevantTechniques:
  - T1566
query: |
  let TimeStart = startofday(ago(30d));
  let TimeEnd = startofday(now());
  EmailEvents
  | extend DMARCFail = AuthenticationDetails has_any ('DMARC":"fail') 
  | make-series Count= count() default = 0 on Timestamp from TimeStart to TimeEnd step 1d
  | render timechart
version: 1.0.0

Required Data Sources

MITRE ATT&CK Context

• Tactic: InitialAccess
• Technique: T1566 — T1566

References

• [Source Query](https://github.com/Azure/Azure-Sentinel/blob/main/Hunting Queries/Microsoft 365 Defender/Email and Collaboration Queries/Authentication/DMARC Failure Trend.yaml)

False Positive Guidance

• Scenario: Scheduled System Email Reports
  Description: Automated reports generated by tools like Microsoft Exchange Online or Google Workspace Admin Console may send emails with DMARC failures due to their “From” headers not aligning with the domain’s DMARC policy.
  Filter/Exclusion: Exclude emails sent by known system accounts or services (e.g., admin@domain.com, noreply@domain.com) or use a filter like from:system@domain.com or subject:*report*.

• Scenario: Internal Testing with Spoofed Headers
  Description: Security teams may test DMARC configurations by sending emails with spoofed headers using tools like SendGrid or Mailgun for internal validation.
  Filter/Exclusion: Exclude emails originating from internal testing IPs or using specific test domains (e.g., test-dmarc@domain.com) or apply a filter like ip:192.168.0.10 or header:Testing-DMARC.

• Scenario: Automated User Provisioning Jobs
  Description: Scheduled user provisioning jobs in tools like Azure AD Connect or AWS WorkMail may send emails with DMARC failures if the “From” address is not properly configured.
  Filter/Exclusion: Exclude emails sent by provisioning services (e.g., provisioning@domain.com) or apply a filter like subject:*provisioning* or from:provisioning@domain.com.

• Scenario: Email Archiving or Migration Tools
  Description: Email archiving tools like Microsoft Exchange Archiving or Symantec Enterprise Vault may send emails with spoofed headers during migration or backup processes.
  Filter/Exclusion: Exclude emails from known archiving tools (e.g., archive@domain.com) or use a filter like