Why new relationships demand higher scrutiny.
OpenEFA® Signals Series | March 28, 2026
Every relationship starts somewhere. In email, that first message from an unknown sender represents both an opportunity and a risk — and attackers know that the moment of first contact is when defenses are weakest.
When a message arrives from a domain your organization has never interacted with before, something important is happening: a new trust boundary is being created. That boundary doesn't come with history, context, or behavioral baselines. It comes with nothing but the message itself — and whatever the sender claims to be.
Most email security systems treat this moment the same as any other. OpenEFA® does not.
The majority of targeted email attacks begin with a first interaction. This is not a coincidence — it's a strategy.
Consider the attacker's challenge: they need to establish credibility with someone who has no reason to trust them. They can't rely on an existing relationship, a shared history, or a familiar conversation thread. They have one chance to appear legitimate enough to earn a response, a click, or an action.
This is why first-contact messages are disproportionately represented in:
In each case, the attacker benefits from the same thing: the recipient has no prior experience with this sender. There is no baseline to compare against. There is no history that would make an inconsistency obvious.
A first-contact domain is any sending domain that has no prior communication history with the recipient or the recipient's organization. OpenEFA tracks this at multiple levels:
The specific recipient has never received email from this domain before. This is the most granular level — even if other people in the organization have corresponded with the domain, this particular user has not. The message represents a new relationship for this individual.
No one in the organization has ever received email from this domain. This is a stronger signal. It means the domain is entirely unknown to the business — there is no institutional familiarity, no shared context, no prior verification.
Beyond the relationship itself, the domain's own history matters. A first-contact message from a domain registered last week carries different risk than one from a domain that has been active for ten years. OpenEFA correlates first-contact status with domain age, registration patterns, and DNS infrastructure to build a more complete picture.
Not every first-contact domain is malicious. Businesses form new relationships constantly. A new vendor reaches out. A potential customer sends an inquiry. A recruiter contacts a hiring manager. A regulatory body issues a notification.
The challenge is distinguishing between these legitimate first contacts and the ones designed to exploit the absence of history.
OpenEFA approaches this by evaluating first-contact messages across multiple dimensions simultaneously:
Does the sending domain have properly configured SPF, DKIM, and DMARC? Legitimate organizations — especially those initiating business relationships — overwhelmingly maintain complete authentication records. A first-contact domain with missing or misconfigured authentication is a compounding risk signal.
Does the first-contact domain visually or structurally resemble a domain the organization already trusts? Attackers frequently register lookalike domains — swapping characters, adding hyphens, using alternative TLDs — to exploit the brief moment before the recipient notices the difference. A first-contact message from acme-corp.net when the organization has an existing relationship with acmecorp.com is a signal that demands attention.
What is the message asking for? A first-contact message that requests a wire transfer, demands credential entry, or pushes for immediate action is fundamentally different from one that introduces a service or asks a routine question. The combination of first contact and high-stakes intent is a powerful risk indicator.
Where is this email actually coming from? OpenEFA examines the sending infrastructure — mail server reputation, IP history, hosting patterns — to determine whether the domain's technical footprint is consistent with what it claims to be. A domain claiming to represent a major corporation but sending from a shared hosting provider is a meaningful inconsistency.
Sophisticated attackers understand the first-contact dynamic and design their campaigns around it. Several patterns are common:
Rather than leading with a malicious payload, the attacker sends an innocuous first message — a generic introduction, a scheduling request, or a simple question. If the recipient responds, a relationship has been established. The malicious request comes in message two or three, now carrying the credibility of an ongoing conversation.
The attacker impersonates a senior executive or external authority figure. The first message references an internal project, a board decision, or a regulatory requirement. The recipient, unfamiliar with this particular sender but respectful of the claimed authority, complies without verifying.
The attacker monitors public information — job postings, press releases, LinkedIn activity — to identify when an organization is onboarding new vendors. They then impersonate that vendor, sending a first-contact message that aligns with the recipient's expectations. The timing makes the message feel anticipated rather than unexpected.
The attacker claims to have been referred by a mutual contact: "Sarah in your procurement team suggested I reach out." This manufactured social proof gives the first-contact message an artificial sense of legitimacy that can bypass casual scrutiny.
When OpenEFA identifies a first-contact domain, it doesn't block the message by default. Instead, it applies a heightened evaluation framework that treats the absence of history as a risk factor to be weighed alongside other signals.
This means:
The fundamental principle behind the First Contact Domain signal is simple: trust must be earned through consistent, verifiable behavior over time. It cannot be assumed based on a single message, no matter how legitimate that message appears.
This mirrors how trust works in every other domain of security. A new employee doesn't receive full system access on day one. A new vendor doesn't get payment terms before a contract is signed. A new application doesn't get network privileges before a security review.
Email should work the same way.
As a sender demonstrates consistent authentication, predictable behavior, and legitimate intent across multiple interactions, their trust level increases. OpenEFA tracks this progression, gradually reducing scrutiny as the relationship matures and the behavioral baseline solidifies.
This approach means that:
Consider this situation:
Recipient: Accounts Payable coordinator
Sender: billing@acme-solutions.net
Subject: "Updated Payment Instructions — Acme Solutions"
"Hi — we've recently updated our banking details due to a change in our payment processing provider. Please find the updated wire instructions attached. We'd appreciate if you could update your records before the next payment cycle. Let me know if you have any questions."
The message is polite, professional, and well-formatted. The domain passes SPF and DKIM. There are no malicious links. The attachment is a clean PDF.
But OpenEFA detects:
acme-solutions.netacmesolutions.com, a known vendor in the organization's communication historyNo single signal is definitive. Together, they form an unmistakable pattern: a newly registered lookalike domain, making a first-contact financial request with manufactured urgency. The message is flagged for review before it reaches the recipient's inbox.
First Contact Domain is part of the OpenEFA Signals framework — a set of behavioral and contextual patterns that reveal risk before it becomes an incident.
The core principle: the absence of history is itself a signal. When a message arrives from a domain with no relationship to the organization, every other signal in that message must be evaluated with greater care.
New relationships are inevitable. New relationships that arrive with financial requests, urgency, and lookalike domains are not coincidences — they are patterns that demand scrutiny.
OpenEFA provides that scrutiny automatically, so trust can be extended deliberately rather than exploited opportunistically.