Email Troubleshooting Checklist for IT Support

Email tickets look simple until they waste your entire morning. “Email is broken” might mean Outlook will not open, a password expired, MFA is failing, the mailbox is full, a message is stuck in the outbox, DNS is wrong, the sender is blocked, or the user is looking in the wrong folder.

The fastest way to fix email issues is to stop treating them as one problem. First decide which lane you are in: client, account, mailbox, delivery, or domain/DNS. Once you know the lane, the next step is usually obvious.

This checklist is written for help desk and IT support techs who need a practical flow they can use during real tickets, not a vendor manual with 900 branching paths.

The five-minute triage

Start by getting the ticket out of vague-land. Ask these questions before touching settings:

What exactly failed? Sending, receiving, opening Outlook, signing in, search, attachments, calendar, or a specific message?
Where does it fail? Desktop Outlook, webmail, mobile app, mail client, or everywhere?
Who is affected? One user, one shared mailbox, one department, all users, or only external senders?
When did it start? After a password change, MFA reset, license change, migration, update, travel, or new phone?
Is there an error message or bounce-back? Get the exact text or screenshot.

If you only remember one rule, remember this: test webmail early. If email works in webmail but not Outlook, you probably have a client/profile/cache problem. If webmail fails too, stop rebuilding Outlook profiles and check account, license, service, mailbox, or tenant settings.

Quick diagnosis table

Symptom	Most likely lane	First useful check
Outlook will not open	Client	Safe mode, add-ins, profile, updates
Webmail works, Outlook does not	Client/profile	Create new Outlook profile or clear cached credentials
User cannot sign in anywhere	Account/auth	Password, MFA, account lockout, license
Can receive but cannot send	Mailbox/sending	Outbox, attachment size, quota, transport block
Can send internal but not external	Delivery/policy	Bounce message, outbound filtering, connector
External senders cannot reach user	Delivery/recipient	Message trace, aliases, quarantine, mailbox rules
Whole domain has issues	Service/DNS	Provider status, MX/SPF/DKIM/DMARC, tenant health
Only one sender fails	Sender-specific	Block list, typo, mail flow rule, bounce reason

This is the same mindset as good IT troubleshooting methodology: narrow the blast radius before you start changing things.

Step 1: Decide whether this is client-side or server-side

Do not start with “reinstall Office.” That is the help desk equivalent of replacing the engine because the gas cap is loose.

Run these checks:

Can the user sign in to webmail from a clean browser session?
Can they send a test message to themselves from webmail?
Can they receive a reply in webmail?
Does the same problem happen on another device or network?
Are other users reporting the same symptom?

If webmail works

Focus on the device or app:

Restart Outlook.
Try Outlook safe mode: outlook.exe /safe.
Disable suspicious add-ins.
Check whether Outlook is in offline mode.
Confirm the account is connected and not prompting silently for credentials.
Clear saved credentials from Windows Credential Manager.
Create a new Outlook profile if the profile is corrupted.
Check for Office and Windows updates.

A new Outlook profile is a reasonable fix when you have proven the mailbox works elsewhere. It is a bad first move when you have not tested webmail yet.

If webmail fails too

Move away from the endpoint:

Check account lockout or disabled status.
Confirm the user has the right license or mailbox assigned.
Verify password and MFA status.
Check service health in the email provider admin portal.
Check mailbox quota.
Run a message trace if the issue is delivery-related.
Check whether the user is hidden, converted, moved, or missing aliases after a change.

For Microsoft-heavy environments, this overlaps with basic Active Directory administration: identity problems often show up as “email problems” because email is the app users notice first.

A user saying “I cannot get email” might actually mean “I cannot sign in.” Those are different tickets.

Work through this list:

Is the username correct?
Did the user recently change their password?
Is the account locked, disabled, expired, or blocked?
Is MFA required but not completing?
Did they get a new phone and lose their authenticator app?
Are they trying from a blocked country, VPN, or unfamiliar location?
Does conditional access or device compliance apply?
Can another known-good account sign in on the same machine?

If the user cannot sign in to any company app, do not call it an Outlook issue. Treat it as an identity/authentication issue and document it that way.

Mail flow checks

If sign-in works, ask what direction is broken:

Sending only?
Receiving only?
Internal only?
External only?
One recipient or all recipients?
One sender or all senders?
Attachments only?

This matters because “cannot send attachments to one vendor” and “nobody can send email externally” live in totally different neighborhoods.

Step 3: Read the bounce message instead of guessing

Bounce messages are annoying, but they are usually the shortest path to the answer. Get the full non-delivery report, not a screenshot cropped to the least useful part.

Look for:

Recipient does not exist.
Mailbox full.
Message too large.
Sender blocked.
SPF, DKIM, or DMARC failure.
Domain not found.
Policy or transport rule rejection.
Suspicious content or attachment blocked.

If a bounce says the recipient does not exist, verify the address before digging through DNS. If it says message too large, stop checking passwords. Follow the clue you already have.

Step 4: Check the boring mailbox problems

A shocking number of email tickets are boring. Boring is good. Boring means fixable.

Check:

Mailbox quota or archive status.
Deleted Items, Junk Email, Clutter/Focused Inbox, and Archive folders.
Inbox rules that move or delete messages.
Forwarding rules or delegates.
Shared mailbox permissions.
Send As and Send on Behalf permissions.
Retention policy or litigation hold behavior if messages are “missing.”
Whether the user is searching the wrong mailbox or shared mailbox.

Mailbox rules deserve special attention. A user might say “I am not receiving invoices,” but the actual issue is an old rule moving invoices into a folder they forgot existed. Also, suspicious forwarding rules can be a security issue, not just an annoyance.

Step 5: Check DNS only when the pattern points there

DNS matters for email, but do not use it as a magic word. Check DNS when the issue affects a domain, external delivery, spoofing protection, or newly changed mail services.

The big records:

Record	What it does	When to check it
MX	Tells the internet where to deliver mail	External senders cannot deliver to your domain
SPF	Says which systems can send for your domain	Outbound mail lands in spam or fails authentication
DKIM	Adds cryptographic signing to outbound mail	Deliverability/authentication problems
DMARC	Tells receivers how to handle SPF/DKIM failures	Spoofing, phishing, or rejected mail issues
Autodiscover	Helps Outlook find mailbox settings	Outlook setup/profile problems

If you are rusty here, review DNS troubleshooting for IT support. Email DNS issues are just DNS issues with more angry executives attached.

Step 6: Document the ticket so the next tech has context

Bad ticket note:

Fixed email.

Useful ticket note:

User could sign in to webmail and send/receive successfully. Outlook desktop stuck disconnected. Cleared saved Microsoft credentials, restarted Outlook, issue persisted. Created new Outlook profile and confirmed send/receive. Root cause likely corrupted local profile. No tenant-wide issue found.

That note tells the next tech what was tested, what changed, and what not to repeat. It also helps if the same user opens another ticket tomorrow.

If your team struggles with this, build lightweight standards from ticketing system best practices. You do not need a novel. You need enough breadcrumbs to avoid re-solving the same problem.

A reusable email troubleshooting checklist

Copy this into your notes or knowledge base:

Email troubleshooting checklist

Scope
[ ] What exactly is failing?
[ ] One user, multiple users, or everyone?
[ ] Desktop app, webmail, mobile, or all clients?
[ ] Started after a known change?
[ ] Exact error or bounce message captured?

Client vs server
[ ] Webmail sign-in tested
[ ] Webmail send/receive tested
[ ] Outlook safe mode tested if desktop-only
[ ] Cached credentials checked
[ ] Outlook profile considered only after webmail works

Account/auth
[ ] Password verified
[ ] MFA checked
[ ] Account lockout/disabled status checked
[ ] License/mailbox assignment checked
[ ] Conditional access/device compliance considered

Mailbox
[ ] Quota checked
[ ] Junk/Focused Inbox/archive checked
[ ] Inbox rules checked
[ ] Forwarding/delegation checked
[ ] Shared mailbox permissions checked if relevant

Mail flow
[ ] Direction identified: inbound/outbound/internal/external
[ ] Bounce message reviewed
[ ] Message trace or provider logs checked
[ ] Quarantine/spam filtering checked
[ ] Attachment size/content policy checked

Domain/DNS
[ ] MX checked if inbound domain issue
[ ] SPF/DKIM/DMARC checked if deliverability issue
[ ] Autodiscover checked if setup issue
[ ] Provider service health checked

Wrap-up
[ ] Root cause or likely cause documented
[ ] User confirmed fix
[ ] Ticket notes include what was tested
[ ] Escalated with logs/screenshots if unresolved

When to escalate

Escalate when you have enough evidence for the next tier to act. Do not just throw the ticket over the wall with “email broken.”

Escalate with:

Affected users and scope.
Exact symptom and error message.
Webmail test result.
Client/device/network test result.
Bounce message or message trace ID.
Recent changes: password, MFA, license, migration, DNS, filtering.
Screenshots or logs.
What you already tried.

Good escalation is not admitting defeat. It is packaging the problem so the next person can move faster.

FAQ

What is the first thing to check when email is not working?

Test webmail. If webmail works, focus on Outlook, the device, cached credentials, or the profile. If webmail fails too, check account, authentication, license, mailbox, service health, or mail flow.

Should I rebuild the Outlook profile right away?

No. Rebuild the profile after you prove the mailbox works somewhere else. If the user’s account, license, or mailbox is broken, a new Outlook profile just wastes time.

How do I troubleshoot emails not being received?

Find out whether the problem affects one sender, all external senders, internal senders, or everyone. Then check junk folders, inbox rules, mailbox quota, aliases, quarantine, message trace, and bounce messages.

When should I check MX, SPF, DKIM, and DMARC records?

Check them when external delivery, deliverability, spoofing protection, or a recent domain/email provider change is involved. Do not start with DNS for a single user’s broken Outlook profile.

What should I include in an email troubleshooting ticket note?

Include the symptom, scope, webmail result, client result, exact error or bounce, what you changed, user confirmation, and the likely root cause. Future-you will appreciate it.

Bottom line

Email troubleshooting gets easier when you stop guessing and start sorting. Client or server? Sign-in or mail flow? One user or everyone? Internal or external? Once you answer those questions, most email tickets become normal troubleshooting instead of ritual sacrifice to the Outlook gods.

If you are trying to get better at support work in general, start with the broader senior-level troubleshooting process, then keep practical checklists like this one for the tickets that show up every week.