Quick answer: When a business has a Microsoft 365 email incident, IT Support should follow five steps: define impact scope, check Microsoft 365 service health, check email DNS, isolate user/device issues, review account security and record evidence after resolution. Reinstalling Outlook first is not enough because many incidents come from tenant, DNS, MFA, licensing or compromised accounts.
Where should Microsoft 365 email incident support start?
Start with scope: one user, one team or the whole company? If many users are affected, check Microsoft 365 service health, DNS/MX, domain, connector and tenant security first. If only one user is affected, check license, password/MFA, mailbox, Outlook profile, device and network.
This work should be handled through IT Helpdesk and IT Support, not scattered personal chat messages.
Why email incidents need a process
Email supports sales, accounting, purchasing, recruitment and customer service. A small issue such as wrong SPF, full mailbox, MFA failure or suspicious forwarding can lose quotations, delay orders or leak data. If IT only rebuilds Outlook without checking tenant and DNS, the incident may repeat or hide a security risk.
Microsoft Support guidance for send/receive issues highlights error messages, connectivity, Outlook behavior and administrator involvement for business mail systems. For Microsoft 365 business, administrators may also need to review service health and open support requests from the admin center.
Email incident priority table
| Priority | Example | Target response | First action |
|---|---|---|---|
| P1 – Company-wide outage | Many users cannot send/receive, MX/DNS issue, tenant incident, critical mailbox down | 15-30 minutes | Check service health, DNS, queue, tenant and send/receive tests |
| P2 – Team impact | A group cannot receive email, messages go to spam, Outlook breaks after password/MFA change | 30-60 minutes | Scope users/groups, rules, licenses, app password and Outlook profile |
| P3 – Single user | One user Outlook issue, full mailbox, mobile sync issue, delegate/signature problem | 2-4 business hours | Remote ticket handling and root-cause notes |
| P4 – Change/request | Alias, group, forwarding, signature, user guidance | 1 business day | Schedule to reduce disruption |
Technical checklist for Microsoft 365 email issues
| Check area | What to review | Goal |
|---|---|---|
| Service health | Microsoft 365 Admin Center, Exchange Online incident status | Separate platform incident from internal issue |
| Email DNS | MX, SPF, DKIM, DMARC, autodiscover | Avoid delivery loss or spam classification |
| User/license | License, mailbox size, login state, MFA | Separate user issue from system issue |
| Client/device | Outlook profile, cache, mobile app, add-ins, network | Resolve device-specific problems |
| Security | Sign-in logs, suspicious rules, forwarding, compromised account | Detect account takeover |
Common symptoms and isolation path
| Symptom | Likely cause | Priority |
|---|---|---|
| Company cannot send/receive | DNS/MX, tenant/service health, expired domain, connector | P1 |
| Email bounces or lands in spam | SPF/DKIM/DMARC, reputation, content, IP/domain | P2 |
| Outlook fails but webmail works | Profile, cache, add-in, credential, workstation network | P3 |
| One user cannot sign in | Password, MFA, license, disabled account, conditional access | P2/P3 |
| Email forwards outside unexpectedly | Suspicious rule, compromised account, audit log | P1/P2 |
Evidence to keep after resolution
| Evidence | What to keep | Why it matters |
|---|---|---|
| Error/NDR screenshot | Error code, time, sender/recipient | Reads the right root cause |
| Send/receive tests | Internal, outbound, inbound, multiple domains | Shows incident scope |
| DNS snapshot | MX/SPF/DKIM/DMARC before and after fix | Avoids wrong changes and supports rollback |
| Sign-in log | IP, country, device, MFA, suspicious rules | Supports security review |
| Ticket closure | Root cause, actions, monitoring notes | Feeds monthly reporting |
When to escalate to Microsoft or a provider
If service health shows an incident, many users are affected, NDR codes point to Microsoft-side problems or DNS/tenant changes do not resolve the issue, IT should escalate. Before escalation, prepare tenant ID, domain, NDR code, incident time, affected users, send/receive test logs and actions already taken. Good evidence reduces back-and-forth.
If the company uses email hosting or Google Workspace instead of Microsoft 365, the same logic applies: define scope, check DNS, quota, security, client and evidence.
Connection with SLA and IT Support reporting
Email incidents need their own SLA because they affect transactions directly. Company-wide email outage can be P1; one Outlook issue can be P3; alias or group creation is P4. Adding this to an IT Support SLA template helps the business know what requires fast response, scheduled handling or a separate project such as migration, hardening or security cleanup.
Monthly reports should include email tickets, recurring issues, full mailboxes, MFA failures, spam/bounce cases, DNS incidents and recommendations such as enabling DKIM/DMARC, standardizing signatures, auditing forwarding or user training.
What not to do during an email incident
Do not change many DNS records without capturing the current configuration. Do not delete Outlook profiles or mailboxes before confirming data synchronization. Do not disable MFA just to make login easier without understanding the cause. Do not forward business email to personal accounts as a workaround because it creates data risk and is difficult to control later.
If account compromise is suspected, revoke sessions, reset password, check suspicious forwarding or inbox rules, review unusual sign-ins and inspect trusted devices first. After the security side is stable, handle user-level items such as Outlook profile, mobile app or signature. This sequence reduces the chance of missing the real root cause.
Prevention plan after the incident
After resolution, the business should keep a prevention checklist: enable MFA for important accounts, review DKIM/DMARC regularly, limit admin privileges, audit forwarding rules, monitor full mailboxes, standardize email signatures, document external sending sources such as website/CRM/ERP systems and train users to recognize phishing. Without this follow-up, email issues often return.
For Microsoft 365, separate admin accounts from daily-user accounts, enable unusual sign-in alerts and keep a clear owner list for DNS and domain access. When employees leave, the IT Support onboarding/offboarding checklist should revoke email, MFA, device and related app access.
FAQ
Should Outlook be reinstalled first when email fails?
No. Check webmail, service health, DNS, license, password/MFA and incident scope first. Reinstalling Outlook only helps when the workstation profile is the issue.
Is spam placement a Microsoft 365 or DNS issue?
It can involve SPF/DKIM/DMARC, content, domain reputation, external sending systems or account abuse. Both DNS and sending logs should be reviewed.
Should security be checked for a single-user email issue?
Yes. Unexpected forwarding, suspicious inbox rules, unusual sign-ins or mass sending should be treated as a security incident.
Read next in the IT Support, Helpdesk and business email cluster
Need structured Microsoft 365 email incident support?
IT Systems can review DNS, tenant settings, Outlook, MFA, licenses, account security and ticket evidence so email incidents are handled with a clear process.
