What happens when we receive an email?

When a mail client connects to ORRO Family’s servers, we run a complex set of checks in order to validate the sender, the email “envelope” and its content.

In order to be fully transparent, we share here all the verifications, tests and checks we apply for each email we receive and what are the actions that result.

You can also read about which error codes are returned by our servers, and what do we log for a deeper understanding of our architecture.

This description of what happens will be split by each command run as the SMTP standard. We won’t talk about Extended SMTP because commands like STARTTLS are standard and we don’t do more than what is recommended in the RFC.

$> telnet mx1.orro.me 25

The first thing that occurs is a connection to our server. When this occurs, we initiate the session for that specific connection and already assign the IP of the client along with a timer to calculate the overall duration of the exchange. Not much more is done at this point.

$> HELO server_name

Upon receiving the “HELO/EHLO” commands, we start to check the client’s quality by running a few verifications that are pretty standard:

  • We check that the IP is not blocked. This can happen when the same IP connects too many times on our server in a short period of time, or when the same IP got too many 500 errors in a short period of time.
    If that IP is blocked, we display an error message (454 4.7.1 Your IP ({0}) has been banned for {1} minutes. Please try again later.) and stop the connection.
  • Then, we check the server_name value given. If it’s an IP, it must match the IP of the client. If it’s a hostname, it must point to the IP of the client. If this fails, we return the error 550 5.7.25 Your IP does not match your hostname..
  • After that, we check that the reverse name for the IP of the client exists, and matches the given hostname. If the reverse (also called PTR) does not match, we refuse the connection with the following message: 550 5.7.25 IP name lookup failed. No valid PTR record found for the given IP address.
  • Finally, we check that the IP from the client is not listed on any DNSBL. We initially were checking for Spamhaus only, but we now also check at Sorbs and Spamcop too.

$> MAIL FROM user@sender.com

The email provided at this point has many names: Return-path, 5321.MailFrom, Bounce email, Envelope from, etc. This section of Wikipedia explains them very well.

As a matter of consistency, we’ll use the name “return-path” when mentioning this value.

At ORRO Family, we don’t run any checks for the Return-path at this step, they will be done at the DATA level.

The Return-path value is used to send back a notification when the delivery of the email fails later. But it’s worth noting that in some cases, that value can be “<>”. This is often used when sending back a bounce delivery notification, since the sender – the mail server – doesn’t expect a response back.

$> RCPT TO recipient@destination.com

As a Mail client sending an email, it’s possible to send multiple emails at once. This is often the case when you send an email with CC/BCC that have the same destination server.

When we receive an RCPT command, we check that the email is valid and standard.

If the email is a bounce

We verify that this bounce is legitimate by ensuring it really came from us. This is done by checking the hash placed by our service in the return-path email used when sending the original email.

This guarantee that we forward bounces that are legitimate, and protect us from backscatter issues.

If the sender is connected

We’ll consider that the email is being sent. In that case, we will allow up to 50 recipients for that same email and will run a few tests:

  1. We will load the user’s details. If we can’t find it, we will respond with a 550 5.1.9 Relay not permitted. (#id-5.9.2).
  2. If the account is banned, we will respond with a 550 5.2.1 The email account you are using is disabled. (#id-5.9.2b)
  3. Finally, if the user sent too many emails for the day, we will respond with a 552 5.2.2 You reached your daily sending quota. Please try again tomorrow.

Otherwise, the email is to be forwarded.

In that case, we will allow for up to three recipients max. After that, the server will return the following error:

451 4.5.3 Too many recipients.

The recipients will have to be on the same domain (right part of the @). If that’s not the case, the server will return the following error:

451 4.1.2 Please RCPT to the same domain.

Then, the following tests will be run on the destination domain:

  1. We will ensure that the domain does exist in our database (to know where to redirect the email to). If we can’t find it, we will return the following error:
    550 5.1.9 Relay not permitted. (#id-5.9.2)
  2. We will then ensure that the destination account is not banned. If that happens, the server will return the following error:
    550 5.2.1 The email account that you tried to reach is disabled. (#id-5.9.2b)
  3. If the domain has reached its daily quota limit, the server will return the following error:
    552 5.2.2 The recipient you are trying to contact is over daily incoming mail quota. Please try again later.
  4. Finally, if no aliases were found to redirect the email to, the following message will be returned to the client:
    550 5.1.1 The email account that you tried to reach does not exist. Please try double-checking the recipient's email address for typos or unnecessary spaces.

With the list of forwarding email loaded for a specific alias, and for each destination emails

Note that if you send an email to more than three persons that have their domains managed by ORRO Family, your email client should be able to handle this case and will do one session per domain.


This is the core of ORRO Family, where all the most important work happens.

It makes sense because, at this point, we have the complete elements in hand. We have the envelope (as its name describe, this is the wrapper of the actual email, which include the sender, the recipient, and who is delivering it to us), and the email’s content (which include the message but also the headers).

The first thing we check is if the email is a bounce or a delivery report. These need special handling so we process them specially, first.

Then, we verify that the headers of the email contains the From field. This is not required per se, and some email service accepts emails without a From field, but following the new DMARC system, a From header is important for domain alignment (a specification of DMARC).
Moreover, we verify that the From header is present AND valid as per the RFC standard.

Note: The From in the email’s header can (and often is) different from the Return-path.

That’s also the reason why we don’t check the “MAIL FROM” command before: Doing the check in the DATA section allows us to have a treat the right From and verify domain alignment.

Next, we ensure that this email was not forwarded too many times. For instance, if your mail client connects to a server, that then connects to a server which then deliver to the recipient, that’s alright. But if one server connects to another, that connect to another, and on and on and on, the email could transit forever.
This can be easily the case in our own service if someone setup to alias that redirects to the other: infinite loop (yay!). In this case, the email will be dropped after a few forwards.

After that, we check for any attachments and reject the email if one of the attachment is in the list of refused extensions.

Now, we verify that the recipient is both at ORRO Family and not over quota.

File size, based on plan




We append a few headers (X-Forwading-Service, etc)

We sign the email with DKIM


Check that the forwarding email has valid MX records

Queue the email