Mql Detection Authoring

Operator writes an MQL rule to flag display-name spoofing where the From display name impersonates an exec but sender.email.domain differs from the org's verified domains. They reference headers.reply_to and sender.email.domain i…

Author the rule against the documented MQL message data model: use sender.email.domain.domain, headers.reply_to[], and the org's known-domain list (e.g. an org_vars / external list reference) rather than hardcoding a domain literal. Combine display-name similarity with an authentication signal (DMA…

Operator writes a rule that should only fire when the sender has never previously communicated with the recipient org (a classic BEC pre-condition). They reference a sender-profile / message-context attribute.

Use Sublime's documented sender/recipient context attributes (e.g. a first-time-sender or known-correspondent signal derived from the org's mail history) rather than re-implementing communication-history tracking in the rule. Combine first-contact with a content cue so routine new-vendor mail is no…

An MQL rule calls strings.icontains(body.current_thread.text, 'urgent') but the message is a calendar invite with no body text, so body.current_thread is null for that message.

Guard attribute access for messages where a field may be absent: MQL evaluates lazily, but the rule should be written so a null body or empty thread yields a clean no-match, not a rule error. Use the documented helper functions (e.g. strings.* / any / all over a possibly-empty list) and test the ru…