Why am I not receiving emails? Finding the cause on your domain

Mail to an email address on your own domain stops arriving for only a few reasons, and the quickest way to tell them apart is to send yourself a test from an account with a different provider. A personal Gmail or Outlook address is perfect for this; wait a few minutes and see what comes back to that account:

• A bounce is good news here, because it names the problem in the bounce message.
• Silence is harder to read, and it usually means the mail was delivered to a server other than the one holding your mailbox.

Before touching the server there are some easy to perform checks that can help rule out the mailbox itself, especially if you can send but not receive emails. First, try checking the junk folder, review the rules in your mail app and ensure you’re reading the account you think you are. If you read mail on a phone, log in to webmail as well; mail that shows in webmail but never reaches the phone points to a problem with the app’s account settings, and nothing on the server needs to change.

Read the bounce-back message before changing anything

A bounce message that lands back in your test account usually quotes the receiving server’s reply, and within that reply is the diagnosis.

“No Such User Here” means the address has no mailbox; our servers reject mail sent to an address that does not exist, so the sender gets that bounce straight away instead of the message disappearing. Compare the spelling with the email address you meant to use, and look in cPanel’s Email Accounts list and, if it’s not there, create the mailbox. A missing address is common after a move to a new host, because mailboxes have to be created on the new server before mail is pointed at it.

A bounce mentioning quota, space or a full mailbox means the account has hit its size limit. Email delivery to that address stays blocked until there’s room, so delete old messages (the sent and deleted folders are usually the largest) or raise the mailbox’s quota in Email Accounts. Large attachments can also be refused on their own, and our guide to email size limits explains where those limits sit.

Bounces mentioning policy, spam or authentication are a different issue, covered further down.

No bounce and no mail: where your MX records point

When a test sends without complaint and still never arrives, the mail has almost always gone to the wrong server. Your domain’s MX records tell every other mail server where to deliver mail for your domain, and if they point somewhere other than the server holding your mailboxes, messages get accepted there but never reach you. This is the classic result of moving host. Changing your nameservers swaps the whole DNS zone for the new host’s copy, and the MX records in that copy point at the new server whether or not your mailboxes have moved yet. The reverse catches people too: mail moved to Microsoft 365 or Google Workspace, with MX records still pointing at the old hosting account. Our guide to moving a WordPress site to a new host covers the order to do a move in, so the mail side is ready before the DNS changes.

To confirm it, look up your domain’s MX records with a DNS propagation checker and compare the answer with where your mailboxes actually live. If they disagree, change the MX records in cPanel to match the mail provider you use.

Once the records are correct, allow time for every sender to see them. Other servers keep their copy of your old MX records until the record’s time to live (TTL) runs out, and on our zones that is four hours unless someone has raised it. The “up to 48 hours” people quote belongs to a nameserver change, where the registry’s own delegation is what has to expire. An MX change on its own is much quicker than that.

Mail sent from your own website never arrives

This narrower version of the same fault catches people who have moved their mailboxes to Microsoft 365 or Google Workspace. Mail from everyone else arrives normally, but contact form messages, order confirmations and password resets sent by the website to your own address never turn up. Nothing comes back either, not even a non-delivery report (NDR).

The cause is a cPanel setting called Email Routing. New accounts on our servers start on Local Mail Exchanger, which tells the server to deliver mail for your domain to its own mailboxes. Mail from outside follows your MX records to your new email provider. Mail your website sends to your own domain never leaves the server and lands in a mailbox nobody reads. Set Email Routing to Remote Mail Exchanger for the domain, a step our guide to setting up Google Workspace email walks through and which applies just as much to Microsoft 365.

Mail arrives, but somewhere else

If some messages go missing and others do not, look at what the server does with mail after it accepts it. A forwarder sends copies of an address’s mail on to another address, often an external one. A filter can move, redirect or discard messages that match a rule. Both are easy to forget once they are set up, especially on an account more than one person looks after. Check the Forwarders page in cPanel (our guide to setting up forwarders shows where it is) and the Email Filters for the address, and remove anything nobody can explain.

Mail blocked as spam

When a bounce mentions spam, a blocklist or a policy rejection, the receiving side has decided the message looks untrustworthy. For mail coming in to you, that is usually a sender whose own domain fails its checks, and there’s little you can change except ask them to fix it or allow the sender. Our guide to email blocked for spam explains how to read those messages and what can be adjusted on your side.

The same checks apply to mail you send. If replies you expect never come because your own messages are being rejected or filed as junk elsewhere, look at your domain’s SPF record and DMARC record before assuming the other side is at fault.

Check the fix worked

Send another test from the same outside account to check the fix once the change is in. If you changed MX records, wait out the TTL first and repeat the lookup until every resolver shows the new value, then send the test. A message that arrives within a minute or two, in the inbox and not the junk folder, confirms the fault is gone. If your own computer still shows the old records after the rest of the world has the new ones, flush your local DNS cache and look again.