Why is Outlook displaying phishing warnings on emails sent from my CRM through Sendgrid, and how can I fix it?
Published 5 Jun 2025
Updated 19 Oct 2026
15 min read
Summarize with
Updated on 19 Oct 2026: We clarified SendGrid domain authentication, Outlook warning diagnostics, and the steps for reporting confirmed false positives to Microsoft.
Outlook displays the warning when Microsoft detects an authentication problem, a suspicious sender identity, or another phishing signal. A common CRM-to-SendGrid case is mail that looks internal but enters Microsoft 365 through an outside system. Check whether the visible From name or address resembles your organization while the message authenticates with an unrelated domain or fails authentication.
Authenticate the sending domain in SendGrid, publish the exact DNS records it provides, get DKIM to sign with a domain that matches the visible sender domain under DMARC, brand the Return-Path where possible, and check whether a Microsoft 365 policy adds the warning.
Treat the warning as a reason to investigate until the sending path and message content have been verified. Business email compromise often uses a familiar internal display name with an outside sending path. DMARC monitoring provides sending-source and authentication evidence; the affected message and recipient admin establish why Outlook showed the warning.
Fast answer: an SPF pass for a SendGrid-controlled Return-Path does not prove that the visible sender passed DMARC. DMARC fails when neither SPF nor DKIM passes for a domain that matches the visible sender. Outlook also applies separate impersonation and phishing checks to authenticated messages.
- Primary fix: Enable SendGrid domain authentication for the exact domain used in the visible sender address.
- DKIM target: Get DKIM signing to show d=yourdomain.com or a controlled subdomain that matches under DMARC.
- Admin check: Ask the Microsoft 365 admin which spoof, impersonation, safety-tip, or mail-flow policy stamped the message.
- Do not do: Disable the warning globally before proving the CRM path is authenticated correctly.
Why Outlook shows the warning
Outlook and Exchange Online do not judge a message only by the friendly display name. They evaluate the sender address, the route into the tenant, standard authentication, Microsoft composite authentication, sender history, and tenant policies. A CRM message can be legitimate and still look suspicious when it says it came from an employee or internal department, but the technical sender is outside the organization. Microsoft 365 tenant policies apply to work or school mailboxes. Outlook.com personal accounts have separate filtering and no customer-managed tenant policy.
This is common when a CRM sends internal notifications, lead alerts, quote approvals, or task reminders. The CRM chooses a familiar internal name so the message feels clear to employees. Microsoft 365 sees a different pattern: an outside server is displaying an internal identity. That is the same shape as many sender impersonation attempts.
Flowchart showing a CRM message passing through SendGrid and Outlook identity checks.
- Display-name match: The message uses the name of a real employee, team, or executive, but arrives from outside the tenant.
- DKIM mismatch: The DKIM signature authenticates SendGrid or a CRM domain instead of a domain that matches the visible sender. This does not cause DMARC failure if SPF passes with a matching domain.
- SPF misunderstanding: SPF checks the envelope sender domain, not the friendly From address users see.
- Policy trigger: A Microsoft 365 rule or anti-phishing policy adds a warning for spoofing, user impersonation, domain impersonation, or first contact.
- New source: The CRM changed sending pools, envelope domains, DKIM settings, or tracked-link domains without a matching configuration update.
Microsoft explains that Outlook can mark a sender as unverified when authentication cannot establish the identity or when the authenticated identity differs from the visible From address. A question-mark sender icon and a via tag are different clues, so record the exact indicator rather than calling every case a DMARC failure. Microsoft's Outlook phishing guidance is useful for explaining those indicators to users.
The fastest way to confirm the cause
Start with one affected message and inspect the full headers. Do not start by editing DNS. First prove which identity passed authentication and which Microsoft verdict triggered. In Microsoft 365, open the message details or trace the message, then read the Authentication-Results and X-Forefront-Antispam-Report headers. The important question is not only whether SPF or DKIM passed. It is which domain passed and what Microsoft did with that result.
|
|
|
|---|---|---|
DKIM / header.d | Pass with a matching signing domain | Failure, missing signature, or an unrelated signing domain |
SPF / smtp.mailfrom | Pass for the actual Return-Path domain | A branded domain alone does not prove SPF passed |
DMARC / header.from | Pass for the visible From domain | Fail, none, or bestguesspass instead of a published-policy pass |
compauth | Pass with its reason code | Fail and its reason code, plus the applied policy |
Source | Expected CRM path | Unknown sending infrastructure |
Read the authentication result and the domain together; a vendor Return-Path still permits DMARC to pass through matching DKIM.
A quick public DNS check helps before you ask the CRM or Microsoft admin to change anything. Suped's product includes a domain health check for reviewing DMARC, SPF, and DKIM-related DNS posture in one pass, which is useful when the problem spans more than one protocol.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
If you can send a fresh CRM message to a test mailbox, compare the live headers with the DNS state. If DKIM uses your domain, DMARC passes, and compauth=pass, the warning is more likely tied to impersonation, first-contact, content, link, sender-reputation, or tenant-policy checks. If DKIM uses a SendGrid domain and DMARC fails, fix SendGrid domain authentication before touching the Outlook rule.
SPF answers one narrow question: is the sending server allowed for the envelope sender domain being checked? An SPF pass satisfies DMARC only when that domain matches the visible sender domain under the applicable matching mode.
- SPF scope: SPF authenticates the bounce domain, also called the envelope sender or Return-Path.
- DKIM scope: DKIM authenticates the domain in the signature's d= value.
- DMARC scope: DMARC needs SPF or DKIM to pass with a domain that matches the visible sender domain.
- Microsoft scope: Microsoft also evaluates composite authentication, spoofing, impersonation, content, links, and tenant rules.
Read Microsoft's verdict headers
Microsoft 365 combines explicit authentication with sender history and policy signals. The compauth result shows composite authentication, while fields in X-Forefront-Antispam-Report show the category and safety tip that Microsoft applied. A composite authentication failure does not automatically block a message; other assessments also affect the verdict.
|
|
|
|---|---|---|
compauth=fail | Composite authentication failed | Check the reason code and domain matching |
CAT:SPOOF | Spoof intelligence flagged the sender | Fix authentication or review the sender pair |
CAT:UIMP, DIMP, or GIMP | User, domain, or mailbox-intelligence impersonation | Change the CRM identity or review the detecting policy |
SFTY:9.25 | First-contact safety tip | Confirm the sender pattern and policy |
CAT:PHSH or HPHSH | Phishing or high-confidence phishing | Review content, links, redirects, and reputation |
SFV:SPM or CAT:SPM | Spam filtering classified the message as spam | Review traffic quality and sender reputation |
CAT:BULK / BCL | Bulk-mail category and bulk complaint level | Review recipient consent and complaint-prone traffic |
Common Microsoft 365 verdict fields in a warned CRM message.
A first-contact tip such as "You don't often get email" concerns contact history and can appear even when authentication passes. Microsoft's anti-phishing policy documentation explains when it appears.
Use CAT and DIR to interpret cloud filtering; SCL alone is not the final classification. Microsoft's message header reference documents the verdict fields.
A clean DMARC result does not cancel a separate impersonation or phishing verdict. If compauth=pass appears with an impersonation category, review the display name and protected identities. If it appears with a phishing category, inspect every destination URL, SendGrid click-tracking rewrite, redirect, attachment, and recent traffic change before editing DNS.
SendGrid link branding makes tracked links use a subdomain you control instead of a shared SendGrid domain. It can make the sender identity clearer, but it does not override a Microsoft verdict or repair an unsafe destination URL. Use the category field to decide whether the next owner is responsible for authentication, CRM content, sender reputation, or Microsoft 365 policy.
Fix SendGrid authentication first
For SendGrid, the most important fix is domain authentication. Add the exact DNS records generated for the sending domain, then verify that the CRM uses that authenticated domain in the visible sender address. The target result is simple: the visible From domain matches the DKIM d= domain or the SPF Return-Path domain under the published DMARC mode, and DMARC passes.
Twilio SendGrid Sender Authentication screen with DNS records for domain authentication.
Typical SendGrid authentication CNAME recordsDNS
em123.example.com CNAME u123456.wl.sendgrid.net. s1._domainkey.example.com CNAME s1.domainkey.u123456.wl.sendgrid.net. s2._domainkey.example.com CNAME s2.domainkey.u123456.wl.sendgrid.net.
Those records are examples, not values to copy. SendGrid generates the exact records and targets for your account, and automated security commonly manages SPF and DKIM through CNAME delegation. SPF is checked at the delegated Return-Path subdomain, so adding a SendGrid include to your root SPF record is unnecessary for that setup. Once verification succeeds, send a new CRM message and check which domain appears in header.d. Then use the DMARC checker to confirm that the published policy and reporting addresses are valid.
Check aspf and adkim in the existing DMARC record. Relaxed mode, the default, permits domains with the same organizational domain. Strict mode requires an exact domain match. For From: alerts@example.com, em123.example.com fails strict SPF matching, but passing DKIM with d=example.com still satisfies DMARC.
Single Sender Verification confirms access to an address; it does not configure domain authentication. If the CRM sends through a vendor-managed SendGrid account or subuser, have the CRM provider authenticate your domain there. A verified domain in a separate account does not configure the CRM's sending path. SendGrid documents subuser domain assignment.
SPF-only setup
- Sender proof: SPF can pass for a bounce domain that users never see.
- Outlook result: The message can still look like an outside system using an internal identity.
- Maintenance: Adding individual IPs creates stale DNS risk when SendGrid changes infrastructure.
- DMARC value: SPF alone satisfies DMARC when it passes with a matching Return-Path domain. Matching DKIM adds resilience when forwarding breaks SPF.
Domain-authenticated setup
- Sender proof: DKIM signs with your domain or a controlled sending subdomain.
- Outlook result: The message has clearer proof that the CRM is authorized.
- Maintenance: CNAME records let SendGrid update rotating infrastructure behind the target.
- DMARC value: DKIM must pass with a signing domain that matches the visible From domain under its DMARC matching mode.
Use this SendGrid fix order: complete domain authentication, verify DKIM and Return-Path domain matching in a live message, start DMARC aggregate reporting, then move to a stricter DMARC policy once the CRM and other approved senders pass consistently. Use the starter record only for a domain without DMARC. If a policy exists, preserve its enforcement and reporting destinations, and edit that record instead of publishing a second one. Replace the example reporting mailbox with an address that receives aggregate reports.
Starter DMARC recordDNS
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:d@example.com"
Check Microsoft 365 anti-phishing policies and rules
After SendGrid authentication is correct, involve the Microsoft 365 admin. The exact indicator can come from spoof intelligence, an anti-phishing policy, a first-contact safety tip, a mail flow rule, or a separate phishing verdict. A policy can be narrow and useful, or it can catch every CRM notification that uses an employee name.
The admin should check the message's category and safety fields, anti-phishing policies, spoof intelligence, protected users and domains, mail flow rules, and recent policy changes. If all internal recipients started seeing the warning at the same time, a tenant-side change is a strong candidate. If only SendGrid-routed CRM messages trigger it and compauth=fail, sender authentication still needs the first fix.
How to classify the warning
Use the header result and sender identity to decide whether to fix DNS, content, policy, or more than one area.
Authentication passes
Inspect verdict
DMARC and composite authentication pass. Review content, tracked links, and the applied policy before treating the message as safe.
Identity mismatch
Rename sender
DMARC passes, but the display name looks like a protected employee identity.
DMARC fails
Fix auth
SPF or DKIM passes only for a vendor domain, and DMARC fails for the visible domain.
Unknown
Investigate
Headers show a source, URL, or sending domain that the CRM owner cannot explain.
Do not add a blanket allow rule for SendGrid just to hide the warning. SendGrid is a shared sending platform, so a broad exception can cause unrelated mail to bypass the intended check. If a business-critical flow must continue during remediation, the Microsoft 365 admin can review a narrow, temporary allow entry for the exact spoofed sender and sending-infrastructure pair, then manually remove it after authentication is fixed. Microsoft's spoofed-sender guidance confirms that these entries do not expire automatically. SendGrid's own SendGrid security advice also explains how to recognize suspicious mail and protect a SendGrid account.
If the banner says messages can be spoofed, the same logic applies: fix the domain proof first, then review Microsoft 365 policy. The explanation of the spoofed warning covers that wording and the related sender identity issue.
Submit persistent false positives to Microsoft
If authentication and message content are correct but Microsoft still flags the email, the recipient's Microsoft 365 admin should submit it as a false positive.
- In Microsoft Defender, open Actions & submissions > Submissions, select Emails, then Submit to Microsoft for analysis.
- Upload the original .eml or .msg file, or enter the network message ID, and specify an affected recipient.
- Select "I've confirmed it's clean" after verifying the message, then submit and review the analysis.
- Retest a fresh CRM message to the affected mailbox after Microsoft responds, keeping the same sending domain and template.
A submission does not automatically override impersonation protection. Review the anti-phishing policy that detected the sender. Confirm which filter needs correction before creating an exception. Microsoft's submission instructions describe the workflow.
A practical remediation plan
Use this order to separate authentication, naming, content, sender reputation, and Microsoft 365 policy. It gives each owner clear work instead of letting everyone guess.
- Capture evidence: Save one affected message, its full headers, the recipient domain, the CRM event that triggered it, and the exact sender address.
- Identify the verdict: Record compauth and its reason code, CAT, DIR, SFTY, SFV, BCL, and the exact Outlook indicator before changing DNS.
- Verify SendGrid: Open SendGrid Sender Authentication and confirm the domain is verified in the account or subuser actually used by the CRM.
- Inspect DKIM: Send a fresh CRM message and confirm DKIM passes with your domain in header.d.
- Inspect SPF: Check which Return-Path domain SPF evaluated and whether that domain matches the controlled sending setup.
- Confirm DMARC: Make sure DMARC passes for the visible sender domain before asking Outlook to trust the message.
- Fix identity and content: Use a clear service sender, then inspect tracked links and redirects if Microsoft stamped a phishing category.
- Review policy: Ask the Microsoft 365 admin to tune the exact rule or sender pair only after the message has correct authentication evidence.
- Monitor results: Watch DMARC aggregate reports and user reports for at least one full sending cycle, and retest a fresh message in each affected recipient tenant.
|
|
|---|---|
CRM owner | Confirm the sending account and sender identity; review templates and tracked links. |
DNS owner | Publish the generated authentication records and preserve the existing DMARC policy. |
Microsoft 365 admin | Read recipient-side verdicts, review the detecting policy, and submit confirmed false positives. |
Security owner | Validate message safety and approve, track, and remove any narrow exception. |
Responsibilities for resolving CRM email warnings.
If the warning disappears after an authentication-only change, that is evidence of an authentication issue. When several settings change together, compare the headers before assigning a root cause. If it persists with clean composite authentication, use the Microsoft category to find the next cause. Keep impersonation protection, but change the CRM sender identity so an automated message does not look like direct person-to-person mail.
Monitor CRM authentication with Suped
Suped's product is useful when the warning spans CRM settings, SendGrid authentication, DNS records, and Microsoft 365 policy. It turns DMARC aggregate data into a sending-source inventory, so the team can confirm whether SendGrid is the expected source and whether its messages pass with the intended domains.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Suped converts aggregate reports into source-level issues, alerts, and practical remediation steps. Compare that authentication evidence with the affected message's Microsoft headers. Aggregate reports do not contain CRM display names, message content, or the exact Outlook warning.
- Issue detection: Suped flags unauthenticated or unknown SendGrid-related sources and gives steps to fix them.
- Hosted controls: Suped's Hosted DMARC supports policy staging while approved senders are cleaned up.
- Unified checks: SPF, DKIM, DMARC, blocklist (blacklist), and delivery signals sit in the same workflow.
- Multiple domains: Agencies and managed service providers can manage client domains without mixing reports.
- Alerting: Alerts highlight authentication changes as reports arrive. DMARC aggregate reporting is delayed, so confirm live Outlook warnings with message headers.
Use Suped's authentication evidence alongside SendGrid setup and Microsoft 365 policy review to keep the sending-source inventory current and investigate recurring warnings.
Views from the trenches
Best practices
Check the Authentication-Results header before changing SPF, DKIM, or Microsoft 365 rules.
Use a CRM service sender name when the message is automated and sent to internal users.
Require DKIM signing with your own domain before asking admins to suppress warnings.
Keep protection active; clean DMARC reports alone do not establish that a message is safe.
Common pitfalls
Adding vendor IPs to SPF can hide the real issue and create stale sender authorization.
Treating every Outlook banner as a DNS failure wastes time when tenant rules changed.
An employee display name on automated CRM mail can trigger recipient impersonation checks.
Assuming SPF pass means DMARC pass misses the visible sender domain match requirement.
Expert tips
Compare one warned CRM message with one clean CRM message to isolate the changed field.
Ask the Microsoft 365 admin for the exact transport rule or policy that added the banner.
Use a controlled sending subdomain when the CRM has different risk than human mailbox mail.
Track SendGrid source changes in DMARC reports so routing changes do not become surprises.
Marketer view
Marketer from Email Geeks says the Microsoft 365 admin should be involved early because tenant rules often decide when the warning appears.
2021-08-31 - Email Geeks
Marketer view
Marketer from Email Geeks says a warning on internal-looking CRM mail is consistent with business email compromise protection, not just a delivery bug.
2021-08-31 - Email Geeks
Frequently asked questions
No. Complete SendGrid domain authentication and publish its generated DNS records. Adding individual IPs creates maintenance risk and does not prove that the visible sender domain passed DMARC.
SPF can pass for the Return-Path domain while the visible From domain is different. DMARC needs SPF or DKIM to pass for a domain that matches the visible sender domain.
Do not create a broad SendGrid exception. Fix domain authentication first. If business mail must continue during remediation, an admin can review a narrow, temporary allow entry for the exact spoofed sender and sending-infrastructure pair, then manually remove it after verification because spoofed-sender entries do not expire automatically.
Use a clear service identity for automated mail unless the message truly comes through that user's mailbox. Names such as Jane via CRM or CRM alerts reduce confusion and impersonation flags.
Check the full headers. If DMARC fails because neither SPF nor DKIM passes with a matching domain, fix SendGrid authentication. A DKIM failure alone does not cause DMARC failure when SPF passes with a matching domain. If DMARC and composite authentication pass, use Microsoft's category and safety fields to investigate the recipient policy or message content.
