How to inspect incoming email issues

Post Reply
User avatar
isscbta
Posts: 13
Joined: Mon Jul 19, 2021 1:41 am
How to inspect incoming email issues

Post by isscbta »

Here you will find step-by-step solution how to inspect problems with incoming emails. For example, let's say that emails sent from domain.com are not reaching your Inbox or they are going into the Spam folder:

- First, you should check logs, to do this - in your SSH, as root, run:

Code: Select all

exigrep 'domain.com' /var/log/exim4/mainlog
Now depending on date when problem occurred, you should inspect mainlog.1 / rejectlog / rejectlog.1 to find what is the problem

Possible problems:
1. For example, lets say that you got this output from exigrep:

Code: Select all

[email protected]:~# exigrep 'domain.com' /var/log/exim4/mainlog
2022-08-04 11:52:46 1oJXX4-0004XK-SL DKIM: d=domain-com.20210112.gappssmtp.com s=20210112 c=relaxed/relaxed a=rsa-sha256 b=2048 [verification succeeded]
2022-08-04 11:52:47 1oJXX4-0004XK-SL <= [email protected] H=mail-ej1-f41.google.com [209.85.218.41] P=esmtps X=TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128 CV=no S=5042 [email protected]
2022-08-04 11:52:48 1oJXX4-0004XK-SL => receiving.email <[email protected]> R=localuser_spam T=local_spam_delivery
2022-08-04 11:52:48 1oJXX4-0004XK-SL Completed
Take a close look at this line: 2022-08-04 11:52:48 1oJXX4-0004XK-SL => receiving.email <[email protected]> R=localuser_spam T=local_spam_delivery

This means that emails sent from [email protected] to [email protected] are going to spam, so you should whitelist this email/domain in order to prevent this. Here you can find how to whitelist domain in spamassassin: viewtopic.php?f=16&t=594&p=1993#p1993

2. If the log shows 'authentication error' related to domain.com, you should check where is their email server hosted: https://mxtoolbox.com.
If domain.com (this is the domain from which we should receive email) have external MX records in place, the server may be attempting to deliver email locally on the server instead of delivering the email to the servers listed as domain.com MX records. In that case you need to contact the administrator of the remote server to do an investigation on his server.

On our side, we can check if emails for domain.com were hosted on our server, by running this command:

Code: Select all

 ls -l /etc/exim4/domains/ | grep 'domain.com' 
If there is no output, that means it's not hosted on our server. Furthermore, if there is an output that indicates that we are hosting emails for this domain, but MX is showing some other mail servers different from ours, then that's the reason for those authentication errors and not receiving emails.

To get a deeper understanding of this, let's go through one simple example:
- Domain AAA.com is hosted on Google Workspace
- Domain BBB.com is hosted on our server
- Domain AAA.com is sending an email to BBB.com
- At some point in time, our server hosted AAA.com, and after that AAA.com was migrated to Google Workspace, but meanwhile we didn't delete AAA.com from our email tab at myVesta hosting panel. So an email is coming from AAA.com hosted on Google Workspace, our server is going to receive that email - but before he does that, the server checks if AAA.com is already hosted on our server and realizes that there is AAA.com hosted on our (email) server. Because of this, our server stops receiving emails from AAA.com as a measure to prevent potential email fraud

Tags:


Post Reply