Mail isn't arriving: the step-by-step plan

Module 6: Bounces and troubleshooting · Reading time: 11 minutes

Learning objective: After this lesson you can systematically work out why an email isn't arriving or is ending up in spam, both as sender and as recipient, and you know what information you need when asking for help.

Key concepts: sending side and receiving side, bounce, mail log or email tracking, spam folder, rules and filters, test email to your own external address, Authentication-Results, testing tools, when it's the recipient's turn to act

Start with the right question

"My mail isn't arriving" can mean very different things:

• the email was never sent (it's still in the Outbox, or your program showed an error);
• the email was sent, but came back with a bounce;
• the email was delivered, but ends up in the recipient's spam or another folder;
• the email was delivered, but the recipient can't find it or says they never received it;
• you yourself are no longer receiving mail from one or more senders.

Each of these situations has a different starting point. The step-by-step plan below works like a decision tree: at every step you learn more, and often you're done after two or three steps.

As sender: seven steps

Step 1. Was the email actually sent?
Is it in your Sent folder? Is it still sitting in the Outbox, or did your program show an error? Then it's a sending problem on your end: server name, port, login, password, or an attachment that's too large (lesson 1.4, 2.1). Test in webmail: if sending works there, the problem is in your program.

Step 2. Did you get a bounce?
Check your inbox (and your spam folder) for messages from Mailer-Daemon or Mail Delivery System. If there's one, read it (lesson 6.1) and look up the code (lesson 6.2). In most cases you'll now know the cause.

Step 3. No bounce: what does the mail log say?
Look up the email in your provider's log. In a hosting panel this is often called email tracking or mail log, in Microsoft 365 it's message trace, in Google Workspace it's the email log search. You'll see:

Step 4. Delivered, but the recipient doesn't see it.
After code 250, the email is with the receiving party. They may put it in spam, in a quarantine at their mail administrator, or have a rule move it. Ask the recipient to check Spam or Junk, other folders, and whether their administrator has a quarantine. You can't see this yourself.

Step 5. Check your domain.
Does your mail end up in spam more often, or fail to arrive at one large recipient? Check SPF, DKIM and DMARC with a tool (the E-mail check, Domain health, internet.nl or MXToolbox). Pay particular attention to:

• exactly one SPF record, within the ten lookups, with every service that sends mail (lesson 4.2);
• a DKIM key for the selector used in your mail (lesson 4.3);
• a DMARC record, and which policy it sets (lesson 4.4).

Step 6. Send a test email and read the header lines.
Send the same email (with the same sender and ideally the same content) to an address of your own at Gmail and at Outlook.com. Open the header lines there (in Gmail: "Show original"). Look at Authentication-Results:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=x header.b=Ab12Cd34;
       spf=pass (google.com: domain of info@example.com designates 192.0.2.25 as permitted sender) smtp.mailfrom=info@example.com;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.com

If it shows pass three times, authentication is fine and a spam placement comes down to reputation or content. If it shows fail, softfail, none or temperror, you know what to fix. Testing services such as mail-tester give a similar report with a score.

Step 7. Look at the sending server.
Which IP address delivered the email (lesson 5.1)? Does it have a correct PTR? Is it on a blocklist (lesson 5.2)? Is it your provider's address or your own internet connection's address? A home connection means your program isn't sending through your provider's server.

As recipient: six steps

If you're no longer receiving mail, or are missing mail from one sender:

1. Check webmail, including Spam and Junk. If the email is there, the problem is in your program or phone (password, POP3 on another device removing the mail, a rule; lesson 1.3, 3.1).
2. Is your mailbox or plan full? A full mailbox rejects new mail (lesson 3.2).
3. Filters and rules: a spam filter that deletes spam immediately, a blocked sender, a server rule that forwards it elsewhere.
4. Is your MX correct? Does it point to the server where your mailbox is located? This often goes wrong after a move or a connection to Microsoft 365 or Google Workspace (DNS course lesson 4.1, lesson 8.2).
5. Is there a forwarding set up for that address? Then the email ends up there, not in your mailbox (lesson 3.3).
6. Ask the sender for their bounce. It tells you exactly what your server replied.

When is it the other party's turn to act?

You can't solve everything yourself. Here's how to tell when it's someone else's issue:

• The recipient, when: mailbox full, address closed down, email delivered but in their spam or quarantine. Ask them to save your address as a safe sender or contact.
• Your provider, when: the sending server is on a blocklist, lacks a proper PTR, or is being throttled or blocked by a large recipient. Send them the full bounce.
• The service sending on your behalf (webshop, accounting software, newsletter service), when: mail from that service fails SPF or DKIM. That service will give you the correct records.

Asking for help: what do you send along?

With this information, any support team can look up the email straight away:

• the sender address and the recipient address;
• the date and time it was sent (with time zone);
• the full bounce, or the line with the code;
• if the email arrived but ended up in spam: the full header lines of that email;
• which mail program or service you used.

Never include your password. No serious provider will ever ask for it.

In practice: what this looks like

At WebOké you'll find step 3 in DirectAdmin under E-mail Tracering, and step 5 in My WebOké on the Set E-mail or Domain / Email health card. If you don't have an account, use the public E-mail check and Domain health at weboke.nl. Other providers name these features differently, but almost every panel has a mail log and DNS management, and the independent tools work for any domain.

Summary

• First work out exactly what "not arriving" means: never sent, bounced, delivered but in spam, or not received by you.
• Sender: was it sent? a bounce? the mail log? delivered means it's the recipient's turn; then check your domain, a test email with header lines, and the sending server.
• Recipient: webmail, storage space, filters, MX, forwarding, a bounce from the sender.
• Authentication-Results in a test email shows at a glance whether SPF, DKIM and DMARC pass.
• When asking for help, include addresses, the time, and the full bounce or header lines.

Quiz

Exercise

Exercise O6.3: Working through a problem. Pick a real problem from your own situation (an email that didn't arrive or ended up in spam), or use the practice case "invoices to Hotmail only arrive after a day". Work through the step-by-step plan and fill in what you found at each step. Finish with: where was the problem, whose turn was it to act, and what did you do or ask? After this you'll see the checklist and the model answer for the practice case.

Further reading

The steps in these articles apply to WebOké's panels; with other providers it works in a similar way.

• My email doesn't arrive or ends up in spam: here's how to figure it out
• I'm no longer receiving email: here's how to find the cause
• I can't send email (receiving does work)
• Checking whether an email has arrived with Email Tracking in DirectAdmin
• WebOké manual 7.4: Mail not arriving: check it yourself
• DirectAdmin guide 9.4: My mail ends up in the recipient's spam folder
• Domain health (free check for any domain): https://www.weboke.co.uk/domain-health