Legitimate SharePoint document share requests come from the platform's own sharing service acting on behalf of a verified sender inside your organization or tenant. The sender is a real user, group, or site with an actual permission grant behind the message. The email envelope usually originates from Microsoft's notification infrastructure, not the sender's personal mailbox, which is why forensic checks must look past the display name to the actual granted identity.
Understanding that split between who authorized the share and who physically sent the mail resolves most confusion. The authorization identity is what matters for security. The transport identity is what appears in headers.
Identity layers behind a share notification
A SharePoint share produces several distinct identities at once. The first is the sharing principal: the authenticated user, security group, Microsoft 365 group, or site that holds permission to invite others. The second is the notification service, which composes and sends the email. The third is the link token embedded in the URL, which encodes the permission scope and expiration.
When a user clicks "Share" on a document, the client calls the SharePoint sharing API. The API checks whether that principal has the Share or Manage Permissions right on the item or its parent. If the check passes, the service records an access grant and queues a notification. The email you receive is a byproduct of the grant, not the grant itself. This is why disabling email notifications does not revoke access and why a message can arrive even when the stated sender never touched their outbox.
The practical consequence is that the display name in the From field proves almost nothing by itself. Anyone can set a display name on an external message. What distinguishes a genuine SharePoint request is the combination of a real access grant in the tenant, a legitimate notification origin, and a link token that resolves to the correct site.
How the notification pipeline actually works
SharePoint notifications pass through Exchange Online and the broader Microsoft 365 notification service. The visible sender address is typically a no-reply or share-specific alias tied to the tenant, often something like [email protected] or a tenant-configured address. The message body carries the sender's display name and email, but the transport path reflects Microsoft infrastructure.
The access grant itself lives in the site's permission structure. External sharing adds entries to a secure external sharing list or, in newer models, issues time-bound sharing links with defined scopes: specific people, organization-wide, anonymous, or password-protected. Each link type maps to a different risk profile. A "specific people" link requires the recipient to authenticate, which binds the grant to an identity. An anonymous link does not, which is why organizations often restrict it.
There is also a token layer. Sharing links include a signed token that encodes the item, the permission level, and an expiration. When the recipient opens the link, SharePoint validates the token before serving content. An expired or revoked link fails at this stage even if the email looks perfect. This token validation is the real gate, and it is invisible in the message itself.
Professional caveat that surprises many administrators: the sender shown in the email can differ from the principal that actually created the link. A user with delegated access, or a service account acting on a workflow, can generate shares attributed to a document owner. Auditing the actual API caller, not the email, is the only reliable attribution.
Quantified context: volume, timing, and thresholds
SharePoint sharing volume scales with tenant size and collaboration habits. A mid-sized tenant with a few thousand active users can generate thousands of share notifications daily, most of them routine. The signal-to-noise problem is real: legitimate requests vastly outnumber malicious ones, so blanket suspicion of every share email produces fatigue that erodes vigilance.
Timing offers a usable threshold. A notification that arrives within seconds to a few minutes of the underlying grant is normal. A message that references a document you have never accessed, from a sender you do not recognize, arriving outside business hours in your region, warrants scrutiny. Microsoft's default sharing link expiration for "specific people" links is often 30 days in many tenant configurations, and organization-wide links can be governed by admin-set policies. An invitation to a link with an unusually long or unlimited lifetime is a mild flag.
Retention and audit logs matter for reconciliation. Microsoft 365 audit logs typically retain sharing events for 180 days by default, extendable with add-on licensing. If you need to verify a share older than that window, the log may be gone. Treat the email as ephemeral evidence and the audit record as primary.
Edge cases that mimic legitimate requests
Several benign scenarios produce share emails that look suspicious to a careful reader. External guest invitations can arrive with the guest's display name but originate from the tenant's notification service. B2B collaboration in Entra ID (formerly Azure AD) routes invitations through a redemption flow, so the invitation email may come from a Microsoft domain even though a colleague initiated it.
Automated workflows and Power Automate flows can share documents programmatically. The resulting email may show a service account or the flow owner as sender, and the timing can be odd. Shared mailboxes and distribution lists can also authorize shares, so the "sender" is a group rather than a person.
Counterintuitive detail worth internalizing: a perfectly spoofed phishing email and a genuine SharePoint notification can be nearly indistinguishable in the inbox. The distinguishing evidence is almost never in the message design. It is in whether the link token resolves to your tenant, whether the sender identity matches an actual grant, and whether the audit log shows the event. Reading the email harder does not resolve it; checking the permission layer does.
Common misconceptions and red flags
The persistent myth is that the From address authenticates the sender. Email authentication standards like SPF, DKIM, and DMARC verify domain sending rights, not human identity, and a compromised or lookalike domain can pass some checks. A second myth holds that SharePoint notifications always come from the sharer's own mailbox, which is false for the notification service path.
Red-flag warnings as bullets:
The link resolves to a domain that is not your organization's SharePoint or OneDrive host and does not redirect there after authentication. The message pressures immediate action, credential entry, or MFA approval before you can verify the sender through another channel. The stated sender is someone you can reach, but the email asks you to sign in through an embedded form rather than the standard Microsoft sign-in. The share grants broad or anonymous access when your organization restricts external or anonymous links. The notification references a document name you cannot find in your tenant after signing in normally. The sender address uses a lookalike domain with subtle character substitutions.
None of these alone proves malice. Together they justify verification before interaction.
Comparison of share request types
| Request type | Visible sender | Authentication required | Typical risk | Verification step |
|---|---|---|---|---|
| Internal specific-people share | Colleague display name via notification service | Yes, tenant sign-in | Low | Confirm grant in audit log |
| External guest invitation | Guest or inviter name via Entra B2B | Yes, redemption flow | Moderate | Check guest account status |
| Organization-wide link | Sharer display name | Yes, org sign-in | Low to moderate | Confirm link scope policy |
| Anonymous link | Sharer display name | No | High | Verify policy allows it |
| Workflow-generated share | Service account or flow owner | Yes | Moderate | Trace the automation owner |
| Lookalike phishing message | Spoofed name, external domain | Varies | High | Inspect link host and token |
The comparison shows why "who sent it" is less useful than "what grant exists." The table is a triage aid, not a verdict.
Timeline of a legitimate share
| Stage | What happens | Typical timing | What you can observe |
|---|---|---|---|
| Authorization | Principal passes permission check | Instant | Nothing yet |
| Grant creation | Access entry or link token issued | Seconds | Audit log entry appears |
| Notification queued | Service composes email | Seconds to minutes | Email enters transport |
| Delivery | Message arrives in inbox | Minutes | Message visible |
| Link redemption | Recipient authenticates and token validates | On click | Access log entry |
| Expiration | Token or grant lapses per policy | Days to months | Access denied after expiry |
The timeline clarifies that the email is a late, cosmetic step. The security-relevant events happen before and after it, largely outside the inbox.
Practical verification steps
Verification should be procedural, not intuitive. The goal is to confirm the grant, not to judge the message.
First, do not click the link in the email. Open SharePoint or OneDrive through your normal bookmark or app, sign in, and search for the document by name. If a genuine grant exists, the document appears in your shared-with-me view or is accessible directly. If it does not appear, the email is suspect regardless of how convincing it looks.
Second, check the sender through a separate channel. Contact the named person using a known phone number or a fresh message thread, not by replying to the email. A one-line confirmation resolves most ambiguity in under a minute.
Third, inspect the link host before any interaction. Hover or copy the URL and confirm the domain matches your tenant's SharePoint host, typically yourorg.sharepoint.com or a configured vanity domain. A link that authenticates through a non-Microsoft domain is a stop sign.
Fourth, consult the audit log if you have access. Sharing events, link creation, and access records resolve the question definitively. If you lack access, your IT or security team can retrieve them within the retention window.
Fifth, report rather than delete suspicious messages. Reporting feeds organizational detection and protects colleagues who received the same campaign.
A useful threshold for action: if two or more red flags are present, stop and verify before any click. A single flag in an otherwise clean message merits a quick sender confirmation but not alarm.
Limitations of what the email can tell you
The notification email is a weak evidentiary artifact. It can be spoofed, forwarded, or rendered misleadingly, and its visible fields do not prove authorization. The authoritative record is the permission grant and the audit log, both of which live outside the message.
Detection also has blind spots. Audit retention windows expire. External sharing policies vary widely across tenants, so behavior that is normal in one organization is a violation in another. Automated and delegated sharing complicates attribution further, because the human who intended the share may never appear in the notification at all.
Finally, no inbox heuristic substitutes for organizational controls. Conditional access, link expiration policies, restrictions on anonymous sharing, and user reporting pipelines reduce exposure far more than individual vigilance. The email answers "who appears to have sent this," and only the permission layer answers "who actually granted access." Treat the two questions as separate, and resolve the second before acting on the first.