Short answer: “email is not working” is four unrelated problems wearing the same sentence. Sending is SMTP. Receiving is decided by your domain’s MX records. Reading mail in an app is IMAP. Whether your mail lands in the inbox or in spam is decided by SPF, DKIM, and DMARC. Each one fails on its own, and a fix for one does nothing for the others. Identify which half is broken first, then fix that half.
The fastest way to split the problem in two takes about thirty seconds, so start there.
Start here: the one test that halves the problem#
Open a browser and log into your provider’s webmail. Gmail, Outlook on the web, Zoho, whatever your mail actually lives on. Then send yourself a message from a different account.
- Webmail works and the message arrives. The mail server, the mailbox, and your password are all fine. The problem is on your device: mail client settings, a network in the way, or an app password you have not created yet. Skip to the mail app section.
- Webmail works but the message never arrives. The mailbox is fine and delivery is broken. That is a DNS and MX problem, or a full mailbox, or a spam quarantine.
- Webmail itself will not let you in. The account is the problem: wrong password, a suspended or expired mailbox, or the provider forcing a security change.
- Webmail works and you can read mail but not send. Sending is a separate connection with separate settings. Go to the sending section.
Almost every wasted hour of email troubleshooting comes from skipping this test and reconfiguring a mail app when the mail was never delivered in the first place.
Symptom to cause, at a glance#
| Symptom | What is actually broken | Where to look |
|---|---|---|
| Nobody’s mail reaches you | Delivery routing | MX records, mailbox quota, quarantine |
| You can receive but not send | SMTP submission | Port, encryption, authentication |
| Webmail works, your app does not | IMAP or the network | Client settings, app password |
| “Cannot get mail. The connection to the server failed” | Client, TLS, or network | The mail app section below |
| Your mail arrives in spam | Authentication and reputation | SPF, DKIM, DMARC, blacklists |
| Your website’s forms send nothing | Application-level mail | SMTP relay for the site |
| One specific domain rejects you | Reputation or a policy rule | The bounce message |
Nobody's mail is reaching you#
Incoming mail is routed by your domain’s MX records. They are public DNS records that tell every other mail server on the internet where to deliver mail for your domain. If they are wrong, mail either bounces or is delivered somewhere you are not looking, and nothing you change on your laptop will help.
Check what the world actually sees, not what you think you configured, using an MX lookup. Then work through this list:
The MX records point somewhere stale. This is the classic aftermath of a website migration. The site moved to a new host, the DNS moved with it, and the mail records were rebuilt from a template instead of copied. Mail is now being delivered to a server that has no mailbox for you and is quietly discarding it or bouncing it.
There are leftover default MX records. Many control panels create a default MX record when a domain is first added. If you use an external provider such as Google Workspace or Microsoft 365 and those defaults are still present, mail routing becomes ambiguous. Some senders will pick the wrong one. The symptom is a suspiciously quiet inbox rather than a hard failure, because mail is arriving somewhere, just not with your provider.
The mailbox is full. Over-quota mailboxes reject new mail with a temporary error, so senders retry for a few days and then give up. IMAP keeps every message on the server, so a mailbox that never gets pruned fills up eventually.
The mail is being quarantined. Business providers filter aggressively and hold suspicious mail in a quarantine that is not the Junk folder and does not notify you by default. Check the provider’s admin console, not just the mail app.
You changed DNS in the last day. MX changes take as long as the record’s TTL to propagate. During that window some senders use the old record and some use the new one, which looks exactly like intermittent mail loss. If you recently edited DNS and something else looks wrong too, work through common DNS errors before assuming the mail server is at fault.
You cannot send#
Sending uses SMTP, on a different port, often against a different hostname, with its own authentication. It fails independently of everything else.
The port and encryption do not match. This is the single most common cause. Use 587 with STARTTLS, or 465 with implicit TLS. Do not mix them. Port 25 is for server-to-server delivery and is blocked by nearly every hosting provider and consumer ISP, so a client configured to submit on 25 will simply hang until it times out.
Authentication is failing with the correct password. Google stopped accepting plain account passwords for mail clients in 2022, and Microsoft disabled basic authentication in Exchange Online. Both now require OAuth or an app-specific password, and creating an app password usually requires two-factor authentication to be enabled first. The password is right, the login still fails, and the error message rarely says why.
The network blocks outbound mail ports. Hotel, airport, and corporate Wi-Fi frequently block SMTP submission to stop compromised laptops from spamming. Tethering to a phone for one test message settles this instantly.
You hit a sending limit. Every provider caps messages per hour or per day. Sending a newsletter from a normal mailbox trips these caps, and the account is often throttled for the rest of the day.
The server says “relay access denied”. That means you are asking a mail server to deliver mail for a domain it does not host, without authenticating. Almost always the client has authentication switched off for outgoing mail, or the username is missing the domain part. The username is nearly always the full email address, not just the part before the @.
Your mail app cannot connect#
This is where the iPhone message “Cannot Get Mail. The connection to the server failed.” comes from, and it is worth knowing what it does and does not tell you: nothing specific. iOS collapses several very different failures into that one sentence. A DNS failure, a blocked port, a TLS handshake error, and a rejected password can all produce it. Android and Outlook are only slightly more informative.
Work through it in this order, because each step rules out a whole category.
1. Confirm webmail still works. If it does, the server is fine and the fault is local. If it does not, stop here and fix the account first.
2. Check the hostname, port, and encryption together. These three settings only work in matched pairs. Ports 993 and 143 are for reading mail with IMAP, and the difference between them is only when encryption starts, which is covered in more detail in what IMAP is and how it works.
| Purpose | Port | Encryption setting |
|---|---|---|
| Read mail (IMAP) | 993 | SSL/TLS |
| Read mail (IMAP) | 143 | STARTTLS, required |
| Read mail (POP3) | 995 | SSL/TLS |
| Send mail (SMTP) | 587 | STARTTLS |
| Send mail (SMTP) | 465 | SSL/TLS |
Port 993 configured as STARTTLS fails. So does 143 configured as SSL. Mail apps often “helpfully” guess these during setup and guess wrong.
3. Use the hostname your provider publishes. Not your website’s domain.
imap.gmail.com
and
outlook.office365.com
are not interchangeable with
mail.yourdomain.com
unless your provider says they are. Pointing a client at a generic hostname is also what produces certificate warnings, because the name on the certificate does not match what you typed. Never click through a certificate warning on a mail account. You are about to send your password to whatever is on the other end.
4. Create an app password if the provider needs one. For Gmail and most Microsoft 365 tenants, an ordinary password will never work in a mail client, no matter how many times you retype it.
5. Rule out the network. Turn Wi-Fi off and retry over mobile data. If it works on cellular and not on Wi-Fi, the network is filtering the port or a captive portal has not been accepted yet. VPNs and corporate filtering cause the same symptom.
6. Check the device clock. A device with a badly wrong date cannot validate the server’s TLS certificate, and the connection fails before authentication is ever attempted. Set date and time to automatic.
7. Check whether the mailbox has IMAP switched off. Some providers disable IMAP access per mailbox by default and expect you to use their own app.
8. Remove and re-add the account, last. It works often enough to be worth doing, but only after the steps above, because it destroys the evidence of what was actually misconfigured.
If mail arrives only when you open the app manually, nothing is broken in the usual sense. The connection that pushes new mail needs to stay open, and mobile networks and aggressive firewalls close idle connections. Switching the account from push to a fetch schedule is the practical fix.
Your mail sends, but it lands in spam#
Delivery succeeded. This is a reputation and authentication problem, and it is the one that quietly costs the most money because nothing looks broken from your side.
Three DNS records decide whether receiving servers trust your mail: SPF lists who may send for your domain, DKIM signs the message so it can be verified in transit, and DMARC tells receivers what to do when the first two fail. Google and Yahoo now require all three for anyone sending in volume, so “it used to work” is not evidence that the setup is correct.
Check all three at once with a DMARC and SPF checker, and watch for the two most common faults: more than ten DNS lookups in the SPF record, which makes it fail entirely, and a second SPF record on the domain, which is invalid no matter how correct either one looks.
Mail from your website is not working#
Contact forms, order confirmations, and password resets are a separate problem again. They are not sent by your mailbox. They are sent by the application, from the web server, and the web server is not a mail server.
Outbound port 25 is blocked on essentially all modern hosting, including Hostney servers, so an application trying to deliver mail directly will fail silently. The fix is to route the site’s mail through an authenticated SMTP relay or an API-based mail service, which for WordPress means configuring an SMTP plugin properly and then adding the matching SPF, DKIM, and DMARC records for the service you picked. For anything approaching bulk sending, a mailbox is the wrong tool entirely and a proper newsletter setup belongs on a dedicated service.
One specific domain rejects your mail#
If mail flows everywhere except to one company, or everywhere except one large provider, read the bounce. It contains the actual answer, and it is the only part of email troubleshooting where the system tells you exactly what is wrong.
| Bounce text | What it means | What to do |
|---|---|---|
| 550 5.1.1 user unknown | The address does not exist there | Check the spelling, ask for a current address |
| 550 5.7.1 or 5.7.26 policy rejection | Authentication failed on their side | Fix SPF, DKIM, and DMARC |
| 552 or 452 mailbox full | Their mailbox is over quota | Nothing you can do, tell them another way |
| 421 or 451 try again later | Greylisting or rate limiting | Wait, it usually delivers on retry |
| 535 authentication failed | Your own login was rejected | App password or OAuth, not a delivery issue |
| 554 blocked, with a URL in the text | Your sending IP is on a blocklist | Follow the URL, request delisting |
For that last one, check the sending IP against the public blocklists with a blacklist checker. If you send through a shared relay, one listing can be someone else’s fault, which is a good reason to use a reputable provider rather than sending from a random server.
Where web hosting fits into this#
Web hosting and email hosting are separate services that people reasonably expect to arrive together. Hostney hosts websites, not mailboxes. Your mail lives with whichever provider your MX records point at, and your mailbox settings and passwords come from that provider.
What Hostney controls is the DNS your domain answers with, so MX records are edited under Hosting > DNS Zone Editor, and it is worth confirming the result with the MX lookup tool after any change. Two things account for most of the “my email broke after I moved my site” tickets: mail records that were not carried over during the move, and default MX records created when the domain was added that were never removed. Both are DNS-side and both are fixable in a few minutes once you know to look.
Quick triage checklist#
- Log into webmail. Working or not working splits the problem in half.
- Look up your MX records and confirm they point at your actual mail provider.
- Confirm the mailbox is not over quota and check the provider’s quarantine.
- Match port and encryption exactly: 993 SSL, 143 STARTTLS, 587 STARTTLS, 465 SSL.
- Use the provider’s published hostname, never your website’s domain by assumption.
- Create an app password for Gmail and Microsoft 365 accounts.
- Test on mobile data to rule out the network.
- Read the bounce message before changing anything.
- Check SPF, DKIM, and DMARC if mail sends but lands in spam.
- Treat website mail as a separate system that needs its own relay.