Message from an Accepted Domain with DMARC TempError

Hunt Hypothesis

Adversaries may exploit DMARC TempError responses to send malicious emails that appear to originate from legitimate domains, bypassing email filtering controls. SOC teams should proactively hunt for this behavior in Azure Sentinel to identify and mitigate potential phishing or spoofing attacks that evade standard detection mechanisms.

KQL Query

let SenderDomains = pack_array ('contoso.com','fabrikam.fr');
EmailEvents
| where EmailDirection == 'Inbound' and SenderMailFromDomain in (SenderDomains)
| extend SPF= tostring(parse_json(AuthenticationDetails).SPF)
| extend DMARC= tostring(parse_json(AuthenticationDetails).DMARC)
| where DMARC == "temperror" or SPF == "temperror"

Analytic Rule Definition

id: a256f4ea-deec-4fcd-bdf3-63987638eed9
name: Message from an Accepted Domain with DMARC TempError
description: |
  This query can be used as a Custom Detection Rule (CDR) to trigger when a potentially malicious email appearing to come from an Accepted Domain but DMARC had a (transient) TempError result.
description-detailed: |
  This query can be used as a Custom Detection Rule (CDR) to trigger when a potentially malicious email appearing to come from an Accepted Domain but DMARC had a (transient) TempError result. DMARC or SPF results can be modified to trigger on "temperror", "permerror", "softfail" or "fail" depending on requirements. Can be run in Continuous (NRT) frequency. https://learn.microsoft.com/en-us/defender-xdr/custom-detection-rules
requiredDataConnectors:
- connectorId: MicrosoftThreatProtection
  dataTypes:
  - EmailEvents
tactics:
  - InitialAccess
relevantTechniques:
  - T1566
query: |
  let SenderDomains = pack_array ('contoso.com','fabrikam.fr');
  EmailEvents
  | where EmailDirection == 'Inbound' and SenderMailFromDomain in (SenderDomains)
  | extend SPF= tostring(parse_json(AuthenticationDetails).SPF)
  | extend DMARC= tostring(parse_json(AuthenticationDetails).DMARC)
  | where DMARC == "temperror" or SPF == "temperror"
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/Custom Detections/Message from Accepted Domain with DMARC TempError.yaml)

False Positive Guidance

• Scenario: Scheduled System Job Sending Emails to Internal Recipients
  Description: A scheduled job (e.g., Microsoft Exchange’s “Send As” task, or a third-party tool like Microsoft Power Automate or AWS Step Functions) sends emails to internal users as part of an automated process (e.g., report distribution, password reset).
  Filter/Exclusion: Check the Message-Id or X-MS-Exchange-Organization-Message-Id header for known internal job IDs, or filter by From address matching internal admin tools (e.g., admin@domain.com).

• Scenario: Legitimate Email from a Third-Party Service Provider
  Description: A legitimate email is sent from a third-party service (e.g., ServiceNow, Zendesk, or Salesforce) that is configured to use the organization’s accepted domain for email replies.
  Filter/Exclusion: Use the Received header to identify the originating IP or domain, or check the X-Envelope-From header to verify the actual sender.

• Scenario: Email from a Trusted Partner with Misconfigured DMARC
  Description: A trusted business partner sends an email using the organization’s accepted domain (e.g., via Microsoft 365 or Google Workspace) but has misconfigured DMARC, leading to a temporary error.
  Filter/Exclusion: Filter by the From address of the partner’s email system, or check the Authentication-Results header for SPF and DKIM alignment.

• Scenario: Internal User Sending Email to External Partner with Accepted Domain
  Description: An internal user sends an email to an external partner using the organization’s accepted domain (e.g., user@company.com to partner@company.com) due to a misconfiguration or mistake.
  *Filter/Ex