Why are fully authenticated emails marked as 'Unverified Sender' in Outlook/Hotmail?

Published 10 Jun 2025

Updated 19 Oct 2026

14 min read

Summarize with

Unverified Sender warning in Microsoft Outlook on an authenticated email.

Updated on 25 Oct 2026: We clarified Outlook's sender warnings and corrected the header checks for diagnosing authenticated messages.

Outlook and Hotmail show an Unverified Sender indicator when Microsoft cannot authenticate the identity displayed in the From address, or when the authenticated identity differs from that visible address. A standalone SPF or DKIM pass can belong to another domain. A DMARC pass applies to the From domain evaluated at that hop, so confirm the result Microsoft added when receiving the message.

If the final trusted Microsoft headers show that SPF or DKIM passes with a matching domain, DMARC passes, and Composite Authentication passes, check which identity and warning Outlook evaluated. Check for multiple Authentication-Results fields, forwarding or gateway changes, a Sender or on-behalf-of identity that differs from From, tenant policy, and client-specific display behavior. Composite Authentication also uses implicit signals such as sender history. Sender and IP reputation affect Inbox or Junk placement, but a poor reputation score does not by itself prove why Outlook displayed Unverified Sender.

Troubleshooting should separate authentication from placement. DMARC monitoring shows authentication and From-domain matching for reported messages. Inbox placement is a separate delivery outcome. A message can pass DMARC and land in Junk, but the Unverified Sender marker requires its own identity check.

What Outlook's Unverified Sender warning means

Outlook's Unverified Sender marker is an authentication and sender-identity warning. Microsoft explains the sender indicators as a failure to verify the sender through email authentication or a difference between the authenticated identity and the visible From address. SPF or DKIM can pass for an unrelated domain while the displayed From identity remains unverified. Junk placement is a separate filtering outcome.

What the warning really means

Treat Unverified Sender as evidence that Outlook did not confidently connect the authenticated identity to the sender shown to the recipient. Treat Junk placement as a separate filtering outcome.

Check the final Microsoft authentication result, not only an upstream pass.
Compare the SPF and DKIM domains with the visible From domain.
Inspect Sender, Return-Path, forwarding, ARC, and gateway changes.
Diagnose Junk placement separately using reputation and filtering evidence.

This distinction resolves the apparent contradiction. A message can authenticate correctly and still go to Junk because authentication does not guarantee placement. If the same message also shows Unverified Sender, verify that Microsoft's final identity result is truly clean before assigning the warning to reputation or the Outlook interface.

Since May 5, 2025, Microsoft has enforced high-volume sender requirements for domains sending more than 5,000 messages per day to its consumer email services, including Outlook.com and Hotmail. SPF and DKIM must pass, DMARC must be published with at least p=none, and at least one passing method must match the 5322.From domain. Noncompliant messages are subject to rejection with SMTP error 550 5.7.515. That rejection is separate from a warning on a delivered message; compliance does not guarantee inbox placement.

Illustration of Outlook showing Unverified Sender with SPF, DKIM, and DMARC pass results.

Identify the Outlook sender indicator

Record the exact wording or symbol before changing settings. Outlook has separate sender indicators, and each points to a different check.

A question mark in the sender photo means Outlook could not verify the sender through its email authentication checks.
A via tag identifies a difference between the visible From domain and an authenticated sending domain. Check the addresses rather than assuming DMARC failed.
The message "You don't often get email from" is a first contact safety tip. It concerns limited sender history and can appear on authenticated mail.
An External tag identifies mail received from outside the organization. It does not mean authentication failed.

Adding a contact or using Safe Senders does not repair domain authentication. For work or school mailboxes, ask the receiving administrator to review the applicable unauthenticated sender indicator settings. Those tenant controls do not apply to personal Outlook.com or Hotmail accounts, and hiding an indicator does not authenticate the message.

How authentication and Junk placement differ

Use a two-stage model. Stage one asks whether Microsoft can authenticate the identity in the visible From address. Stage two asks whether Microsoft trusts the message enough for the inbox. DMARC answers part of stage one. It does not guarantee inbox placement, and it does not override Microsoft's spam filtering or reputation system. Relaxed DMARC domain matching permits the same organizational domain; strict matching requires identical domains. Reply-To and the part of the address before @ do not determine DMARC domain matching. See the DMARC specification for these matching rules.

Authentication results

SPF pass means the connecting IP is authorized by the envelope sender domain.
DKIM pass means the signed message data validates against the signing domain.
DMARC pass means at least one passing method matches the visible From domain.
CompAuth pass is Microsoft's combined explicit or implicit authentication verdict.

Placement evidence

Record the actual destination folder and any mailbox rules that moved the message.
Investigate source IP reputation when wanted mail repeatedly lands in Junk.
Compare domain history and outcomes across Microsoft recipients.
Review content and sending patterns alongside filtering headers.

An unused IP has no recent positive sending history to demonstrate. If wanted mail repeatedly lands in Junk, investigate IP reputation alongside recipient complaints and sending patterns. Build a sending history with wanted mail and steady volume rather than assuming a parked IP is trusted.

When a warm IP and known domain show an SPF or DKIM domain match, DMARC pass, and CompAuth pass in the final Microsoft result while Outlook still says Unverified Sender, stop assuming DNS or reputation is the direct cause of the marker. Check the client, tenant policies, message routing, and every identity-bearing header.

How to read the Microsoft headers

Start with the delivered message headers from the Outlook or Hotmail mailbox that displayed the warning. In new Outlook or Outlook.com, open More actions > View > View message details. In classic Outlook for Windows, open the message in its own window, then File > Properties > Internet headers. Microsoft's header instructions show these paths. Identify the Authentication-Results field added at Microsoft receipt by tracing the Received chain. Do not choose a field merely because it is first or last; sender-supplied or upstream results are not proof of Microsoft verification.

Illustrative Microsoft authentication and filtering headers

Authentication-Results:
  spf=pass smtp.mailfrom=returns.example.net;
  dkim=pass header.d=example.com;
  dmarc=pass action=none header.from=example.com;
  compauth=pass reason=101

X-Forefront-Antispam-Report:
  SCL:5; SFV:SPM; DIR:INB; CAT:SPM;

X-Microsoft-Antispam: BCL:0;

In this example, DKIM matches the From domain, DMARC passes, and CompAuth passes. SFV:SPM and CAT:SPM indicate spam classification; DIR:INB identifies inbound mail. Confirm the actual delivery action and applicable policy. Microsoft's SCL guidance says SCL alone does not determine spam classification or delivery action in cloud mailboxes. These filtering signals do not establish why an Unverified Sender indicator appeared.

Signal	Meaning	Use in diagnosis
SPF pass	Envelope domain authorized the IP	Compare smtp.mailfrom with From
DKIM pass	Signature validated	Compare header.d with From
DMARC pass	A matching method passed	Confirm header.from
CompAuth pass	Composite authentication passed	Read the reason code
CAT:SPM / SFV:SPM	Spam classification	Check policy and actual folder
SCL:5	Supporting filtering value	Insufficient to prove delivery action
ARC pass	ARC chain validated	Also establish sealer trust

Authentication results identify the evaluated domains; filtering results require policy and delivery context.

Keep the CompAuth reason code with the result. Microsoft documents reason=101 for DKIM signed by the From domain and reason=130 when a trusted ARC result overrides a DMARC failure. A dmarc=bestguesspass result is different from dmarc=pass: it indicates no published DMARC TXT record. See Microsoft's header reference for the field definitions.

The Microsoft Q&A thread shows how broad the consumer-facing symptom is: users see the Unverified label, then answers point to SPF, DKIM, DMARC, sender configuration, and Outlook settings. For senders, the essential step is proving which identity and which hop failed.

Forwarding, gateways, and ARC

Forwarding and intermediary gateways create a major false contradiction. Forwarding changes the connecting IP, so SPF usually fails against the original envelope domain. DKIM can survive if the message stays unchanged, but a gateway that adds a footer, rewrites links, removes an attachment, or edits signed headers can break the signature. DMARC then fails when neither SPF nor DKIM produces a pass with a matching domain.

Authenticated Received Chain (ARC) lets an intermediary seal the authentication results it observed before modifying or forwarding the message. Microsoft can use those preserved results when it trusts the ARC sealer. ARC validation alone does not establish trust or a successful original authentication result. Inspect the ARC instances and the receiving Microsoft CompAuth verdict. Microsoft's trusted ARC guidance explains this distinction. A trusted ARC override does not turn the underlying DMARC failure into a pass or bypass spam filtering.

Intermediary mail-flow checks

Map every forwarding service, inbound gateway, relay, and mailbox rule in the path.
Trace authentication results through the Received chain and compare results before and after each intermediary.
Check whether body or header changes broke DKIM after the first hop.
Verify ARC sealing and trust only for a required intermediary.
Retest with the intermediary bypassed to isolate the cause.

For work or school mailboxes routed through an inbound gateway before Microsoft 365, ask the receiving administrator to review Enhanced Filtering for Connectors. It helps preserve original source information for authentication checks. This is a tenant mail-flow setting, not an Outlook.com or Hotmail recipient setting.

Aliases and send-on-behalf configurations can cause a similar identity split. Confirm which address is the primary sending identity and whether Outlook displays a different From or Sender address. Changing devices or adding the address to contacts does not repair a server-side domain mismatch.

Likely causes when SPF, DKIM, and DMARC appear to pass

When delivered headers appear to show SPF pass, DKIM pass, DMARC pass, and Composite Authentication pass, work through these causes before changing DMARC policy.

A passing Authentication-Results field belongs to an upstream hop while Microsoft's receiving-hop result differs.
A Sender or on-behalf-of configuration differs from the intended From identity. A different Reply-To alone does not fail DMARC.
A relay or gateway changed the message after an earlier successful authentication check.
Forwarding changed the SPF path and no matching DKIM signature survived; check whether trusted ARC preserved usable results.
An alias or send-on-behalf configuration uses an unintended From or Sender address.
The warning appears in only one Outlook client or one recipient tenant despite consistent receiving-hop results.

How to classify the evidence

Use the delivered headers and mailbox outcome together, not one signal alone.

Authentication failure

Trace the failure

A receiving-hop check fails; determine whether DNS, sender configuration, or message routing caused it.

Intermediary issue

Trace the route

Authentication changes after forwarding, relaying, or gateway modification.

Identity mismatch

Check From matching

A passing domain does not match the identity shown to the recipient.

Client or policy issue

Escalate

Final authentication is clean and the warning is limited to one view or tenant.

If multiple Microsoft seed accounts send every message to Junk, investigate IP and domain reputation even when authentication passes. If the Unverified Sender marker repeats on a proven warm route with a clean final Microsoft authentication result, collect evidence for a Microsoft, tenant, or client-side investigation instead of making random DNS changes.

What to check before changing DMARC

Changing p=quarantine to p=none, or p=reject to p=quarantine, does not repair authentication. If the Microsoft receiving-hop result already shows DMARC pass, a policy change does not explain the warning. Verify the sender identity and mail path first, then investigate placement separately.

Get delivered headers from the Outlook or Hotmail mailbox that displayed the warning.
Trace the Received chain to identify Authentication-Results added by Microsoft at receipt.
Check whether a passing SPF or DKIM domain matches the visible From domain under the published matching rules.
Review forwarding, gateways, message changes, and ARC results.
Compare Outlook on the web with another Outlook client using the same delivered message.
Record the exact warning text, folder, UTC timestamp, sending IP, client version, and message ID.

What's your domain score?

Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.

For a focused DNS check, use the DMARC checker to confirm syntax and policy, then the domain health checker to review authentication DNS. A valid DNS record does not prove that a particular message used it successfully. Confirm the delivered authentication results as well.

Basic DMARC record for monitoring

_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:d@example.com"

If a domain has no DMARC record, add monitoring first. The example uses d@example.com as a placeholder: replace it with a working reporting address you control, or the reporting destination supplied by Suped. Replace an existing DMARC record rather than publishing a duplicate. If Microsoft already reports DMARC pass, a policy change alone does not explain the Outlook warning.

Where Suped fits in the workflow

Suped's DMARC reporting product collects aggregate reports across sending sources and domains. Use Suped to find recurring authentication or domain-matching failures, then compare those patterns with the delivered headers of the message that displayed the Outlook warning.

DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records

Where Microsoft reports are available, compare each source IP with the reported SPF, DKIM, and DMARC results to spot routes that fail intermittently. Suped's hosted DMARC supports policy changes without repeated manual DNS edits after the initial setup.

Practical Suped workflow

Detect failing senders and DNS mistakes with automated issue checks.
Compare DMARC results by source in the Microsoft reports received.
Monitor for a route that starts failing authentication or domain matching.
Compare domains and sources before escalating an Outlook-only warning.

Standard DMARC aggregate reports do not include individual Outlook warning labels, CompAuth verdicts, or confirmed Inbox/Junk placement. Reports cover participating receivers and the messages they report. Use Suped to track authentication trends; use delivered headers and recipient observations to investigate the individual warning.

When to escalate an Outlook warning to Microsoft

Escalate when repeated samples show a receiving-hop SPF or DKIM domain match, DMARC pass, and Composite Authentication pass, but Outlook still displays Unverified Sender. Record intermediary changes and compare the same delivered message across clients. A warm IP is useful when investigating placement; positive IP history is not a prerequisite for investigating a contradictory identity warning.

Microsoft documents Composite Authentication as a combination of explicit authentication and implicit signals such as sender history. It also explains that other protection checks can flag messages that pass authentication. A pass narrows the investigation; it does not prove a client defect. For a work or school mailbox, ask the receiving administrator to review the applied policy and message trace before escalating.

Evidence worth collecting

Include full delivered headers, not screenshots only.
Keep Microsoft message IDs and timestamps in UTC.
Show the IP, domain, intermediary, client, and folder outcome.
Compare the same delivered message across clients and use a known working route as a control.

If the evidence points to Composite Authentication behavior, compare the result with Composite Authentication fail. If the evidence points to a basic configuration issue, verify DMARC, DKIM, and SPF before escalating.

How to fix an Unverified Sender warning

The fix depends on which layer is failing. Do not treat every Unverified Sender label as a DNS emergency, and do not use a reputation fix for a proven identity mismatch. Work through the least speculative fixes first.

Investigate receiving-hop authentication failures. For CompAuth, read the reason code before choosing a fix; a failed check is not automatically a DNS fault.
Prevent intermediary changes from breaking DKIM, or configure trust for the required ARC sealer in the receiving tenant.
Use the intended From and Sender addresses and a matching authenticated SPF or DKIM domain. Reply-To does not need to be identical for DMARC.
If Junk placement is the problem, investigate reputation and ramp wanted mail with steady volume.
Compare the same delivered message across Outlook clients and record the exact indicator.
Escalate with repeatable samples, full headers, route details, message IDs, and UTC timestamps.

A costly mistake is rewriting a working DMARC record when the final header already shows DMARC pass through a matching domain. Another is treating the Unverified Sender interface as proof without identifying the authentication result added by Microsoft at receipt. Both create random changes and no reliable before-and-after evidence.

Views from the trenches

Best practices

Separate authentication evidence from inbox placement before changing DNS or sender policy.

Warm unused IPs with wanted mail and stable volume before judging Outlook placement.

Collect final Outlook headers, message IDs, timestamps, IPs, and folder outcomes together.

Use a warm sender as the control sample before escalating a Microsoft display issue.

Common pitfalls

Assuming a parked IP has good reputation after months without normal recipient traffic.

Treating an Unverified Sender label as proof that SPF, DKIM, or DMARC is broken.

Changing DMARC policy when the delivered Microsoft headers already show DMARC pass.

Running only seed tests and missing the real user volume affected by the warning.

Expert tips

Compare cold and warm routes with identical content to isolate reputation from content.

Check whether the warning appears across Outlook clients or only in one interface.

Look for identity drift across From, DKIM, bounce, tracking, and reply domains carefully.

Escalate only after collecting repeatable samples with clean authentication results.

Marketer view

Marketer from Email Geeks says unused IPs can see complete Microsoft junking even when authentication passes, because no recent positive traffic history exists.

2026-01-16 - Email Geeks

Marketer view

Marketer from Email Geeks says a new Outlook sender warning can behave like a client-side rollout issue, so teams should verify impact before spending days on DNS changes.

2026-01-18 - Email Geeks

Frequently asked questions

No. It means Outlook could not confidently verify the displayed sender identity. DMARC failure is one cause, but an unrelated authenticated domain, forwarding, gateway changes, alias behavior, or a client or tenant issue can produce the same symptom.

Yes. DMARC pass confirms an authentication result with a matching domain. Microsoft still applies sender reputation, IP reputation, content, and recipient-history signals before choosing Inbox or Junk.

Yes. Forwarding changes the connecting IP, which usually breaks SPF for the original envelope domain. If DKIM also fails, DMARC fails. A trusted ARC chain can preserve earlier results for Microsoft to use, without changing the underlying DMARC failure into a pass.

Safe Senders is a mailbox preference, not proof that a message passed SPF, DKIM, or DMARC. Adding a contact or marking mail as Not junk does not repair the sender authentication. Ask the sender or domain administrator to inspect the delivered headers.

Changing the DMARC policy does not repair a failed SPF or DKIM check or a domain mismatch. If DMARC already passes at Microsoft receipt, investigate the exact indicator and the message path. Keep enforcement in place while fixing legitimate sending sources.

Collect full delivered headers, Microsoft message IDs, UTC timestamps, sending IPs, visible From and Sender identities, intermediary details, client names, and mailbox outcomes across repeated tests.

Why are fully authenticated emails marked as 'Unverified Sender' in Outlook/Hotmail?