Recipient verification

In this article, you will learn what recipient verification is and how the recipient verification file is created.
Background information
To ensure that, for globally reachable RWTH email addresses, emails are delivered only to existing recipients, recipient verification is used.
For all accounts on the central RWTH mail server, this verification is already implemented. For other mail servers within RWTH, recipient verification is also indispensable for the reasons listed below:
- Without recipient verification, many delivery attempts to non-existent mailboxes are accepted and only later recognized as undeliverable. This results in unnecessary (bounce) emails being transported and checked for viruses and spam.
- During spam and virus waves, this can quickly lead to overload at the mail inbound of RWTH Aachen University.
- In the event of an error, a non-delivery notification must be generated. Since sender addresses in spam are often forged, such notifications (“backscatter”) may be sent to uninvolved third parties and may contain not only the error message but also content from the original email.
- At the central mail gateway, a large number of unwanted delivery attempts from external sources are already rejected directly during the SMTP dialog (reject).
However, this is not sufficient if downstream mail servers first accept messages and only later determine that the recipient does not exist. In this case, non-delivery notifications (bounces) may be generated, which in turn are sent to forged sender addresses (backscatter). - The original spam may therefore be indirectly “confirmed” again via RWTH mail servers or answered with non-delivery notifications (backscatter).
- This can harm the email reputation of RWTH Aachen University or lead to some providers rating emails from RWTH domains less favorably or no longer accepting them.
Recipient verification file
For these reasons, a way was developed to centrally record and keep up to date the email addresses of departmental mail servers.
This enables recipient verification for the mail domains of the individual RWTH units as well. To do so, each unit provides a recipient verification file (text file) containing all valid email addresses (local-parts) of that unit.
The data is imported into a database that can be queried by the central inbound mail server (mail gateway at the MX). This makes it possible to decide as early as the SMTP command RCPT TO whether a recipient exists, and to reject the message immediately if necessary.
This shifts error handling to the sending mail server; unnecessary acceptance and later bounces (backscatter) are reduced. In addition, automated attacks (e.g., address guessing) can be detected and blocked earlier.
The recipient verification file is retrieved cyclically per domain from a (protected) web server of the respective unit.
The synchronization is performed every 15 minutes by default. For security reasons, a synchronization is discarded and the existing dataset is retained if:
- network errors occur (timeout, reject, etc.).
- more than 20% of the addresses stored with us would be deleted.
- no file is available.
In the event of a database outage, recipient verification is automatically disabled; incoming emails are then processed without this check until the service is available again.
Formatting the recipient verification file
This file must list all email addresses of the respective unit line by line, without the domain part.
For example, for the email addresses webmaster@test.rwth-aachen.de, postmaster@test.rwth-aachen.de, admin@test.rwth-aachen.de, the following entries would have to be listed in the recipient verification file:
- webmaster
- postmaster
- admin
Please note the following restrictions:
- Comment lines are allowed and start with #.
- Wildcards are NOT possible.
- The following characters are allowed in address entries:
- letters a-z
- digits 0-9
- special characters "." "-" "_" "&" "/"
Further information:

