How do subdomains affect root domain reputation and how can I fix Microsoft O365 Outlook SCL:5 spam filtering issues?
Updated on 10 Oct 2026: We updated our SCL:5 troubleshooting advice and subdomain authentication checks.
Subdomains can affect root domain reputation, but receivers do not use one universally shared score. Microsoft, Gmail, and other receivers build reputation across related identifiers such as the visible From domain, organizational domain, DKIM signing domain, envelope sender domain, sending IPs, URL domains, and recipient responses. A marketing or outreach subdomain can damage trust associated with the parent domain when these identifiers and sending patterns overlap.
In Microsoft 365, SCL:5 alone does not establish the filtering verdict or delivery action. Check CAT and DIR alongside tenant evidence. SPF, DKIM, and DMARC passing does not override reputation, content, URL, bulk, or tenant policy signals. Microsoft explains the score limits in its SCL documentation and policy outcomes in its anti-spam FAQ. The practical investigation starts with message evidence, sender cleanup, a recipient-admin false-positive submission, and support escalation when the verdict persists.
A high Google reputation result does not prove that Microsoft should inbox the same mail. Google reputation reflects Google-side traffic. Microsoft builds separate history, and Microsoft 365 tenants can apply policies or overrides beyond the service defaults.
Fast answer
- Subdomains can influence root domain reputation when receivers connect behavior across related sending identities.
- SCL:5 alone does not prove a spam verdict, an authentication failure, or a delivery block.
- Gather headers, identify the exact Microsoft category or override, pause risky sending, and submit a clean sample for review.
What SCL:5 means in Outlook
Finding a message in Junk Email confirms its delivery location. To identify the cause, inspect the threat category (CAT), direction (DIR), filtering verdict (SFV), and applicable tenant policy. SCL remains useful for on-premises Exchange and hybrid delivery, but it is insufficient for diagnosing a Microsoft 365 cloud verdict.
|
|
|
|---|---|---|
SCL:-1 | Spam bypass request | Other protection still applies |
CAT:SPM | Spam | Junk under Default or Standard; quarantine under Strict |
CAT:HSPM | High confidence spam | Junk under Default; quarantine under Standard or Strict |
CAT:BULK | Bulk filtering | Junk or quarantine when the configured BCL threshold is met |
Microsoft 365 delivery actions depend on the verdict and effective policy; SCL alone does not determine them.
A consistent SCL:5 across separate SMTP paths warrants comparison of the actual categories and policy actions. If those also match, investigate shared domain or URL reputation, repeated content, and recipient overrides. The O365 SCL variance breakdown covers cases where the same message receives different results across Microsoft 365 tenants.
Microsoft Defender for Office 365 message details showing SCL 5 and Junk Email delivery.
How subdomains affect root domain reputation
Subdomains are not perfectly isolated. A receiver can build history for mail.example.com while still connecting it to example.com. The connection becomes stronger when mail shares the same DKIM signing domain, return-path domain, website links, brand identity, recipient lists, or sending behavior. A separate subdomain helps segment operations, but it does not create a guaranteed reputation firewall.
Root domain and subdomain reputation connected through DKIM domains, sending IPs, and email link domains.
Separate sending identities
- Different From domain: Marketing uses news.example.com, while staff mail uses example.com.
- Aligned DKIM domain: Each stream signs with its own aligned domain rather than one shared parent domain.
- Separate links: Campaign links do not reuse the tracking host used by corporate mail.
More shared risk
- Same organization: Receivers can connect repeated complaints to the organizational domain.
- Shared DKIM domain: Bulk and staff mail signed with example.com share a signing identity that receivers can evaluate together.
- Same links: Poor URL reputation follows shared hosts into otherwise clean messages.
SPF is evaluated at the MAIL FROM domain, with HELO used for an empty reverse path; a parent SPF record does not automatically cover a subdomain. Publish authorization at each domain used for those identities, as defined in RFC 7208. DKIM keys are selected using the signing domain (d=) and selector (s=), as defined in RFC 6376. Changing only the selector keeps the same signing domain. Changing a return-path subdomain also leaves the visible From domain unchanged.
DMARC inheritance exampledns
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; sp=reject" _dmarc.news.example.com. TXT "v=DMARC1; p=quarantine"
DMARC policy inheritance and reputation correlation are separate concepts. In this example, example.com requests quarantine for DMARC failures. Existing subdomains without their own applicable record use sp=reject. The specific record at _dmarc.news.example.com takes precedence for news.example.com, which requests quarantine instead. Without an applicable sp or np tag, the inherited policy uses p. Neither policy makes the subdomain's reputation independent.
RFC 9989 defines a DNS Tree Walk for fallback DMARC policy discovery, replacing the earlier public-suffix-list method. It also defines np for nonexistent subdomains. Check receiver authentication results and aggregate reports when changing nested policies; the standard's publication does not establish which discovery method a receiver has implemented.
Root and subdomain authentication should therefore be monitored together. Suped's DMARC monitoring keeps marketing, transactional, and corporate sender sources visible in one reporting workflow while preserving their domain-level differences.
Checks to run before contacting Microsoft
Collect enough evidence to show whether the issue follows the domain, one sending IP, one message template, or one recipient tenant. Run a live test through Suped's email tester, then compare the result with an affected recipient's mailbox. Distinguish consumer Outlook.com or Hotmail accounts from Microsoft 365 work or school mailboxes. Outlook is also a mail client, so its name alone does not identify the receiving service. The tenant-admin workflow below applies to Microsoft 365.
- Headers: Capture the full raw headers, including Authentication-Results, X-Forefront-Antispam-Report (CAT, DIR, SCL, and SFV), X-Microsoft-Antispam (BCL), and Microsoft mailbox-delivery fields.
- Authentication: Confirm SPF and DKIM results, DMARC alignment with the visible From domain, and composite authentication when present.
- Infrastructure: Verify forward DNS, PTR or reverse DNS, and consistent HELO or EHLO and MAIL FROM identities for infrastructure under your control.
- Content and links: Compare the real message with a short plain-text test, then test optional tracking, redirect, calendar, attachment, and signature elements one at a time. Keep working unsubscribe controls in production marketing mail.
- Sending behavior: Check for volume spikes, weak consent, stale recipients, unprocessed hard bounces, and complaint-heavy campaigns.
- Blocklists: Review IP and domain blocklist (blacklist) status, including related sending and link hosts.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
For DNS and domain-level checks, use Suped's domain health check to find broken SPF, DKIM, DMARC, rDNS, and sender identity settings. Keep blocklist monitoring active because a blacklist event can coincide with sudden Microsoft filtering even when authentication still passes. A clean public blocklist result does not establish Microsoft's internal reputation assessment.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Trace the verdict inside Microsoft 365
A recipient's Microsoft 365 administrator can see evidence that an external sender cannot. Message trace confirms the delivery path. Where the tenant has the required Defender for Office 365 license and permissions, Threat Explorer or Real-time detections and email entity details add detection and override evidence. Compare original and latest delivery locations to check for a later service or admin move, including zero-hour auto purge (ZAP). If the service shows Inbox delivery while the recipient sees Junk, inspect mailbox and client rules too. Microsoft's Defender detection documentation describes the available evidence.
|
|
|
|---|---|---|
Headers | SCL, CAT, DIR, BCL, SFV, compauth | Spam, bulk, authentication, blocked sender, or transport rule signals |
Message trace | Delivery events and mail flow rule processing | How the service handled the message at delivery |
Email entity | Detection technology, policy, override, original and latest location | The filter or tenant setting associated with the verdict |
Recipient policy | Preset policy, custom policy, allow or block entry | Why recipients in different tenants get different outcomes |
Microsoft evidence that narrows an SCL:5 investigation.
Use the documented fields rather than guessing at internal diagnostic codes. CAT:SPM indicates spam; CAT:HSPM indicates high confidence spam. SFV:SKS identifies an honored spam decision set by a mail flow rule or on-premises Exchange, while SFV:SKB indicates an anti-spam policy block and SFV:BLK indicates a user's Blocked Senders entry. CAT:BULK or SRV:BULK directs the investigation toward bulk filtering. Microsoft's header reference explains these values.
- Find the message: Use Message trace to confirm the delivery path, then inspect Defender detection and delivery details where available.
- Check overrides: Review the Tenant Allow/Block List, mail flow rules, anti-spam policies, and the user's Blocked Senders list.
- Separate bulk from spam: Compare the message BCL with the effective bulk threshold. Default and new custom policies use 7 by default, Standard uses 6, and Strict uses 5. BCL is a filtering score, not a measured complaint percentage.
- Submit the false positive: The recipient admin should submit the original message as clean through the Microsoft Defender Submissions page.
- Escalate persistent cases: Open a Microsoft 365 admin support case with the submission result, message IDs, timestamps, headers, and trace evidence.
A message that meets or exceeds the configured threshold takes the policy's bulk action. If Bulk moves enabled is on, bulk mail below that threshold can instead go to Outlook's Promotions folder. That placement is separate from Junk Email. Microsoft documents both behaviors in its bulk filtering guidance.
Treat allow entries as temporary containment
A narrow allow entry can restore a known sender while Microsoft reviews a false positive, but broad domain allowlisting weakens protection and can hide the cause. Fix authentication, content, infrastructure, or policy issues first, and remove temporary overrides when they are no longer needed.
Why an allowlist does not fix SCL:5
An allowlist entry only helps when it matches the message and applies to the affected recipient. Adding a parent domain or requesting SCL:-1 does not establish that filtering was bypassed. Check the effective policy and override evidence before adding more exceptions.
- Check the visible From address, including its full subdomain. Anti-spam allowed sender and domain lists inspect this address, not the MAIL FROM return path. For sender@news.example.com, inspect news.example.com rather than assuming an entry for a different identity matched.
- Confirm policy priority. Strict and Standard preset policies take precedence over custom policies, and custom policies take precedence over Default. Only the first matching anti-spam policy applies, so an allow entry added to Default does not change a recipient's preset policy.
- Check the allowlist method. Outlook Safe Senders applies to one mailbox; its domain entries are not honored when the policy action is quarantine. An organizational allow entry and a mailbox Safe Senders entry have different behavior.
- For a mail flow rule, inspect its conditions, exceptions, priority, and trace result. A spam-bypass request does not disable malware or high confidence phishing protection. Submit the false positive for review instead of using a broad sender-domain bypass.
Microsoft's allowlist guidance describes sender matching and protection limits. Its anti-spam policy documentation explains policy precedence. Use a targeted admin submission for temporary relief and verify that subsequent messages show the expected handling.
How to repair subdomain reputation and Outlook filtering
Repair work depends on the evidence. If the same root domain reaches Junk Email through multiple SMTP paths, domain-associated signals deserve closer attention, but content, URL, and tenant policy tests still need to be ruled out.
- Map streams: List corporate, marketing, transactional, sales, and support mail by From domain, DKIM domain, return path, link domain, and provider.
- Pause risk: Stop cold outreach, scraped-list campaigns, and mail with weak consent while reputation recovers.
- Separate signing: Use distinct DKIM signing domains that satisfy DMARC alignment with each stream's From domain. Separate selectors help key management, but changing selectors alone does not separate the signing identity.
- Clean links: Remove unnecessary redirect chains and retire tracking hosts associated with poor engagement or abuse.
- Stabilize volume: Send wanted mail at consistent levels, suppress hard bounces promptly, and avoid sudden spikes.
- Use real feedback: Known recipients can mark valid mail as not junk or reply after confirming the sender relationship.
Do not use warm-up networks
Warm-up services create artificial engagement patterns and can make a reputation problem harder to unwind. Recovery should rely on consent-based mail, clear segmentation, controlled volume, low complaints, and genuine recipient interaction.
If Outlook junk placement continues after authentication, policy, and content checks, compare the pattern with Outlook junk placement cases where authentication passes but the detected category still causes spam filtering. Reputation recovery has no guaranteed timetable. Track delivery results across affected Microsoft tenants while maintaining wanted mail and low complaints; rotating through new subdomains does not remove shared domain or URL signals.
How to submit and escalate a false positive
The best first submission comes from an affected recipient's Microsoft 365 administrator because that admin can provide the original message and Microsoft-side evidence. On the Submissions page, submit the Network Message ID or upload the original .eml or .msg file, select an affected recipient, and choose "I've confirmed it's clean" after verifying the message. If the result does not resolve the issue, open an admin support case with the submission ID and filtering evidence. Microsoft documents the procedure in its admin submission instructions. There is no documented guaranteed domain reputation reset for SCL:5.
Microsoft escalation wording
Subject: Microsoft 365 SCL:5 false-positive review Hello Microsoft support, Legitimate messages from example.com to Microsoft 365 recipients are being delivered to Junk Email with SCL:5. The original messages were submitted as clean through the Microsoft Defender Submissions page. Please review the filtering category and the applicable policy or override. The submission IDs and results, full headers (including CAT, DIR, SFV, BCL, and actual authentication results), message trace, sending IPs, timestamps, affected recipients, and Network Message IDs are attached. Please identify the detection responsible for the action and advise on corrective steps for these messages.
A direct request for false-positive analysis is more accurate than an IP delisting request when the message was accepted and placed in Junk Email. Similar symptoms appear in this Microsoft community SCL=5 case, but a community thread does not provide a formal root-cause analysis for another tenant.
Evidence to attach
- Headers: Full raw headers from at least two affected messages sent on different days.
- Identifiers: Network message IDs, timestamps, sender addresses, recipient domains, and sending IPs.
- Microsoft evidence: Submission IDs and results, message trace, available email entity details, and the detection category, policy, or override shown.
- Comparison tests: Results across different SMTP paths, templates, URLs, recipients, or Microsoft 365 tenants.
Monitor root and subdomain authentication with Suped
Suped is our DMARC reporting and email authentication platform. For an SCL:5 investigation, it can inventory sender sources, show SPF and DKIM alignment across root domains and subdomains, surface authentication changes, and keep blocklist (blacklist) events alongside the sender review. Microsoft-side headers and tenant evidence are still required to identify Microsoft's filtering category and policy action.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
A practical Suped workflow is to map every sending source, compare DMARC pass and alignment rates by subdomain, investigate new or failing sources, and alert the owners responsible for each stream. Hosted DMARC can support policy staging, while Hosted SPF and SPF flattening can help manage SPF records that are approaching the DNS lookup limit.
For MSPs and teams with many brands or subdomains, Suped's multi-tenant view keeps corporate, marketing, and transactional mail visible without treating every stream as the same sender.
Practitioner tips for Microsoft filtering
Best practices
Separate corporate, marketing, and transactional mail with clear domains and matching DKIM.
Collect CAT, DIR, SFV, and full headers so support can distinguish policies from filtering.
Pause risky outreach while repairing reputation, since new complaints slow recovery.
Common pitfalls
Treating Google reputation as proof of Microsoft trust leads to slow troubleshooting.
Changing SMTP paths without testing shared domains and URLs misses other filtering causes.
Using warm-up networks adds artificial engagement and risks worse filtering later.
Expert tips
Ask the recipient admin to submit a false positive with trace and message evidence.
Have trusted recipients move valid mail out of junk after confirming the relationship.
Track root and subdomain authentication together to catch failures in shared sending sources.
Marketer view
Marketer from Email Geeks says Google reputation data does not explain Microsoft delivery because each receiver builds its own domain and IP history.
2024-11-20 - Email Geeks
Marketer view
Marketer from Email Geeks says repeated Microsoft replies work better when the request explicitly asks for escalation and includes message evidence.
2024-11-21 - Email Geeks
