Email problems are easier to solve when you isolate one variable at a time. This repeat-use checklist helps you diagnose webmail login failures, sending and receiving errors, synchronization conflicts, browser issues, storage limits, authentication problems, and possible mail-server faults without changing several settings at once.
Overview
When email is not working, start by defining the exact failure. “Email is down” can describe several different conditions: a webmail login page may not load, an account may reject a password, messages may send but not arrive, new mail may appear in a browser but not on a phone, or an email client may repeatedly ask for credentials.
Use this order of diagnosis:
- Check whether the problem affects one device, one account, or multiple users.
- Separate access, sending, receiving, and synchronization problems.
- Test the simplest available path, usually the provider’s official webmail page.
- Review account status, storage, authentication, and mail-server settings.
- Record what changed before adjusting configuration.
This approach protects a shared communication workflow. In a team, avoid repeatedly changing passwords, ports, or DNS records while other people are testing. Keep a short incident note with the time, affected account or domain, error message, device, network, and steps already attempted. That record makes escalation more efficient and helps reveal recurring patterns.
What to track
1. Access and webmail login
First determine whether the official webmail service is reachable. Confirm that you are using the correct provider address rather than a saved bookmark that may be outdated or a link from an untrusted message. If the page loads, note whether the failure is an incorrect password, a locked account, a verification challenge, or a blank or looping login screen.
For secure webmail access, check the browser’s address carefully and avoid entering credentials after following a suspicious email link. If you need to reset a webmail password, use the provider’s normal account-recovery process. Review the Webmail Login Help Center for a provider-focused recovery sequence.
Test a private browser window or a different supported browser. If that works, the likely causes include stale cookies, an extension, cached site data, or a browser setting. If the same login fails across browsers and devices, investigate the account, provider status, network, or identity system rather than repeatedly clearing local data.
2. Sending and receiving
Send a test message from webmail to an address you can check, then send a reply back. Record each result separately:
- Cannot send: check the exact error, recipient address, attachment size, account status, and outgoing server configuration.
- Can send but cannot receive: check mailbox storage, filters, forwarding rules, quarantine, spam, and whether the sender received a bounce message.
- Can receive but cannot send: review SMTP authentication, port and encryption settings, sending limits configured by the provider, and whether the account password recently changed.
- Neither works: test webmail, check account access and service availability, then review domain or mail-server configuration if the issue affects several users.
Do not treat a missing message as proof of delivery failure. Check the recipient’s spam or quarantine folder and inspect any non-delivery report. For unusual sender behavior or unexpected routing, the email header guide can help you identify timestamps, routing details, and authentication results.
3. Device synchronization
If webmail works but a phone or desktop client does not, compare the client with the webmail mailbox. Look for the last successful sync time, offline mode, account-specific errors, and whether only one folder is affected. Confirm that the account uses the intended IMAP and SMTP settings, including the server names, ports, encryption method, and authentication requirement supplied by the provider.
IMAP generally supports mailbox synchronization across clients, while SMTP is used for sending. Avoid copying settings from a different provider or account. Use the IMAP and SMTP settings guide when checking a client configuration, and change one setting at a time so you can identify the effect.
4. Account, domain, and server signals
Track mailbox storage, password changes, multi-factor authentication prompts, account lockouts, forwarding rules, filters, and recent administrative changes. For business email, also record whether the issue affects one mailbox, one domain, a particular network, or the entire organization.
If multiple mailboxes are affected, inspect domain and mail-server settings rather than troubleshooting each device independently. Relevant areas may include DNS records, mail routing, authentication records, relay permissions, and server connectivity. Make changes only if you manage the domain or have confirmation from the responsible administrator. The webmail IMAP and SMTP troubleshooting guide provides a broader configuration checklist.
Cadence and checkpoints
Use this checklist during an incident, then maintain a lightweight review on a monthly or quarterly cadence for important accounts and shared communication systems.
During an active incident
- Write down the first observed time and the first affected function.
- Test webmail before changing a desktop or mobile client.
- Compare a known-working account, device, or network when appropriate.
- Capture exact error text, not just a summary such as “login failed.”
- Record every configuration change and its result.
Monthly or quarterly review
Check that recovery details are current, authorized users still have access, stored credentials are not being shared informally, and important clients use documented mail-server settings. Review forwarding rules, filters, mailbox storage, inactive devices, and recent authentication alerts. For a team, keep a current owner for the domain, mail provider, DNS access, and account recovery process.
Also review recurring delivery problems. A pattern involving one recipient domain, one sender, or one automated workflow may indicate a routing or authentication issue rather than a general webmail outage. Keep the review proportional to the account’s importance; a shared support mailbox deserves more frequent attention than an unused personal inbox.
How to interpret changes
Patterns usually narrow the cause:
- Only one browser fails: suspect cookies, extensions, cached data, or browser compatibility.
- Every device fails for one account: investigate credentials, account status, storage, security verification, or provider access.
- Several users fail at once: check provider availability, DNS, routing, authentication infrastructure, and administrative changes.
- Webmail works but clients fail: compare IMAP and SMTP settings, saved credentials, encryption, and client sync state.
- Messages send but are delayed or absent: inspect bounce messages, recipient filtering, spam or quarantine, headers, and domain configuration.
- The issue began after a password or security change: update authorized clients and review sessions or app passwords where the provider supports them.
Be cautious with conclusions based on a single test. A successful test message proves only that one route worked at that moment. Repeat the test with a relevant sender, recipient, device, or network before making a broad change. Never disable security controls permanently just to make a connection succeed.
When to revisit
Return to this checklist whenever email stops working, a provider or domain is changed, a password or authentication method is updated, a new device is added, or a shared mailbox begins missing messages. Revisit it on a monthly or quarterly schedule for business-critical accounts, especially after staff, DNS, mail-routing, or collaboration-tool changes.
Escalate when several users are affected, the provider reports an account or service restriction, DNS or routing changes are required, or messages contain security warnings. Preserve timestamps, headers, bounce messages, screenshots, and the change log before escalating. If a message appears suspicious, do not use its links to test access; consult the phishing email checker guide and verify the sender through a trusted channel.
After service returns, document the confirmed cause, the successful fix, and one preventive action. Updating the team’s webmail login instructions, IMAP and SMTP settings, recovery ownership, or incident notes turns a one-time repair into a more reliable unified communication workflow.
