Problems sending and receiving mail. Reference Guide to Diagnosis and Resolution.

It sometimes happens that sending an email results in failure to send or not receive. of the message. Really understanding which of the two cases we are facing is not easy precisely, because in both cases it is difficult to establish whether we are faced with a failure to send or a failure to receive and requires investigations at a technical level not always possible by the 'final user.

Whose fault is it then? The sender or the recipient?

It should be noted that sending an e-mail and receiving it involves a series of absolutely non-trivial “behind the scenes” operations that indisputably determine the success or failure of sending and receiving.

Although sending an email is within everyone's reach, it is also true that there are thousands of mail servers, each with its own software and each with its own configuration, which at times may not communicate with each other due to technical problems and incorrect configuration.

Let's assume a real scenario

When a user, for example tizio@tizio.it, try sending an email to another user, like caio@caio.it, a series of very specific technical operations are activated that occur in the background. These operations are regulated by standardized protocols and orchestrated by multiple components, while appearing to the user as a simple click-to-send action.

1. The email client used by tizio, which can be a software like Outlook, Thunderbird or a webmail, connects to the mail server responsible for managing outgoing emails for the domain tizio.it, for example mail.tizio.it. The connection generally occurs via the SMTP protocol, authenticated and secure, using ports 587 (submission) or 465 (smtps). Once the connection is established, the client transmits to the server all the information necessary to compose the email: sender (MAIL FROM), recipient (RCPT TO), headers such as Subject, and finally the body of the message (DATA), faithfully following the syntax provided by the SMTP protocol.

2. Once the sending from the client to the sending mailserver is complete, this – which is a software listening on port 25, specialized in managing and forwarding emails – moves on to the next phase: identifying the destination mailserver. To do this, it makes a DNS (Domain Name System) request looking for the MX (Mail Exchanger) record of the recipient's domain, in this case caio.it. This record indicates which server is authorized to receive mail for that domain.

3. The DNS for the domain caio.it will respond with the name of the authoritative mailserver, for example mail.caio.it. The sending mailserver, therefore mail.tizio.it, will use this information to establish a TCP connection to port 25 of mail.caio.it. Once the connection is established, the server tizio will forward the mail to the queue, previously received by the user's client tizio@tizio.it.

4. The destination mail server, mail.caio.it, receives the message and places it in the incoming mail queue. In this phase, the server takes care of storing the message within the local filesystem, in a structured format that can be Maildir (based on separate directories and files for each message) or mbox (a single file containing all emails). The message is then associated with the account caio@caio.it, ready to be consulted by the recipient.

5. Finally, the recipient – ​​in this case Caio – will use his own mail client to access the message just received. This happens through an incoming mail protocol, POP3 or IMAP, which allows you to download the message to your device or consult it while leaving it on the server. Once the connection to the incoming mail server is established, the message will be read and made available to the user.

This is what happens in a normal regime, i.e. without specific anti-virus and anti-spam checks.

Up until now, for this whole mechanism to work, the following requirements are needed:

• 2 fully functional mail servers, one for the sender and one for the recipient

• The host and IP information on the mail servers are published in the DNS entries (called zones) of the domains in question.

• Making a DNS query implies having a working DNS server with the correct information published, especially the MX record

Advanced configurations with sender and content controls.

In an advanced configuration, you also have to deal with additional controls, implemented on the mailserver side, which play a fundamental role in filtering incoming traffic and defending the infrastructure from spam, malware and abuse attempts. These mechanisms not only improve the security and reliability of email, but also allow you to maintain a good reputation of the mailservers involved.

greylisting: is a very effective and simple to implement defense technique. When a message is received from an unknown sender (based on the IP, sender and recipient combination), the recipient server temporarily rejects the email with an SMTP “try again later” code. This behavior, which may seem counterproductive, actually exploits a weakness typical of spam bots: these automated tools attempt to send large volumes of messages and do not correctly manage temporary resends. Legitimate SMTP servers, on the other hand, as per the RFC specification, will try to send the message again after a few minutes. This allows for an initial and already significant selection between legitimate traffic and malicious traffic. The main disadvantage of this approach is the delay in receiving the first email from a given sender, which can vary from 10 to 15 minutes or even more, especially if the sending server is slow in managing retry queues. After the first successful delivery, however, the sender is “whitelisted” temporarily or permanently, speeding up subsequent sendings.

DNSBL (DNS-based Blackhole List): This is another powerful defense tool. When a mail server receives an incoming connection, it makes a series of queries to public and distributed lists on the Internet that contain IP addresses known for spam activity or suspicious behavior. These requests are similar to those made to obtain DNS records and are made via UDP protocol. If the sender's IP appears on one of these blacklists, the message can be automatically rejected, returning an error message to the sender containing the reason for the rejection. This approach allows you to proactively block large amounts of spam, but requires careful selection of the lists to use to avoid false positives and limit the impact on legitimate emails.

SPF (Sender Policy Framework): is a validation mechanism that allows the sender domain to specify, via specific TXT records in the DNS, which IP addresses or hosts are authorized to send emails on behalf of that domain. When a server receives a message, it can perform an SPF check to ensure that the sender IP is actually included in this list. Otherwise, the email can be marked as suspicious or rejected. SPF is very useful for combating spoofing, i.e. sending emails with falsified sender addresses, and represents a first barrier against phishing and spam. However, SPF does not protect the content of the message or guarantee that the email has not been altered along the way.

DKIM (DomainKeys Identified Mail): is an authentication technology that allows an organization to digitally sign outgoing messages. The signature, generated using a private key, is inserted into the message header. The recipient, in turn, can verify the authenticity of the message and its integrity using the public key published in the DNS of the sender's domain. DKIM guarantees that the message has not been modified in transit and certifies that it really comes from the person who claims to have sent it. This mechanism is not visible to the end user, because the verification is handled directly by the receiving mail server. Unlike end-to-end encryption, which protects the content from external eyes, DKIM focuses on the authenticity of the sender and is used by providers to make decisions on how to treat the message in terms of trust.

Anti-spam / Anti-virus: once the previous checks have been passed, the message is analyzed based on its content. Modern anti-spam systems assign a score to each received email, evaluating factors such as the presence of suspicious keywords, dangerous attachments, typical spam patterns, internal URLs, language used, sender IP reputation and much more. If the score exceeds a certain threshold (usually 5), the message is classified as SPAM. Depending on the configuration of the server or the client-side filter, the message may be automatically moved to the SPAM folder, or it may be delivered normally but with a change in the subject, for example by prefixing labels such as [SPAM] o ***SPAM***.

In this case, in order for the message to be correctly received by the recipient's address, the sender must ensure a series of fundamental good practices. First of all, the IP of the sending mailserver must not be listed in a DNSBL. Furthermore, the message must be structured correctly: it is essential to write a coherent subject, include a readable text body (avoiding pure HTML with a single image, for example), and avoid potentially harmful or prohibited attachments, such as executables .exe, script .bat, .vbs, or suspicious compressed files. Any anomaly can increase the SPAM score and compromise its delivery.

It is also important to clearly underline a concept that is too often underestimated: when an email does not arrive at its destination, or is not received, the responsibility can fall on both the sender and the recipient. It is wrong to assume that the culprit is always "the one who is waiting for it". If, for example, one of our customers or suppliers sends us an email from a server listed in a DNSBL blacklist, the responsibility is entirely theirs: it is them who are not sending the email according to the minimum rules of SMTP hygiene. Our server, in rejecting that email, is doing exactly what it should do: protecting our infrastructure from potentially malicious sources.

It is also important to remember that email is not, and never has been, a tool designed for instant communication. Its architecture is asynchronous and best-effort: delivery is not guaranteed, it is not immediate, and it may be subject to delays or errors. Any use of email as a “real-time” system is, technically, a misuse.

Every time an email is not delivered, the sending system (unless it has been misconfigured) returns an error message, called a bounce, which includes an SMTP code and a description of the problem. Reading these error messages carefully allows, without a shadow of a doubt, to understand the origin of the problem: if it is our block, if it is an error of the sender, if the address does not exist, or if the message was rejected for security reasons.

Too often these errors are ignored or overlooked, and we end up reporting as faults problems that are actually simply related to compliance (or not) with the rules. It would be enough to take a few minutes to read the contents of the bounce to avoid unnecessary or unfounded communications to the company helpdesk.