The impersonation policy nobody populated

A message arrives displaying the finance director's name. The address belongs to a consumer mailbox provider. The message asks for payment details to be changed.

SPF, DKIM and DMARC are not the problem. The external provider genuinely sent the message. This is exactly the kind of case impersonation protection is meant to help with.

The useful question is not whether that feature is enabled. It is what the feature actually knows about your organization.

Enabled is not the same as complete

Different mail-security platforms build impersonation decisions differently. Some use lists of protected people and domains. Some use directory information. Some learn normal communication patterns. Many combine several signals.

That means there is no single checkbox that proves the protection is complete. An environment can have impersonation protection switched on while the people most likely to be impersonated are missing, old identities remain protected years after departure, legitimate alternate addresses are misunderstood, or broad exceptions have quietly weakened the policy.

The control exists. The data behind it may no longer describe the company.

Protect the people attackers are likely to borrow

Start with the identities that carry authority. Senior leadership is obvious, but the highest-risk list is usually broader:

• Finance and payroll.
• HR.
• IT and security administrators.
• Executive assistants.
• Anyone who can approve payments, change banking information, reset credentials or release sensitive information.

The exact mechanism differs by platform. The operational question does not: If someone used this person's name from an unrelated external address tomorrow, what would your mail system know about that identity?

That answer should be intentional.

The company changes faster than the policy

Impersonation configuration ages quietly. A new CFO joins. A founder leaves. An executive starts using a second legitimate address. A board member receives access. Responsibilities move from one person to another.

Nothing necessarily reminds the mail administrator that the protection model should change with them. A configuration built during a deployment three years ago can be technically valid and organizationally wrong. This is one reason mail-security review should include organizational data rather than only policy settings.

Exceptions are where good controls get weaker

False positives are inevitable. An executive sends legitimately from another address. A recruiting platform sends messages using a staff member's display name. An advisor works from an external organization.

The quickest response is often to trust the sender or exempt a large domain. That can solve today's problem while weakening tomorrow's protection.

Where the platform allows it, prefer the narrowest explanation of what is legitimate: the specific identity, address or service relationship rather than an entire platform or sender population.

An exception should answer three questions:

• Who asked for it?
• Why is it needed?
• When should somebody check it again?

If nobody can answer those questions, it is no longer an exception. It is simply part of the security posture.

Automatic intelligence still needs reviewing

Directory-driven or learned impersonation protection reduces manual maintenance. It does not eliminate it.

The platform may know that two people communicate regularly, but it cannot know whether that relationship is still appropriate. It may know who is in the directory, but not which roles currently authorize a payment.

Automation can improve the signal. Ownership still matters.

The check worth running

Open whatever your mail platform uses for impersonation protection. Compare it with the people who currently hold financial, administrative or executive authority. Then review the trusted identities, domains and exceptions that have accumulated since deployment.

You are not looking for whether the feature is enabled. You are looking for whether it still describes the company you have today.

Explore this expertise: Email Security

All technical notes