Display Name and Exact Domain Spoofing Guide: Detecting Internal Impersonation and First Contact Fraud

Most impersonation email that reaches finance and executive inboxes does not need to break SPF, DKIM or DMARC: it borrows a trusted display name from a free mailbox, or forges your own domain through a path that authentication is not enforced on. Display name spoofing puts "Chief Executive" in the From name over an attacker-controlled address; exact domain spoofing forges your real domain in the From header and relies on a receiving system that does not act on the authentication failure. Both feed business email compromise (BEC), payment diversion and gift card fraud. This guide covers how each technique works, the mail platform controls that catch them, external sender tagging and first contact warnings, detection, and the process controls that stop the payment when a message gets through. It is written for email administrators, security operations and finance control owners. For domain authentication and the wider BEC picture, see the Email Identity and BEC Guide.

Key takeaways

• Two different problems need two different controls. Exact domain spoofing is stopped by enforced DMARC and closed unauthenticated paths; display name spoofing passes authentication and is caught by impersonation detection, tagging and process.
• Your own domain is the first one to lock down. Publish DMARC at p=reject, make sure inbound filtering honours it, and close internal relays and direct send paths that accept unauthenticated mail claiming your domain.
• Tag external and first-time senders. A native External tag and a first contact warning are cheap, low noise signals that break the "it looks internal" assumption.
• Protect names, not just domains. Executive and finance names in the display name of an external message are the core signal; both major mail platforms can flag them.
• Payment process is the last control. Out of band verification of any bank detail change or urgent payment request stops the fraud even when the message is perfect.

How the techniques work

In MITRE ATT&CK v20 these behaviours sit under T1684 Social Engineering, specifically T1684.001 Impersonation and T1684.002 Email Spoofing, with delivery via T1566 Phishing and, when an internal account is used, T1534 Internal Spearphishing. Lookalike domains are covered in the Brand Impersonation and Lookalike Domain Takedown Playbook; this guide focuses on display name and exact domain cases.

Stopping exact domain spoofing

Exact domain spoofing only works when the receiving system either cannot tell the message failed authentication or chooses to deliver it anyway. Close both gaps.

• Publish and enforce DMARC: move your domains, including parked and non-sending domains, to p=reject once all legitimate senders are aligned. DMARC is now specified in RFC 9989 (Proposed Standard, May 2026), which obsoletes RFC 7489. See the DMARC, SPF and DKIM Guide and the DMARCbis Changes Guide.
• Make inbound filtering act on your own policy: many tenants protect other people from your spoofed domain but still deliver spoofs of it internally because of allow rules, connector bypasses or a gateway in front of the mail platform that strips the evidence. Check that inbound evaluation honours DMARC reject and quarantine for your own domains.
• Close unauthenticated paths that accept your domain: scanners, printers and line of business apps often send as your domain through an open relay or an unauthenticated submission path. Inventory them, move them to authenticated submission or a dedicated subdomain, and then block the unauthenticated path. Microsoft documents direct send, in which devices send to Microsoft 365 recipients over port 25 without credentials using any accepted domain address, and says most customers do not need it; Exchange Online provides an organisation setting (RejectDirectSend) to reject it. See the Microsoft 365 Direct Send guide.
• Remove broad allow rules: transport rules that skip filtering for your own domain or for a partner's IP range turn a DMARC failure into a delivered message.

See the Email Sending Sources Inventory Template to record every legitimate sender before enforcement.

Detecting display name impersonation

Display name impersonation needs detection that compares the sender's name with the people your users trust. The core signals are:

• Protected name match: the display name matches or nearly matches an executive, finance approver or key supplier contact, but the address is external.
• Unusual characters: lookalike letters or digits in the address or name, such as a Cyrillic character or a zero for an "o".
• First contact: the recipient has never, or rarely, received mail from this address.
• Free mailbox plus internal name: an internal person's name sent from a consumer webmail domain is rarely legitimate.
• Reply-To divergence: the Reply-To domain differs from the From domain on external mail.
• Content cues: urgency, secrecy, payment, gift cards, bank detail change, or a request to move to a phone or chat channel.

Platform controls

Platforms are listed alphabetically. The settings below come from each vendor's administrator documentation as of November 2026; both are customer-side settings that administrators turn on and tune.

Google Workspace (Gmail)

Gmail's advanced phishing and malware protection includes a Spoofing and authentication group of settings in the Admin console under Apps, Google Workspace, Gmail, Safety:

• Protect against spoofing of employee names: flags messages whose sender name matches a name in your Workspace directory but which do not come from your domain or aliases. This is the native display name control.
• Protect against inbound emails spoofing your domain: targets messages that claim to come from your domain and fail both SPF and DKIM.
• Protect against domain spoofing based on similar domain names: handles lookalike domains of your domains and aliases.
• Protect against any unauthenticated emails: requires SPF or DKIM to pass for any domain; unauthenticated messages display a question mark next to the sender name.
• Protect Groups from inbound emails spoofing your domain: applies the same protection to all groups or private groups only.
• Actions: keep the email in the inbox and show a warning, move it to spam, or quarantine it. Start with warnings, review results, then move higher-confidence settings to spam or quarantine.

See the Google Workspace Security Guide for the wider tenant settings.

Microsoft 365 (Exchange Online and Defender for Office 365)

Microsoft's anti-phishing policies split into spoof settings, which are built into Exchange Online Protection, and impersonation settings in Defender for Office 365:

• Spoof intelligence: on by default in the default policy and new custom policies; blocked spoofed senders go to Junk Email (default) or quarantine.
• Honor DMARC record policy when the message is detected as spoof: lets you quarantine or reject messages whose domain publishes p=reject, and quarantine or junk p=quarantine. If MX points to a third-party service in front of Microsoft 365, this applies only when Enhanced Filtering for Connectors is turned on.
• Unauthenticated sender indicators: a "?" on the sender photo when SPF and DKIM fail and DMARC or composite authentication fails, and a "via" tag when the From domain differs from the DKIM or MAIL FROM domain.
• First contact safety tip: shows "You don't often get email from" the sender when the recipient rarely or never receives mail from them; it does not depend on spoof or impersonation settings.
• User impersonation protection: up to 350 protected users per policy, internal or external, with actions such as quarantine or move to Junk (the default action is to apply none, so set one).
• Domain impersonation protection and mailbox intelligence: up to 50 custom domains per policy; turn on Enable intelligence for impersonation protection (off by default) so mailbox intelligence can act on learned contact patterns.
• Impersonation safety tips: user, domain and unusual characters tips warn the reader inline.
• Trusted senders and domains: up to 1,024 exceptions; keep the list short, because entries are never classified as impersonation.

See the Microsoft Defender for Office 365 Configuration Guide for the wider policy set.

Availability: Google documents the spoofing and authentication settings as part of Gmail advanced phishing and malware protection; Microsoft documents spoof settings and the first contact safety tip in Exchange Online Protection and impersonation settings in Defender for Office 365 Plan 1 and Plan 2. Confirm the edition requirements against each vendor's current documentation.

External sender tagging and first contact warnings

Tagging tells users that a message came from outside, so an internal-looking display name on an external message stands out. The two approaches compare as follows:

For most organisations the best combination is a native External tag for every external message, a first contact warning, and a targeted, stronger warning when an external sender uses an internal protected name. Avoid generic banners on every message as the only control: users learn to ignore them.

Implementing in phases

1. Inventory (weeks 1 to 2): list all sending sources for your domains, all transport allow rules and connector bypasses, and the names to protect: executives, finance approvers, payroll, and top suppliers.
2. Close exact domain paths (weeks 2 to 6): move unauthenticated senders to authenticated submission, then set DMARC to p=quarantine and p=reject in steps, watching aggregate reports. Turn on inbound handling that honours DMARC and block unauthenticated internal paths.
3. Turn on tagging (week 3): enable the native External tag, retire old subject-prefix rules, and confirm first contact warnings show.
4. Name protection in audit mode (weeks 3 to 6): configure protected users and employee name spoofing with the mildest action (warning, or move to Junk) and review hits each week for false positives such as executives using personal mail.
5. Enforce (week 7 onwards): move high-confidence detections to quarantine, keep a short, reviewed trusted senders list, and publish a process for executives who must send from outside.
6. Roll back if needed: each setting can return to warning-only per policy; keep a record of the previous state so a false positive surge can be reversed in minutes.

Small and large organisations

A small business on a single platform can usually do all of this with built-in settings in a few days: DMARC at reject, native External tag, employee name protection and a written payment verification rule. Large organisations with a secure email gateway in front of the mail platform must check that authentication results survive the gateway, decide which layer enforces, and keep the protected names list synchronised with HR data.

Where identity fits

Exact domain spoofing often hides behind non-human senders: multifunction printers, monitoring tools and SaaS apps sending as your domain with shared SMTP credentials or none at all. Give each sender its own authenticated identity, scoped to the addresses it may send as, and record it in the sending sources inventory. API keys for email delivery services deserve the same care as other secrets. See the SendGrid, Mailgun and Mailchimp API Keys Security Guide.

Stopping the payment

The FBI's September 2024 public service announcement on BEC (I-091124-PSA) reported USD 55.5 billion in exposed losses across 305,033 incidents from October 2013 to December 2023. Its recommendations include verifying account change requests through a secondary channel and checking the full sender address rather than the display name, especially on mobile. Turn that into process:

• Call back on a known number: verify any bank detail change or new payee using contact details from the vendor master file, never from the email.
• Dual approval: require a second approver for payments above a threshold and for any first payment to new bank details.
• Cooling-off period: hold first payments to changed bank details for a set period.
• No exceptions for seniority: make it policy that an executive request by email never overrides verification.

See the Business Email Compromise Awareness for Finance Teams Guide and, if money has moved, the Business Email Compromise Response Playbook.

Detection and measurement

• Detections to build: external sender with a display name matching a protected name; DMARC fail for your own domains delivered to any mailbox; Reply-To domain differing from From domain on external mail; first contact sender plus payment keywords; protected name from consumer webmail domains.
• Logs to use: message trace and header fields such as Authentication-Results, and in Microsoft 365 the X-Forefront-Antispam-Report header SFTY values (9.25 for first contact, 9.19 domain impersonation, 9.20 user impersonation). See the Email Gateway and Message Trace Detection Guide.

Framework mapping

See the CIS Control 9 Email and Web Browser Protections Guide.

Common failure patterns

• DMARC at reject, spoofs still delivered: an allow rule, connector bypass or gateway means the tenant never acts on the failure for its own domain.
• Forgotten printers and apps: an unauthenticated internal relay accepts mail claiming your domain from anywhere it can reach.
• Impersonation protection with no action: protected users are configured but the action is left at none, so detections only appear in reports.
• Trusted senders list as a dumping ground: large allow lists suppress exactly the detections that matter.
• Banner fatigue: a loud banner on every external message trains users to ignore it, and attackers copy the banner HTML into their messages.
• Process bypass for executives: payment verification is skipped because the request appears to come from the CEO.

Practitioner checklist

• Set DMARC to p=reject for every sending and parked domain, after aligning all legitimate senders.
• Confirm inbound filtering honours DMARC for your own domains and that no allow rule or connector bypasses it.
• Inventory and close unauthenticated paths that accept mail as your domain, including direct send and open relays.
• Turn on a native External tag and confirm first contact warnings display.
• Configure employee name and user impersonation protection for executives, finance and payroll, with a real action.
• Build detections for protected names from external senders and Reply-To divergence.
• Keep trusted sender exceptions short and review them quarterly.
• Enforce out of band verification and dual approval for bank detail changes and urgent payments.

Standards and references

• IETF: RFC 9989, Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• Microsoft Learn: Anti-phishing policies in Microsoft 365
• Microsoft Learn: Set-ExternalInOutlook
• Microsoft Learn: How to set up a multifunction device or application to send email using Microsoft 365
• Google Workspace Admin Help: Advanced phishing and malware protection
• FBI IC3: Business Email Compromise, The $55 Billion Scam
• MITRE ATT&CK: T1684.001 Impersonation

Related NHI Mgmt Group resources: Email Identity and BEC Guide · DMARC, SPF and DKIM Guide · Brand Impersonation and Lookalike Domain Takedown Playbook · Payment Fraud Guide