Why are my emails not delivering to Outlook and being flagged as phishing?
Published 29 Apr 2025
Updated 19 Oct 2026
13 min read
Summarize with
Updated on 19 Oct 2026: We clarified Outlook phishing diagnostics, DMARC domain matching, and Microsoft false-positive submissions and quarantine release.
Your emails are not delivering to Outlook and are being flagged as phishing because Microsoft sees one or more signals that make the message look unsafe. The most common causes are an SPF or DKIM failure, a DMARC domain mismatch, suspicious links or tracking pixels, a third-party tracking domain with poor shared reputation, a sending IP or domain reputation problem, or a Microsoft 365 tenant rule that quarantines the message.
When Microsoft Defender shows PHISH, do not start by rewriting subject lines. Start with evidence. Check whether the message was rejected, delivered to Junk, held in quarantine, or delivered with a link that Safe Links blocks when clicked. Safe Links rewriting alone is normal protection, not a phishing verdict. Then compare a clean proof against the original, one change at a time. If removing a conversion pixel or redirect repeatedly fixes the proof, investigate that URL and its shared tracking infrastructure.
The fast answer
A phishing verdict identifies a suspected threat in the message, sender identity, or sending environment. If a tracking pixel is highlighted, investigate its URL and redirects before treating the detection as a false positive.
- Inspect the original headers for authentication results and Microsoft verdict fields before changing the message.
- Send the same proof with tracking pixels and tracking redirects removed, keeping the sender and recipients unchanged.
- Restore one tracking element at a time and repeat the comparison to identify a reproducible failure.
Why Outlook flags legitimate emails as phishing
Outlook delivery depends on several filters. Consumer Outlook.com and Microsoft 365 business mailboxes have different filtering and support workflows. In Microsoft 365, authentication checks, URL scanning, spoof detection, and tenant policies affect the result. Microsoft says Outlook shows suspicious indicators when sender identity cannot be verified or differs from the authenticated sender. A question mark or via tag is an identity warning; it does not by itself establish a phishing verdict.
The official Outlook phishing guidance explains the sender identity warnings. For DMARC, at least one passing SPF or DKIM domain must match the visible From domain under the applicable domain-matching rules. Both authenticated domains do not need to match for DMARC to pass.
Microsoft Defender for Office 365 email investigation showing a Phish verdict and tracked URLs.
- Authentication: SPF or DKIM fails, or DMARC fails because neither passing authentication method has a domain that matches the visible From domain.
- URL reputation: Safe Links or content filters dislike a redirect, image host, click tracker, or final landing page.
- Shared tracking: a pixel or link domain is shared with other senders, whose activity can affect that domain's reputation.
- Sender reputation: Outlook sees complaints, new sending infrastructure, rate spikes, bounces, or poor list quality.
- Tenant policy: a Microsoft 365 admin policy, mail flow rule, or allow and block entry changes the verdict.
- Forwarding: an intermediary breaks SPF or changes the message after DKIM signing, which can trigger spoof detection.
|
|
|
|---|---|---|
SPF fail | Headers | Authorize source |
DKIM fail | Headers and signing configuration | Check the selector, public key, and message changes after signing |
DMARC fail | Headers and aggregate reports | Verify that a passing SPF or DKIM domain matches the From domain |
Bad URL | Link evidence | Remove asset |
High BCL | Headers | Reduce complaints |
Common Outlook phishing signals and where to check them.
Check Outlook.com's high-volume sender requirements
Outlook.com enforces extra authentication requirements for domains that send 5,000 or more messages per day to Microsoft consumer addresses using the same visible From domain. The scope includes Outlook.com, Hotmail.com, Live.com, and MSN.com addresses. It does not automatically cover every mailbox hosted by a Microsoft 365 tenant.
If a non-delivery report contains 550 5.7.515, Outlook.com rejected the message because the domain in the visible From address did not meet the required authentication level. This is a hard rejection, not a Junk-folder or phishing-label problem. A DMARC pass alone is insufficient if SPF or DKIM fails: both must pass under these high-volume requirements.
- SPF: publish a valid record and make SPF pass for the Return-Path domain.
- DKIM: publish the public key and make the DKIM signature pass.
- DMARC: publish a valid policy of p=none or stronger, and make DMARC pass because the SPF or DKIM domain matches the visible From domain.
- Third-party senders: configure every service to use an authorized Return-Path and a passing DKIM signature under your domain.
Do not confuse two sender restrictions
Error 550 5.7.515 when sending to Microsoft consumer addresses points to an inbound authentication rejection. If a Microsoft 365 user cannot send to any recipient and the NDR says the user was not recognized as a valid sender, check Restricted users, secure the account, and investigate possible outbound abuse. That is an account restriction, not a DMARC policy failure.
Isolate tracking pixels and redirect URLs
A tiny tracking pixel can cause an otherwise valid email to be filtered because its image source is a URL. Inspect the host, redirects, and final destination in Microsoft's detection evidence. The presence of a tracking pixel alone does not establish why the message was flagged.
A deprecated conversion pixel on a third-party ad or analytics domain is a useful starting point. Shared tracking domains can have reputation problems unrelated to your own sending. A branded tracking domain still depends on its redirect targets and hosting infrastructure, so a custom name is not proof that a URL is safe.
Risky setup
- Shared domain: pixels load through a third-party host used by unrelated senders.
- Long redirect: links bounce through several domains before the real destination appears.
- Old asset: a deprecated product pixel remains in templates after its business use ended.
Cleaner setup
- Owned host: tracking and images use a branded domain controlled by your team, with verified destinations.
- Short path: redirects are minimal and the destination is clear to scanners.
- Current asset: every pixel in the template has a current owner and reason to exist.
Use a pixel isolation test
- Baseline: send a plain version with no tracking, no redirects, and one simple link.
- Restore: add one pixel or redirect back into the email and send the proof again.
- Confirm: repeat the paired test; if restoring the same asset brings back the phishing verdict, remove or repair that asset.
- Retest: send the cleaned production template through the same Outlook inboxes.
Check authentication before changing content
Authentication is the part you can control most cleanly. SPF says which servers can send for the Return-Path domain. DKIM signs the message with a domain. DMARC checks whether SPF or DKIM passed with a domain that matches the visible From domain. If that chain is broken, Outlook has a strong reason to distrust the message before it evaluates the copy. Default relaxed matching accepts domains with the same organizational domain, such as bounce.example.com and example.com. If aspf=s or adkim=s is set, that method requires an exact domain match.
Run a domain health check first, then compare the failing Outlook proof's headers with aggregate reports for the same sending source. Aggregate reports usually arrive daily and group authentication results; they do not identify a specific message's Inbox or quarantine placement. Also check for duplicate SPF records, SPF's 10-DNS-lookup limit, and a passing DKIM signature on the actual message.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
A basic DMARC record with aggregate reporting is enough to start collecting evidence. Do not jump straight to reject if you still have unknown senders or unverified marketing systems. Start with monitoring, fix the legitimate sources, then tighten policy. Replace the sample reporting address with a mailbox or a Suped reporting address configured to receive aggregate reports.
Starter DMARC recordDNS
Name: _dmarc Type: TXT Value: v=DMARC1; p=none; rua=mailto:dmarc@example.com
If DNS changes are slowing the fix, Hosted DMARC in Suped's product lets you change policy after the initial DNS setup. Use the source-level evidence to fix legitimate authentication failures before increasing enforcement.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Read Outlook headers and delivery evidence
Do not rely on the inbox view alone. Get the non-delivery report when there is a rejection, plus the message trace, quarantine reason, and full headers for delivered mail. Verify that an unexpected bounce corresponds to a message you actually sent; fake non-delivery notifications can contain credential-stealing links. In Microsoft 365, useful fields include Authentication-Results, X-Forefront-Antispam-Report, X-MS-Exchange-Organization-RuleID, X-Microsoft-Antispam, SCL, BCL, SFV, CAT, and compauth. Microsoft documents separate handling for spam false positives and phishing or malware false positives in its false positive steps.
Illustrative headers: authentication passes, phishing verdict remainstext
Authentication-Results: mx.example.net; spf=pass smtp.mailfrom=mail.example.com; dkim=pass header.d=example.com; dmarc=pass header.from=example.com; compauth=pass reason=100 X-Forefront-Antispam-Report: SCL:5; SFV:SPM; CAT:PHSH; DIR:INB; X-Microsoft-Antispam: BCL:0;
In this illustrative example, authentication passes but CAT:PHSH identifies a phishing verdict. Read CAT and the Defender detection details together; SCL or SFV:SPM alone does not identify the threat category. BCL belongs in X-Microsoft-Antispam, rather than X-Forefront-Antispam-Report.
For consumer Outlook.com delivery, Microsoft says SmartScreen filtering considers sending IP, domain, authentication, list accuracy, complaint rates, content, and other signals. The Outlook sender guidance also calls out reputable URLs, standard URL formats, SPF records, and avoiding links to known phishing sites. That is why a URL-only change can fix what looks like a mail delivery problem. For self-hosted sending, also verify reverse DNS (PTR) for the sending IP.
|
|
|
|---|---|---|
SCL 5-6 | Spam score | Check CAT and the applied policy |
SCL 7-9 | High confidence spam score | Check CAT before choosing a remedy |
BCL 7-9 | Bulk mail likely to generate complaints | Review consent, complaints, and the tenant BCL threshold |
SFV:SPM | Spam filtering processed the message | Read CAT for the threat category |
SFV:BLK | Sender on the recipient's Blocked Senders list | Ask the recipient to remove a mistaken block |
CAT:PHSH | Phishing | Review detection details and URLs |
CAT:HPHSH or CAT:HPHISH | High confidence phishing | Ask an admin to review quarantine and submit a clean sample |
CAT:UIMP or CAT:DIMP | User or domain impersonation | Review sender identity and the anti-phishing policy |
compauth=fail | Composite authentication failed | Read the reason code and SPF, DKIM, and DMARC results |
Via tag | Visible and authenticated sender identities differ | Inspect headers before diagnosing a phishing verdict |
Evidence mapping for Outlook failures.
If only forwarded or relayed copies fail, inspect the Authentication-Results chain before changing DNS. SPF often breaks at a forwarder, and message modification can break DKIM. A Microsoft 365 admin can review spoof intelligence and configure a trusted ARC sealer for a legitimate intermediary.
Fix authentication, URL, and reputation problems
The fix depends on the recorded detection. Repair confirmed authentication or URL problems. If a legitimate message is incorrectly classified, submit the original sample for review; a passing DMARC result does not guarantee Inbox placement. A tenant allow entry applies only to that organization and the filters associated with the allowed entity.
- Remove bad URLs: delete deprecated pixels, shorten redirect chains, and keep final destinations clean.
- Own your tracking: move links and images to branded domains when your sender setup supports it.
- Fix identity: make SPF and DKIM pass, and make at least one authenticated domain match the visible From domain for DMARC.
- Check reputation: monitor sending IPs and domains for blocklist (blacklist) listings and complaint spikes.
- Reduce complaints: suppress hard bounces, honor unsubscribe requests, and send at a steady volume to recipients who opted in.
- Submit evidence: when the message is clean, submit the false positive through the Microsoft workflow.
Outlook authentication rollout checkpoints
Apply these checks to known legitimate sending sources before increasing Outlook volume.
Ready
100% of known sources
Every known source passes DMARC. High-volume Outlook.com mail also passes both SPF and DKIM.
Investigate
Any known-source failure
A legitimate source has intermittent or consistent authentication failures.
Stop
NDR 550 5.7.515
Outlook.com rejects mail because the From domain misses its authentication requirement.
A clean retest looks like this
Keep the subject, From address, sending source, and proof recipients unchanged when comparing versions. Confirm authentication results and message trace details, then ask the recipient to verify Inbox placement and the absence of a phishing warning. A delivered trace status alone is not proof of Inbox placement.
Submit an Outlook phishing false positive
For Microsoft 365 recipients, follow Microsoft's false positive steps with the receiving tenant's administrator.
- Capture the original message, message ID, UTC timestamp, recipient, and detection details.
- Have an admin submit the message from quarantine or the Defender Submissions page after verifying it is legitimate. Select "I've confirmed it's clean" and request a targeted temporary allow entry when needed.
- Release the verified message from quarantine. Similar messages already in quarantine need separate release; submitting a false positive does not release them automatically.
- Review the submission result, correct any identified tenant configuration issue, and retest before the temporary entry expires.
High confidence phishing needs admin review. Use the submission workflow rather than relying on a Safe Senders entry or a blanket spam-bypass rule.
For consumer Outlook.com or Hotmail rejections, use Outlook sender guidance to reach the consumer support workflow. Provide the complete NDR, sending IP, and timestamps.
Use Suped to monitor the sending side
For a one-off incident, isolate pixels, read headers, and submit a false positive manually. For recurring Outlook failures, Suped's product uses DMARC monitoring to identify sending sources and recurring authentication failures.
Suped shows which sources pass or fail authentication and which sending IPs or domains have public blocklist (blacklist) listings. Use its issue details and alerts to prioritize record fixes. A clean public blacklist result does not establish Microsoft's internal reputation verdict.
A useful Suped workflow
- Verify sources: confirm the sending platform appears as a known, passing source.
- Find failures: open the issue list and review the tailored steps to fix each record.
- Monitor changes: watch authentication results after DNS or sending-platform changes, alongside new Outlook test messages.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Pair Suped's source-level authentication data with Microsoft message trace and Defender URL evidence for the same incident. Aggregate reports do not show Inbox placement or identify which tracking pixel triggered a verdict.
Views from the trenches
Best practices
Pixel audit: remove unused tracking pixels before testing Outlook delivery again in production.
Authentication check: inspect SPF, DKIM, and DMARC before changing copy or cadence.
Owned domains: keep links, images, and redirects on domains you control where practical.
Common pitfalls
Shared URLs: third-party tracking domains can carry reputation damage from other senders.
Internal BCC: archive copies sent to Outlook can hit rate limits and distort diagnosis.
Header gaps: treating Junk placement like rejection hides the actual Microsoft verdict.
Expert tips
Run paired tests: repeat the same message with and without the suspected tracking element.
Use message trace: confirm whether Outlook delivered, junked, quarantined, or rejected.
Stage DMARC policy: verify legitimate sources and complete sending cycles before enforcing.
Expert view
Expert from Email Geeks says a PHISH label on a tracking pixel points to URL reputation or compromise, not ordinary inbox placement.
2021-04-27 - Email Geeks
Marketer view
Marketer from Email Geeks says removing a deprecated conversion pixel restored Outlook proof delivery for their campaign.
2021-04-28 - Email Geeks
Retest Outlook delivery
Retest the cleaned production template with the same sending source and recipient mailboxes after the relevant DNS or tenant policy changes take effect. Test consumer Outlook.com and Microsoft 365 recipients separately. Keep each version's headers, SMTP response or trace details, and confirmed folder placement so recurring failures can be compared against the original incident.
Frequently asked questions
Mailbox providers use different reputation, URL, tenant policy, and authentication models. A URL chain or tracking pixel that passes elsewhere can trigger Microsoft Defender, Safe Links, or Exchange Online Protection.
Yes. A pixel URL or its shared hosting infrastructure can contribute to a phishing verdict. Check the detection evidence and repeat the same proof with and without the pixel before naming it as the cause.
Change policy only after you know the failing source. First check the record with a DMARC checker, then confirm the source passes with an authenticated domain that matches the visible From domain. Do not weaken an enforced policy to compensate for a misconfigured legitimate sender; repair that sender's authentication.
Outlook.com rejected mail from a high-volume From domain because it missed the required authentication level. Check that SPF and DKIM both pass, a valid DMARC record exists, and at least one authenticated domain matches the visible From domain.
Ask for message trace results, quarantine details, full headers, SCL and BCL values, CAT and SFV values, compauth results, mail-flow rule matches, and any tenant allow or block entries that match the sender or URL.
Submit when a verified legitimate message is incorrectly classified, using the original message and its detection evidence. The receiving Microsoft 365 admin can submit it, request a targeted temporary allow entry, and release it. Other quarantined copies still need release, and unrelated filters continue to apply.
