What to do when Microsoft is confused about automated alerts from your domain?
Updated on 15 Oct 2026: We corrected the alert sender examples and clarified Outlook warnings, authentication requirements, and Microsoft review steps.
If Microsoft flags automated alerts from your domain, start by identifying the warning or rejection. Treat it as four checks: prove the alert is real, prove the sending source is authorized, remove message patterns that look risky, and then handle the Microsoft-side action with evidence. Microsoft will not trust an alert just because the visible From address uses your domain.
The exact response depends on where the confusion appears. A Defender-generated notification, a Microsoft 365 quarantine, an Outlook warning, and an SMTP bounce come from different systems. Start with the original message and headers, not a screenshot, because the evidence identifies an authentication failure, a filtering verdict, a reputation problem, or a tenant policy action.
- Capture evidence: Save the full headers, message ID, sending IP, envelope sender, DKIM selector, and any Microsoft bounce or quarantine reason.
- Test authentication: Confirm SPF, DKIM, DMARC, and Microsoft's composite authentication result on the real alert, not on a hand-built test email.
- Separate traffic: Use a dedicated alert subdomain when it helps separate authentication settings, ownership, and reporting.
- Escalate last: Submit or support-escalate a false positive only after authentication and content have been cleaned up.
Confirm what Microsoft is reacting to
The first mistake is treating Microsoft confusion as one failure. It can be a Defender notification created by an alert policy, a quarantine action inside a Microsoft 365 tenant, an Outlook.com reputation decision, an SMTP rejection, or a warning shown to a recipient. Each one needs a different first move.
|
|
|
|---|---|---|
Defender notification | Alert policy activity | Open the alert record |
Defender quarantine | Filter, policy, or override | Open the email entity |
SMTP bounce | Authentication, configuration, policy, or reputation | Save the exact code |
Outlook identity warning | Sender verification or first-contact safety tip | Read the exact notice, then compare domains |
Junk placement | Mixed filtering signals | Test live mail |
Autodiscover certificate warning | Client connection or certificate mismatch | Check the endpoint and certificate |
Use the Microsoft signal to decide where to start.
For Microsoft 365 tenant issues, ask the recipient admin for the quarantine verdict, message trace, email entity details, and the policy or override that acted on the message. For Outlook.com filtering or an SMTP rejection, collect the full response code and final delivery status. Save complete headers if a copy was delivered to Microsoft; a rejected message has no recipient copy to inspect. A phone screenshot gives context, but it does not show what failed.
Microsoft Defender alert policies with notification recipients and trigger settings.
A Defender alert-policy notification reports activity in the tenant. It is different from a message that Defender quarantined. In Email & collaboration > Policies & rules > Alert policy, check that notifications are enabled, the recipient list is correct, and the daily notification limit has not been reached. New or changed policies take up to 24 hours to sync. Unusual-activity triggers need up to seven days to establish a baseline, during which they do not generate alerts. Aggregation can combine matching events into one alert, and role permissions determine which alerts an admin can see. See Microsoft's alert policy documentation.
If the warning appears when Outlook opens and mentions Autodiscover or a certificate name mismatch, ask the messaging administrator to check the connection endpoint and certificate using Microsoft's Autodiscover documentation. SPF and DMARC changes do not repair that connection error. For an unusual-sign-in email, open the Microsoft account activity page directly and verify the event before using any links in the message. Microsoft explains this in its Recent activity guidance.
Interpret Outlook sender warnings
Record the exact warning text before changing a policy. Outlook sender indicators describe different conditions, and a delivered alert with a safety tip is different from a rejected or quarantined message.
|
|
|
|---|---|---|
Question mark beside the sender | The sender was not verified by the authentication checks used for this indicator. | Inspect Microsoft's SPF, DKIM, DMARC, and compauth results. |
"via" beside the sender | The From domain differs from the DKIM signing domain or envelope sender domain. | Check the alert platform's custom DKIM and return-path configuration. |
"You don't often get email from" | The recipient has little or no message history with this sender. | Verify the expected alert; this tip alone does not show an authentication failure. |
External sender label | The message is identified as originating outside the organization. | Check the tenant's external-sender tagging configuration. |
Match the Outlook notice to the right investigation.
A "via" tag alone does not establish that an alert is malicious. Fix authentication where it fails, but keep first-contact and external-sender notices separate from spoofing verdicts. Microsoft documents these distinctions in its anti-phishing policy guidance.
Prove the alert is really yours
Before changing DNS or asking Microsoft to review anything, verify the automated alert is actually coming through the approved path. That means using a real generated alert, sent by the same system, with the same template, envelope sender, links, and attachments or no attachments.
Illustrative recipient header evidence
Authentication-Results: mx.receiver.example; spf=pass smtp.mailfrom=bounces.alerts.example.com; dkim=pass header.d=alerts.example.com; dmarc=pass header.from=alerts.example.com; compauth=pass reason=101 Received-SPF: pass Return-Path: <bounce-id@bounces.alerts.example.com>
Send one live alert to Suped's email tester to inspect its authentication results, then compare those results with the copy delivered to the affected Microsoft recipient. A test inbox does not reproduce the recipient tenant's filtering decision. Use the domain health check for DNS checks, and verify the DKIM selector shown in the real alert.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
The key is testing the live path. A manually forwarded sample changes headers. A copied template sent through a different mailbox changes the sending source. A test message without the alert links and alert wording does not prove how Microsoft sees the production message. If a gateway or forwarder sits in the path, inspect the ARC results and whether an intermediary modified the signed message. ARC depends on receiver trust in the intermediary; an ARC pass alone does not guarantee acceptance. In Microsoft's X-Forefront-Antispam-Report header, capture SCL (spam confidence level), SFV (filtering verdict), and CAT (threat category). Read compauth with its reason code: 000 indicates an explicit authentication failure, while 001 indicates an implicit authentication failure. See Microsoft's header reference.
What good evidence contains
- Original headers: Use the final recipient copy, not a forwarded copy or a screenshot of the message.
- Exact sender: Record the visible From domain, envelope domain, DKIM signing domain, and sending IP.
- Microsoft result: Save the bounce text, filtering verdict, quarantine reason, or alert-policy name.
- Timing data: Keep the send time, delivery attempt time, and any spike in Microsoft-only failures.
Fix authentication before asking Microsoft to trust it
Authentication is the baseline. Microsoft can distrust an alert that uses your visible domain while the envelope sender belongs to a vendor, DKIM signs with a different domain, or DMARC fails because neither authenticated identifier matches the From domain. DMARC passes when SPF or DKIM passes with the required domain match. The default relaxed setting permits related subdomains under the same organizational domain; strict mode requires an exact domain match. Microsoft's compauth result adds other evidence to those protocol results, so read it beside SPF, DKIM, DMARC, and ARC. A compauth failure alone does not automatically block a message.
Illustrative DNS records, replace provider values before usedns
bounces.alerts.example.com. IN TXT "v=spf1 include:_spf.sender.example -all" selector1._domainkey.alerts.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..." _dmarc.alerts.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@alerts.example.com"
Publish SPF at the envelope sender domain, bounces.alerts.example.com in this example. Keep one SPF record per hostname and stay within SPF's limit of 10 DNS-querying terms, including nested includes. The provider hostname and truncated DKIM key above are placeholders; use the actual records supplied by the alert platform. Use quarantine only after reports confirm legitimate sources pass DMARC, and configure a working aggregate-report destination.
Weak setup
- Root overload: Every automated sender is added to the root SPF record.
- Vendor DKIM: The DKIM domain belongs to the sender, not your alert subdomain.
- Loose ownership: No one knows which team owns the alert stream or DNS changes.
Stronger setup
- Dedicated domain: Automated alerts use a specific subdomain with clear purpose.
- Your DKIM: The alert source signs with a DKIM domain under your control.
- Tracked policy: DMARC reports show which sources pass, fail, and change over time.
Suped's DMARC monitoring groups aggregate report data by sending source and shows authentication failures. Review unfamiliar sources with the alert owner before deciding whether they are authorized. This helps confirm that the alert platform uses the expected domain and infrastructure; aggregate reports do not establish a recipient's inbox placement or the exact tenant policy that acted on an individual message.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Do not lower a DMARC policy just to get past one Microsoft warning. If the alert stream fails DMARC, fix the stream. If it passes DMARC and Microsoft still flags it, check the remaining authentication requirements before investigating message content and reputation.
Check Outlook.com high-volume requirements
For domains sending 5,000 or more messages per day to Microsoft consumer mailboxes, Outlook.com requires both SPF and DKIM to pass, plus a published DMARC policy of at least p=none and a DMARC pass. A DMARC pass through DKIM alone does not excuse an SPF failure under this requirement. Error 550 5.7.515 indicates that the sender domain does not meet the required authentication level. This is separate from a Microsoft 365 tenant policy. See Microsoft's 5.7.515 guidance.
Consider a dedicated alert subdomain
A dedicated subdomain can separate automated alerts from human mail and marketing mail when those streams have different owners or authentication settings. It gives you a clearer reporting boundary and a place to stage DMARC policy. It is optional, and Microsoft does not guarantee separate reputation for each subdomain.
Clean alert identity model
Visible From: alerts@alerts.example.com Envelope From: bounce@bounces.alerts.example.com DKIM d=: alerts.example.com DMARC record: _dmarc.alerts.example.com Owner: security operations
|
|
|
|---|---|---|
Alerts | alerts | Operational |
Receipts | receipts | Transactional |
Human | mail | People |
Marketing | news | Campaigns |
Keep sender identities simple and stable.
The subdomain makes alert-source changes easier to identify in DMARC reports. If an alert vendor changes infrastructure or sends a broken template, compare that stream with normal business mail. A subdomain does not isolate problems on a shared sending IP or guarantee that root-domain reputation is unaffected.
Subdomain rule of thumb
Use a stable subdomain for an alert stream when it improves ownership and reporting. Configure the visible From domain, envelope domain, and DKIM signing domain to satisfy your DMARC matching settings. Then monitor the subdomain until legitimate sources consistently pass.
Reduce Microsoft risk signals in the message
Once authentication passes, review the content. Automated alerts often contain patterns Microsoft filters watch closely: urgent security wording, account names, links to dashboards, raw IP addresses, tracking URLs, and login prompts. Legitimate alerts can look hostile when they lack context.
- Brand context: Include the product, tenant or account, and the specific event that triggered the alert.
- Link hygiene: Use stable branded hostnames and avoid shorteners, raw IP links, and surprise redirects.
- Recipient context: Tell the recipient why they are getting the alert and who owns the system.
- Volume control: Suppress duplicate alerts, dead recipients, role accounts that bounce, and old test users.
- Complaint handling: Give non-critical alert recipients a preference route instead of forcing every notification.
Microsoft automated email alert troubleshooting flowchart covering headers, authentication, reputation, and escalation.
If the symptom is a Microsoft block or repeated bounce, the same evidence still matters. The deeper process is covered in Microsoft blocks automated emails, but the short version is simple: do not ask Microsoft to ignore a message that still has authentication gaps, unstable sender identity, or weak recipient targeting.
Handle Defender quarantines without broad allow rules
When Microsoft Defender for Office 365 quarantines an automated alert inside a tenant, the recipient admin can investigate the decision. Collect the email entity, detection technology, policy name, override details, quarantine reason, and original headers. Then separate a sender problem from a tenant rule or override that is too broad.
Avoid broad allow rules
A broad domain allow can hide a compromised sender, a broken vendor integration, or a real spoofing attempt. Use narrow handling that matches the authenticated sender, expected headers, known recipient group, and specific alert stream.
Risky handling
- Domain allow: A domain-wide exception skips the checks covered by that allow mechanism for every matching sender.
- No expiry: The exception remains after the alert source changes.
- No owner: No one reviews whether the exception still matches reality.
Safer handling
- Scoped entry: The entry covers the specific sender or entity that caused the verdict.
- Review date: The exception has a ticket, owner, and planned review.
- Authentication check: The expected domain must still pass the required authentication checks.
If Microsoft 365 shows conflicting SPF or DKIM results, validate the path before blaming the recipient rule. The same pattern appears in Office 365 authentication failures: one hop, one forwarder, or one missing DKIM selector can turn a trusted alert into a suspicious message.
Submit legitimate mail for Microsoft review
After the recipient admin confirms a false positive, use Actions & submissions > Submissions in the Microsoft Defender portal. Submit the original message by network message ID or upload the .eml or .msg file, then select a recipient who experienced the problem. Microsoft uses that recipient to check whether a user policy, organization policy, or override affected delivery. The network message ID is available in X-MS-Exchange-Organization-Network-Message-Id or X-MS-Office365-Filtering-Correlation-Id.
- Locate the original item in quarantine, message trace, Threat Explorer, or the recipient mailbox and record its network message ID.
- Submit the email for analysis and choose "I've confirmed it's clean" only after validating the sender, URLs, and attachments.
- Record Microsoft's result and the policy check. A filtering error needs Microsoft review, while an organization policy or override needs a tenant-side correction.
- If delivery is urgent, review the specific allow entry created for the detected entity, assign an owner, and record its removal date. Spoofed-sender entries do not expire automatically, so schedule their removal explicitly.
Keep the submission path scoped
An allow entry can skip filters associated with the allowed sender, domain, URL, or file; other message elements are still evaluated. Domain or user impersonation false positives need review of the anti-phishing policy's Trusted senders and domains settings. Do not assume every false-positive submission creates a temporary Tenant Allow/Block List entry. See Microsoft's submission guidance.
This admin-submission path applies to mail handled inside a Microsoft 365 organization. An Outlook.com or Hotmail rejection can concern authentication, sender reputation, or another delivery policy. Preserve the exact SMTP response, identify the affected sending IP, and follow the Microsoft route named in the rejection rather than asking a recipient admin to change tenant policy.
Track reputation and blacklist status
Passing DMARC does not guarantee inbox placement at Microsoft. Automated alerts can still suffer when the sending IP has a weak reputation, recipients complain, or old addresses bounce repeatedly. Isolate Microsoft-only failures because global averages hide receiver-specific behavior.
Check relevant blocklist (blacklist) results when the bounce identifies a reputation problem. A clean public blacklist result does not establish a clean Microsoft reputation, because Microsoft also uses its own filtering signals. Suped's blocklist monitoring helps track public listing changes alongside authentication investigations; use the exact Microsoft response to decide the remediation path.
Microsoft alert escalation states
Use the evidence state to choose the next action.
Healthy
Monitor
The live alert passes authentication and Microsoft accepts it at the normal baseline.
Investigate
Find the change
A sender, selector, template, link host, or recipient pattern changed before failures began.
Escalate
Submit evidence
Microsoft repeatedly rejects or quarantines alerts after sender-side checks pass, or a sender warning conflicts with the authentication evidence.
Prepare the Microsoft escalation packet
If everything passes and Microsoft still rejects or quarantines the alert, escalate with a compact packet of evidence. Include original Microsoft-recipient headers when available, the network message ID, sending IPs, DNS records, affected recipients, timestamps with time zones, exact SMTP responses, and quarantine or policy details. State why the alert is expected mail, which approved system sends it, and which sender-side changes were tested.
