Why are internal emails flagged as impersonation when using a 3rd party provider even with SPF and DKIM verification?
Updated on 5 Oct 2026: We clarified why authenticated third-party emails trigger internal impersonation warnings and how to diagnose the exact verdict.
Emails sent to employees through a third-party provider can be flagged as impersonation because they use your company's From address but arrive as external mail. The cause can be missing DMARC alignment, authentication changes at a gateway, or an impersonation policy that flags the sender even when authentication passes. SPF and DKIM verification inside a marketing platform means the platform is configured to authenticate mail. It does not mean every internal gateway, filter, and mailbox layer will trust the message after the next handoff.
The common pattern is simple: a campaign is sent through Salesforce Marketing Cloud Account Engagement (formerly Pardot), HubSpot, Marketo, or another third-party provider using a visible From address on the company domain. The first gateway can record valid authentication. A later internal layer, often Microsoft 365, can see a different connecting IP or modified signed content and record an authentication failure. A separate user impersonation policy can also flag the sender's display name without any authentication failure.
An internal-only warning does not establish an external deliverability problem. Check the internal mail flow and the policy verdict first. Other recipients do not see the same internal route, so they do not necessarily see the same warning. Still, do not ignore it, because the same header evidence can reveal a real SPF, DKIM, or DMARC issue before it spreads outside the company.
- Header proof: Compare the gateway's trusted Authentication-Results with the final mailbox result.
- Route proof: Check whether a gateway sits between the provider and Microsoft 365.
- Domain proof: Confirm the DKIM signing domain or SPF envelope domain matches the visible From domain for DMARC.
- Policy proof: Ask IT whether the warning came from anti-spoofing, user impersonation, domain impersonation, or phishing policy.
Why authentication passes still trigger warnings
SPF and DKIM answer narrow questions. SPF asks whether the connecting sender is allowed by the envelope sender domain. DKIM asks whether selected message headers and body content still match the signature. DMARC asks whether SPF or DKIM passes with a domain that matches the visible From domain. Internal impersonation filters ask a different question: does this message behave like a trusted internal sender or like an outside system pretending to be one?
Microsoft 365 also has composite authentication, shown as compauth in headers. Microsoft authentication combines standard authentication with sender history, reputation, recipient history, and behavior signals. A message can pass SPF, DKIM, DMARC, and compauth and still trigger a separate impersonation verdict. Conversely, compauth failure alone does not determine whether Microsoft 365 blocks the message.
The most useful evidence is not the provider's green check mark. It is the full message header from an affected internal recipient. Look for the first authentication result, the final authentication result, the Return-Path, the DKIM-Signature domain, and the connecting IP at each hop.
- First pass: A gateway can record SPF, DKIM, and DMARC as passing when the provider first delivers the message.
- Later fail: Microsoft 365 can later see the gateway IP as the sender and fail SPF for the original bounce domain.
- Signature break: Link rewriting, footers, disclaimers, and security scanning can break DKIM if they change signed content.
If a trusted gateway result says DMARC passed and the final result says DMARC failed, investigate the handoff before changing DNS. Verify the Authentication-Results authserv-id against your known receivers; a header inserted by an untrusted sender is not proof of authentication.
What SPF and DKIM prove
Start by separating authentication from trust. Authentication is mechanical. Trust is a policy decision made by the receiving system. A marketing platform can pass its setup tests because the domain has the right CNAMEs, TXT records, or DKIM keys. Your internal security filter can still decide the message is risky because the visible From address is an employee or company domain, but the route is external.
Use a DMARC checker to confirm the public DNS record is valid, then use real message headers to confirm what receivers actually evaluated. DNS checks and message checks answer different parts of the problem.
DMARC alignment can be relaxed or strict. Relaxed alignment accepts the same organizational domain, while strict alignment requires an exact domain match. Only one passing authentication method with the required domain match is needed for DMARC to pass. For example, with From: news@example.com, a passing DKIM signature with d=example.com can satisfy DMARC even when the provider uses its own bounce domain. A relay that breaks SPF does not cause DMARC failure if this DKIM signature still passes.
|
|
|
|---|---|---|
SPF | The connecting sender is allowed for the envelope domain. | The visible From domain can still be different. |
DKIM | Signed content verifies using the signing domain's public key. | The signing domain can differ from From; DKIM does not verify an employee's identity. |
DMARC | SPF or DKIM passed with a matching From domain. | Passing DMARC does not override impersonation or content policy. |
CompAuth | Microsoft judged sender authenticity with extra signals. | The reason code still needs header context. |
Policy | IT defined how suspicious mail is treated. | A rule can be stricter for internal recipients. |
Authentication checks compared with internal impersonation checks.
Illustrative gateway pass followed by a mailbox failuretext
From: Company news <news@example.com> Return-Path: <bounce@bounce.example.com> Authentication-Results-Original: gateway.example.net; spf=pass smtp.mailfrom=bounce.example.com; dkim=pass header.d=example.com header.s=marketing; dmarc=pass header.from=example.com Authentication-Results: mailbox.example.net; spf=fail smtp.mailfrom=bounce.example.com; dkim=fail header.d=example.com header.s=marketing; dmarc=fail header.from=example.com; compauth=fail reason=000
This simplified example assumes the first result came from your trusted gateway. The original DKIM signing domain matches From, so its pass supports the original DMARC pass. After the relay, neither method passes. Microsoft's reason=000 indicates explicit authentication failure with DMARC policy p=quarantine or p=reject; it is not a generic code for every gateway problem.
Why external and internal recipients see different results
External recipients usually receive the message directly from the marketing provider or through their own gateway chain. Internal recipients receive it through your company's inbound path. Those paths do not have to produce the same result. A message can pass at Gmail, fail inside Microsoft 365 after a gateway relay, and still be correctly authenticated at the provider.
Salesforce Marketing Cloud Account Engagement settings with SPF and DKIM verified.
Shared IP sending adds a second layer of confusion. A shared IP is not automatically bad, and it does not explain an internal-only impersonation warning by itself. It matters more for Gmail and other mailbox providers because shared IP reputation is affected by all senders on that pool. For senders of 5,000 or more messages per day to personal Gmail accounts, Google sender guidelines require SPF and DKIM, a DMARC record, and From-domain alignment through SPF or DKIM for direct mail. Their marketing and subscribed messages also need one-click unsubscribe and a visible unsubscribe link in the body.
External recipient path
- Connection: The mailbox provider sees the marketing platform or its sending infrastructure.
- Result: SPF, DKIM, and DMARC are judged against the original external delivery.
- Risk: Spam placement depends on reputation, content, recipient feedback, and authentication.
Internal recipient path
- Connection: A secure gateway can relay the message into Microsoft 365.
- Result: The final layer can see the gateway as the sender and fail SPF.
- Risk: The filter can mark the message as domain or user impersonation.
Gmail spam placement after a test send is a separate signal. If the domain has low or sporadic marketing volume, Gmail has less positive history for the authenticated identifiers used by that platform. Authentication lets the sender build reputation under the right identifiers. It does not grant inbox placement on day one.
How to diagnose internal impersonation warnings
Start with the actual message, its route, and the policy verdict before changing DNS. The route tells you who saw the message, who modified it, and which system applied the warning. DNS tells you whether the public setup gives receivers enough information to authenticate the sender.
- Get headers: Export the original message as an .eml file with full headers; a normal inline forward loses useful evidence.
- Find results: Read Received headers bottom to top to reconstruct the route; compare trusted Authentication-Results, Authentication-Results-Original, and the final compauth value and reason code.
- Compare hops: Identify where SPF, DKIM, or DMARC changed from pass to fail, or confirm that authentication passed throughout.
- Check domains: Compare header From, Return-Path, DKIM d=, and the signing selector.
- Ask policy: Record the exact warning, message trace identifier, applied policy, and threat category.
- Test outside: Send the same campaign to external seed inboxes and compare final headers.
A domain health check helps confirm the baseline DNS state before you change anything. Also check for an SPF permerror. SPF evaluation allows no more than 10 DNS-causing terms across the full evaluation, including nested includes and redirects. Exceeding that limit returns permerror and needs record cleanup rather than a connector change.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
After the DNS baseline is clean, focus on the internal handoff. Enhanced Filtering for Connectors can recover the original sender information when a gateway receives mail before Microsoft 365. Authenticated Received Chain (ARC) preserves earlier authentication results through signed headers that a receiver can evaluate when an intermediary modifies or relays messages.
Email authentication flowchart showing SPF, DKIM, and DMARC changes after an internal relay.
If authentication passes for external recipients but an internal policy fires, DNS changes are not automatically required. Bring the mail-flow admin and the relevant security and marketing operations owners into the same header review.
Distinguish spoofing from impersonation
An impersonation safety tip is different from an authentication failure. In Microsoft 365, check the CAT field in X-Forefront-Antispam-Report alongside Authentication-Results and the applied anti-phishing policy.
|
|
|
|---|---|---|
CAT:SPOOF | Spoofing | Sender authentication and the gateway route. |
CAT:UIMP | User impersonation | Display name and protected user settings. |
CAT:DIMP | Domain impersonation | Sender domain and protected domain settings. |
CAT:GIMP | Mailbox intelligence impersonation | Sender relationships learned by mailbox intelligence. |
Microsoft 365 threat categories identify which protection detected the message.
A first contact safety tip indicates an unfamiliar sender. An external sender label indicates message origin. Neither alone establishes a DMARC failure.
For a confirmed spoofing false positive, review spoof intelligence and allow only the verified sender/infrastructure pair in the Tenant Allow/Block List. User or domain impersonation exceptions belong in the detecting anti-phishing policy's Trusted senders and domains settings. Prefer a specific email address over a domain-wide exception; these entries are not restricted to a connector.
Submit the original message to Microsoft as a false positive for analysis, then retest the same sending path with full headers.
Preserve the original sender in Microsoft 365
When internet mail reaches Microsoft 365 through a gateway, Enhanced Filtering for Connectors can make Microsoft 365 evaluate the original internet sender instead of treating the gateway IP as the source. This setting is also called skip listing. Use it when your MX routes internet mail through a gateway before Microsoft 365. It is not intended for a service that scans mail after Microsoft 365.
- Scope the connector: Use the inbound connector that receives gateway mail and include only the public IP addresses of trusted intermediary hops.
- Pilot with recipients: Apply enhanced filtering to a small recipient set before expanding it to the organization.
- Verify headers: Look for X-MS-Exchange-ExternalOriginalInternetSender or X-MS-Exchange-SkipListedInternetSender after a test.
- Remove conflicting bypasses: Review and normally disable connector transport rules that request an SCL -1 spam bypass after enhanced filtering is enabled; evaluation mode or a phased deployment has different requirements.
ARC handles a related part of the route. The intermediary records incoming authentication results, then seals the message it forwards after its changes. Trust only a sealer connected to a verified mail path. If the gateway does not add an ARC seal, Enhanced Filtering for Connectors can still recover source information and reduce false DMARC failures caused by the handoff. ARC does not repair the original DKIM signature or bypass impersonation filtering.
Do not put broad or unverified IP ranges on the skip list. An incorrect range can make Microsoft 365 evaluate the wrong hop as the original sender. Document the route, test a small recipient set, and confirm the stamped headers before wider use.
What to fix first
Fix the earliest confirmed failure. If SPF fails only after a gateway relay, do not start by adding the gateway IP to a third-party bounce domain you do not control. If DKIM passes before the gateway and fails after, find what changed the signed content. If DMARC never passed at any hop, fix the provider authentication and domain matching first.
|
|
|
|---|---|---|
SPF pass then fail | Gateway relay changed the connecting IP. | Recover the source IP with enhanced filtering; use trusted ARC evidence where applicable. |
DKIM pass then fail | Message content changed after signing. | Reduce signed-content changes or configure a trusted ARC sealer. |
DMARC fails everywhere | No matching SPF or DKIM domain. | Configure custom DKIM or branded bounce. |
Only staff see warnings | Gateway authentication changes or an internal anti-phishing verdict. | Identify the verdict, then correct routing or the specific policy. |
Gmail spam | Low history, content, or shared IP reputation. | Send consistently and monitor feedback. |
Common causes and the first practical fix.
Simple DMARC record for monitoringdns
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
A monitoring policy is a starting point for a domain that is not yet enforcing DMARC. The rua address must receive and process aggregate reports; replace the example address with your own reporting destination. A p=none policy requests no DMARC enforcement, but recipients still apply spam and impersonation policies. Keep an existing p=quarantine or p=reject policy when onboarding a provider; fix its authentication before sending. RFC 9989 makes pct historic, so do not use pct to stage enforcement. Move policy only after legitimate sources pass consistently.
Do not create a broad allow rule for anything that claims to be your domain. Verify the sender and sending infrastructure before a spoofing exception. For an impersonation exception, prefer the specific sending address in the policy that detected it, and document its scope and review. A sender-only exception does not enforce a connector path.
The right fix can be technical, policy-based, or both. For a provider like Pardot, check that custom DKIM is active, the return-path or bounce domain is correct, and the From domain is the domain you expect. For Microsoft 365, check whether the secure gateway is treated as a trusted inbound source and whether authentication results are preserved in a way Microsoft can use.
Use Suped reports to check third-party senders
Suped is our DMARC reporting and email authentication platform. Suped's DMARC monitoring shows sending sources and authentication results in aggregate reports received for your domain. Use these reports to check a third-party provider's domain matching and compare results before and after a configuration change.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
In this workflow, Suped can identify a failing source, show whether SPF or DKIM matched the From domain, provide remediation steps, and confirm the result in later reports. Aggregate reports do not contain the full message headers, employee display names, or the Microsoft 365 policy that generated a safety tip. Pair Suped reports with the affected message and its message trace.
Manual header checking
- Speed: Good for one incident, slow across many campaigns.
- Scope: You see only the original messages captured with full headers.
- Risk: Teams can over-correct SPF or create broad allow rules.
Suped workflow
- Speed: Sources, failures, and fixes are visible in one place.
- Scope: Track sources reported by participating receivers; reporting coverage is not complete.
- Risk: Compare authentication results before changing DNS or internal policy.
Suped reports support authentication diagnosis. Your IT team still needs to check the internal gateway and Microsoft 365 policy verdict when a warning appears only for employees.
How to explain it to IT
The clearest explanation is: the campaign can authenticate correctly at the internet edge, but our internal route can change the final result, or a separate impersonation policy can flag the sender. The warning identifies something to investigate; it does not prove the public SPF record is wrong.
Ask IT for the rule name, the message trace, and the connector path. If the rule is user impersonation, the display name or From address can be the trigger. If it is domain impersonation, inspect the actual sending domain against protected domains rather than assuming external routing alone caused the verdict. If it is a composite authentication failure, the headers should show whether Microsoft saw spf=fail, dkim=fail, dmarc=fail, or only a policy warning.
The target is a verified sending path where the provider passes DMARC, the gateway preserves usable authentication evidence, and Microsoft 365 continues filtering the message. Apply a specific impersonation exception only if the confirmed false positive remains after those checks.
If external recipients also see spam placement, treat that as a parallel deliverability project. Review list consent, sending cadence, unsubscribe headers, content, complaint rate, and the reputation of the authenticated domain. For deeper authentication cases, the same pattern appears when DMARC can still fail even though the sender thought SPF and DKIM were set up.
Views from the trenches
Best practices
Compare trusted gateway and final Authentication-Results before changing DNS or sender settings.
Use custom DKIM with the required From-domain match; add a branded bounce domain where supported.
Keep policy exceptions specific to verified senders; record their scope and review them regularly.
Common pitfalls
Treating a shared IP as the cause before checking the gateway handoff wastes time fast.
Reading only the final header can hide a clean pass recorded by the first gateway upstream.
Changing SPF to fix a DKIM break caused by message rewriting creates new DNS risk quickly.
Expert tips
Ask IT to preserve authentication results between the secure gateway and Microsoft 365 layers.
Send the same campaign to internal, Gmail, and seed inboxes, then compare outcomes side by side.
Warm low-volume marketing identifiers gradually so mailbox providers see steady sending history.
Marketer from Email Geeks says external authentication can pass at the gateway, while Microsoft 365 later marks the same message as failing after an internal handoff.
2024-02-07 - Email Geeks
Marketer from Email Geeks says sending mail from your own domain through an outside platform to your own employees matches many impersonation rules.
2024-02-07 - Email Geeks
