When you run your own mail server, you have full control over its performance and reliability. here’s how to get started with an open source mail server on aws ec2.
related: how to install a web server on aws ec2 and set up a website from scratch on a domain of your choice.
running a mail server on aws ec2 is not as easy as it seems.
1. register your domain name
register your domain name with a reputable registrar. the company that performs this service is now officially the registrar of your domain. it is now your responsibility to keep your contact details with this company up to date at all times. If you don’t want to divulge as much personal information, you can purchase a domain privacy service in most jurisdictions, but you must still keep your account with your registrar in good standing or you risk losing your domain. this is where using a reputable and trustworthy registrar pays off: they will go the extra mile to alert you to any bumps in the road and protect you from potentially disastrous events such as domain hijacking attempts by third parties.
after registering your domain name you can configure routing.
2. get your ns servers from route 53
log in to the aws management console and navigate to the route 53 service at:
Create a new public hosted zone using the domain name from step 1. This will reserve four of amazon’s nameservers for the domain of your choice (minimum required is two, but you must use all four). make a note of their hostnames; you don’t need to know their ip.
for more information on dns setup, please refer to this post: A quick guide to dns setup using aws route 53 (or any other dns service)
3. map your domain’s nameservers to your domain registrar’s record
your registrar may have already assigned their own nameservers to your domain. This is common practice with services like domain parking, where you’re not hosting a website yet, but simply holding the domain in your account. whatever the case with your registrar’s default ns servers, in most cases you’ll want to swap them out.
Log back into your account at your registrar and change your domain’s default nameservers to your new nameservers that you acquired through aws route53 in step 2 above.
4. edit your hosted zone to configure ns routing
At this point, there are two possible scenarios. you can:
- set up a mail server from scratch
- use an existing mail server that has been preconfigured in another domain and is already working.
In the first case, you must create an a record and an mx record in the hosted zone of your domain. the a record should point to the ip address of your ec2 instance that will host your mail server. the mx record defines your mail exchanger. this is the host running your mail transfer agent (eg postfix).
In the second case, where you simply add your new domain to an existing setup, all you have to do in terms of ns setup is create an mx record pointing to the host that is running a fully functional mail server. the default priority of 0 is meaningless with a single mail server.
Within your domain’s hosted zone, click the create a record set button and give it a name of your choice (typically mail.domain.tld or smtp.domain.tld). select the type “mx — mail exchange”. no, it’s not an alias. keep the ttl value at its default value. enter the hostname of your mail server with the default priority of 0 in the form:
(with the period at the end). a lower number means a higher priority. set the routing policy to simple and click create to confirm. the result should be something like this:
after a period of time defined by the ttl value, the routing should be fully operational, but may not have propagated yet. Patience is the key to success here. In the meantime, you can use a service like intodns.com to verify your settings.
5. request a reverse dns record from aws
Request an aws reverse dns record using this form (aws root access required):
6. configure your mta
The details of this step depend on your choice of mta. one of the best open source mtas is postfix of course. supports various types of mail users:
- unix system users (such as root or postmaster)
- vmail users: These users access virtual mailboxes using canonical (“real”) or hosted domains (so called because they are non-canonical ). to the suffix host)
You can implement hosted domains in several ways, namely as:
- virtual alias domains: mail users in these domains are always aliases to addresses in other domains (can be local unix system accounts or remote addresses); to configure these accounts, use the parameter virtual_alias_maps
- virtual mailbox domains: each mail user can have their own mailbox and a unix system account is not required; to configure these accounts, use the virtual_mailbox_domains parameter
your domain (yourdomain.tld) will be a hosted domain in this setup.
first, postfix must recognize your hosted domain as legitimate. to make postfix take responsibility for handling mail, use the virtual_alias_domains and virtual_alias_maps parameters.
When changing postfix map files, remember to run postmap on them and reload postfix. after changing configuration files, remember to restart postfix.
once you complete this setup, there is only one more big challenge to overcome and that has to do with reading mail.
7. configure an mda
y mda is the software on your mail server that delivers messages to your mail client on any device of your choice. one of the best open source mdas out there is dovecot.
Assuming the dovecot setup works on an existing mail server, there’s only one more thing you need to do: create login credentials for a dovecot user on your new domain. the most typical configuration consists of a username (typically the email address) and a password. hash the password using:
Save the hash, not the password!, to the dovecot user database (look for the passdb and userdb parameters), then restart the service. This is what the password hash looks like in the configuration in /etc/dovecot/users:
verify authentication
If you’re having trouble connecting to dovecot remotely, try the command line.
check if the user exists:
verify authentication:
if you are successful, you know your credentials work with dovecot. your mail client, when configured correctly, should have no problem connecting to your ec2 instance running dovecot to retrieve mail that postfix stores there.
in case you need more detailed debugging information, open the file
/etc/dovecot/conf.d/10-logging.conf
and activate:
restart dovecot, repeat recent activity and check your logs:
7. configure your mail client
Last but not least, you need software to handle email on your end device. Outlook, Postbox, Thunderbird, and Microsoft’s Apple Mail are some popular options.
Once this setup is complete, your administrative tasks will only begin in earnest. spam is the name of the game in mail server management.
related: antispam defense: using postfix with smtpd access restrictions