Outlook is displaying the warning because Microsoft 365 sees a message that looks internal to the recipient, but the message enters the tenant from an outside mail system. With a CRM sending through SendGrid, the usual cause is that the visible From name or address looks like your organization, while the message authenticates as SendGrid, an unauthenticated CRM source, or another domain that does not match the visible sender domain.
The fix is not to add random SendGrid IPs to SPF. The practical fix is to authenticate SendGrid as your domain, sign the message with DKIM using your domain in d=, confirm the Return-Path domain is branded where possible, publish DMARC reporting, and check whether your Microsoft 365 admin has a mail flow rule or impersonation policy that intentionally adds the warning.
I treat this warning as useful until the headers prove otherwise. It exists because business email compromise often uses a familiar internal display name with an outside sending path. Good DMARC monitoring turns that guess into evidence: which service sent the mail, which domain authenticated, which source failed, and what needs to change.
Fast answer: if SPF passes only because of include:sendgrid.net, but DKIM signs as SendGrid or the Return-Path domain is not your domain, Outlook still has a rational reason to warn users.
- Primary fix: Enable SendGrid domain authentication for the exact domain or subdomain used in the visible sender address.
- Minimum requirement: Get DKIM signing to show d=yourdomain.com or a controlled subdomain.
- Admin check: Ask the Microsoft 365 admin whether an external sender or impersonation rule changed recently.
- 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, the authentication results, and tenant-level 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.
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 account compromise 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 your visible sender domain.
- SPF misunderstanding: SPF checks the envelope sender domain, not the friendly From address users see.
- Policy trigger: A Microsoft 365 rule adds a banner when an outside sender uses an internal display name.
- New source: The CRM changed sending pools, IPs, envelope domains, or DKIM settings without a matching DNS update.
Microsoft explains that suspicious sender behavior can cause Outlook to mark a sender as unverified or warn the recipient. The details depend on tenant settings, but the security model is consistent: Outlook wants evidence that the sender is who the message claims. Microsoft's Outlook phishing guidance is worth sharing with users if they keep asking why the banner appears.
The fastest way to confirm the cause
I start with one affected message and inspect the headers. Do not start by editing DNS. First prove which identity passed authentication. In Microsoft 365, open the message details or trace the message, then read the Authentication-Results header. The important question is not whether SPF or DKIM passed. The important question is which domain passed.
|
|
|
|---|---|---|
DKIM | Your domain | SendGrid only |
SPF | Branded path | Vendor path |
DMARC | Pass | Fail |
From name | Clear sender | Internal name |
Source | Expected CRM | Unknown IP |
Header checks that separate a harmless banner from a real authentication problem.
A quick public DNS check helps before you ask the CRM or Microsoft admin to change anything. Suped's domain health check checks DMARC, SPF, and DKIM-related DNS posture in one pass, which is useful when the problem spans more than one protocol.
0.0
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 signs as your domain and DMARC passes, the warning is more likely a Microsoft 365 display-name policy. If DKIM signs as SendGrid and DMARC fails, fix SendGrid domain authentication before touching the Outlook rule.
The SPF include alone answers only one narrow question: are SendGrid's sending servers allowed for the envelope sender domain being checked? It does not prove that the visible sender domain passed DMARC.
- 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.
- Outlook scope: Outlook also evaluates display-name impersonation and tenant security rules.
Fix SendGrid authentication first
For SendGrid, the most important fix is domain authentication. In practice that means adding SendGrid's CNAME records for the sending domain, then verifying that the CRM is using that authenticated domain for the sender identity. The end state I want is simple: the visible From domain, the DKIM d= domain, and the DMARC result all point back to a domain you control.
Twilio SendGrid Sender Authentication screen with DNS records for domain authentication.
Typical SendGrid DNS 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 targets for your account. Once they verify, send a new CRM message and check whether DKIM shows your domain in d=. Then use the DMARC checker to confirm that the published policy and reporting addresses are valid.
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: Weak if DKIM and the visible sender domain do not match.
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 manage rotating infrastructure behind the target.
- DMARC value: Strong when DKIM passes for the same organizational domain users see.
My preferred SendGrid fix order is DKIM first, branded Return-Path second, DMARC reporting third, then a staged DMARC policy once the CRM and every other sender is clean.
Starter DMARC recordDNS
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:d@example.com"
Check the Outlook rule and internal identity policy
After SendGrid authentication is correct, involve the Microsoft 365 admin. The exact banner often comes from a tenant rule or anti-impersonation policy, not from SendGrid. That rule can be narrow and helpful, or it can be too broad and catch every CRM notification that uses an employee name.
The admin should check mail flow rules, external sender tagging, impersonation settings, and any recently changed security policy. If the CRM started showing the warning for all internal recipients during the same week, a tenant-side rule change is a strong candidate. If only SendGrid-routed CRM messages trigger it, header authentication still deserves the first fix.
How to classify the warning
Use the header result and sender identity to decide whether to fix DNS, policy, or both.
Low risk
Review policy
DKIM uses your domain, DMARC passes, and the CRM sender name is clearly labeled.
Medium risk
Rename sender
DMARC passes, but the display name looks like a protected employee identity.
High risk
Fix auth
DKIM or SPF passes only as SendGrid, and DMARC fails for the visible domain.
Unknown
Investigate
Headers show a source IP 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, and a broad allow rule can train users to trust a pattern that attackers also use. SendGrid's own SendGrid security advice is a reminder that account protection and sender verification belong together.
If the banner says messages can be spoofed, the same logic applies: fix the domain proof first, then review Microsoft 365 policy. I have a separate explanation of the spoofed warning when the wording is different but the underlying sender identity issue is similar.
A practical remediation plan
This is the order I use because it separates authentication, naming, and Microsoft 365 policy. It also gives the CRM owner, DNS owner, and tenant admin clear work instead of letting everyone guess.
- Capture evidence: Save one affected message, its full headers, the recipient domain, the CRM record that triggered it, and the exact sender address.
- Verify SendGrid: Open SendGrid Sender Authentication and confirm the sending domain is verified, not just the account.
- Inspect DKIM: Send a fresh CRM message and confirm DKIM passes with your domain in d=.
- Inspect SPF: Check which Return-Path domain SPF evaluated and whether that domain is part of your controlled sending setup.
- Confirm DMARC: Make sure DMARC passes for the visible sender domain before asking Outlook to trust the message.
- Fix naming: If the CRM sends as an employee, change it to a clear service identity such as Jane via CRM or CRM alerts.
- Review policy: Ask the Microsoft 365 admin to tune the rule only after the message has correct authentication evidence.
- Monitor results: Watch DMARC aggregate reports and user reports for at least one full sending cycle.
Remediation ownership
Most fixes need more than one owner, so assign each piece instead of treating it as one DNS task.
CRM owner
DNS owner
M365 admin
Security owner
If the warning disappears after DKIM signs with your domain, the root cause was sender authentication. If it persists with clean DMARC, the rule is doing display-name impersonation protection. In that case I keep the protection, but narrow the CRM sender identity so the message does not pretend to be a direct internal person-to-person email.
Where Suped fits
Suped's product is useful here because the problem spans several systems. The CRM owner sees SendGrid. The DNS owner sees SPF, DKIM, and DMARC records. The Microsoft 365 admin sees a warning banner. Suped brings those signals into one place and points to the sending source that needs work.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
For most teams, Suped is the best overall DMARC platform because it turns aggregate reports into source-level issues, real-time alerts, and practical steps to fix. That matters when the root cause is not a single typo but a mix of SendGrid authentication, CRM sender naming, and Microsoft 365 policy.
- Issue detection: Suped flags unauthenticated or unknown SendGrid-related sources and gives steps to fix them.
- Hosted controls: Suped's Hosted DMARC makes policy staging easier when several senders need cleanup.
- Unified checks: SPF, DKIM, DMARC, blocklist (blacklist), and deliverability signals sit in the same workflow.
- MSP support: Agencies and managed service providers can manage multiple client domains without mixing reports.
- Alerting: Real-time alerts help catch a CRM sending change before employees report Outlook warnings.
The important point is that Suped does not replace SendGrid setup or Microsoft 365 policy work. It makes the evidence easier to see, keeps the sending-source inventory current, and reduces the guesswork when a warning appears again.
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 the warning active until DMARC reports show the CRM source is consistently clean.
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.
Using an employee display name for automated CRM mail triggers 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 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 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
The practical answer
Outlook is warning because the message looks like it came from inside your organization, but the delivery path and authentication evidence say it came from an outside system. With a CRM sending through SendGrid, the clean fix is to authenticate SendGrid as your domain, sign with your own DKIM domain, verify DMARC pass, and use a sender name that does not mimic an employee unless it is truly a mailbox-backed sender.
If the headers still look clean and the banner remains, it is time for the Microsoft 365 admin to tune the policy. Keep the rule narrow. Trust the CRM because it authenticates correctly and uses a clear identity, not because all SendGrid mail was allowed around the filter.
The answer to the SPF question is direct: include:sendgrid.net is normally the right SPF mechanism for SendGrid, but it is not the complete fix for Outlook warnings. DKIM and DMARC domain matching are the parts that usually decide whether the message proves it belongs to your domain.
