A sender-recipient baseline is a behavioral profile of how two parties normally communicate over time. It captures patterns such as message frequency, topic, timing, and request type. Security teams use this baseline to spot abnormal invoice requests, unusual urgency, or other signs that a familiar exchange has been manipulated.
How a Sender-Recipient Baseline Works
A sender-recipient baseline is not a static rule, but a living profile built from observed communication over time. It helps security teams understand what “normal” looks like between two parties so that deviation stands out.
The baseline usually reflects frequency, timing, topic, tone, and request patterns. A finance team member who normally receives routine invoice follow-ups at month-end may look very different from the same person receiving urgent payment-change requests at odd hours from a familiar counterpart.
What the Baseline Helps Detect
The main value of the baseline is that it turns relationship history into a detection signal. Because the model is anchored in how a pair normally interacts, it can reveal subtle manipulation that would not trigger a simple keyword or spam filter.
Common examples include invoice fraud, business email compromise, fake urgency, and requests that fit the relationship superficially but not behaviorally. The goal is to notice when an expected conversation suddenly carries a new purpose, pace, or pressure.
Why It Matters in Business Email Compromise Defense
Sender-recipient baselines are especially useful where attackers exploit trust rather than technical weakness. If an adversary compromises one mailbox or impersonates a trusted sender, the message may appear legitimate at a glance, while the historical communication pattern tells a different story.
This makes the baseline a relationship-aware control: it looks at who is communicating, how often, and in what manner, rather than only checking whether a message passes authentication or filtering. That extra context is what helps expose social-engineering attempts that borrow the shape of real work.
Limits, Tuning, and Operational Use
Baselines are strongest when they are tuned to the actual business relationship, not just the mailbox. A stable vendor relationship, a fast-moving executive assistant exchange, and a seasonal finance workflow all have different normal patterns, so the baseline must be sensitive enough to catch abnormality without generating constant noise.
They also work best as one signal among several. A sender-recipient anomaly becomes more compelling when it aligns with unusual payment instructions, a changed tone, or a request that breaks established approval habits. Used this way, the baseline supports triage, investigation, and fraud prevention rather than acting as a standalone verdict.
Risk and Threat Considerations
Sender-recipient baselines are vulnerable when attackers can imitate the cadence of a trusted relationship or when the underlying communication history is sparse, seasonal, or noisy. In those cases, manipulation may blend into normal workflow patterns until the request reaches a human decision point.
Failure mechanism: The attacker exploits familiarity, mailbox compromise, or impersonation to issue a request that matches the relationship well enough to avoid obvious suspicion, while subtly changing timing, urgency, or payment details.
Impact: Organisations can approve fraudulent invoices, redirect funds, or miss early warning signs of business email compromise because the message looks normal in isolation but abnormal against the established baseline.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-9 — Email and Web Browser Protections | Email trust abuse is a core use case for sender-recipient anomaly detection. |
| Recommendation — Correlate suspicious mailbox behavior with CIS-9-aware email protections and alert on unusual sender-recipient patterns. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and systems are monitored to detect potential cybersecurity events | Baselining communication patterns is a monitoring technique for detecting abnormal events. |
| Recommendation — Use communication baselines to surface deviations in monitoring and triage pipelines. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Review, Analysis, and Reporting | The baseline depends on reviewing communication telemetry for anomalous behavior. |
| Recommendation — Review message-traffic anomalies and report deviations that suggest manipulation or fraud. | ||
| MITRE ATT&CK | T1566 — Phishing | Abnormal sender-recipient behavior often reveals phishing or business email compromise. |
| Recommendation — Map anomalous request patterns to phishing activity and escalate suspicious exchanges. | ||
Practitioner Guidance
Why practitioners should care: This term is operationally important because its value depends on context quality. Teams need to understand which relationships are stable enough to baseline and which are too dynamic to trust without additional controls.
Common misunderstanding: A sender-recipient baseline is not the same as message authentication or spam filtering. It does not prove legitimacy, it only raises suspicion when a trusted exchange starts to behave differently.
Practitioner takeaway: Treat the baseline as a behavioral layer for fraud detection, then confirm anomalies with business context before actioning any high-impact request.
Related resources from NHI Mgmt Group
- Why do misdirected email controls need better contextual understanding of sender and recipient relationships?
- Why does recipient-side risk matter more than sender-side monitoring for scam prevention?
- What is the difference between email sender authentication and recipient-facing visual trust signals?
- Sender and Recipient Verification