Server Setup

Server Email Setup

by , , revisited on

We have by far the largest RPM repository with NGINX module packages and VMODs for Varnish. If you want to install NGINX, Varnish, and lots of useful performance/security software with smooth yum upgrades for production use, this is the repository for you.
Active subscription is required.

There are many resources (articles, dedicated websites) to help you with setting up your website email easily.
However, most of these make an assumption of having single website per server, which is most of the time not the case.
You arrived here to configure mail that will work differently for each virtual host (in NGINX terms, server block).

We will cover free ways to send and receive mail from your domain (website), from easy to hard mode. All without packing your server with full blown email services.

Server email setup should be easy! Let’s start.

Part 1. Receiving email

Referring to other articles again: they want you to run a full blown mail server just for the sake of reading a few website-specific emails.
Instead, we suggest to use 3rd party email servers, that will save precious server resources and will provide web interface and IMAP access.

Free email hosting for your domain

What does email hosting mean? It means that you can send & receive email using your domain email accounts. The following services provide receiving capability, as well as sending.

Zoho Mail

Zoho Mail Suite Provides 25 free accounts with 5GB storage for each. Simply point your domain’s MX DNS record to them and now you can read emails sent to email addresses on your own domain.

Read your @domain.com emails inside your Gmail

If you already own a Gmail account, you can read the emails for your domain there. Setup Zoho Mail first. Then go to your Gmail account and specify Zoho POP connection details:

Incoming Server Name : imappro.zoho.com
Port : 993
Require SSL : Yes
Username : user@yourdomain.com
Incoming Server Name : poppro.zoho.com
Port : 995
Require SSL : Yes
Username : user@yourdomain.com

Yandex for Mail

Allows you to host email accounts of your domain, similar to Zoho Mail

Using options like this, all you need is edit your DNS, point MX record to Zoho’s or Yandex’s, then setup email accounts with them, and you’re all setup.
But it’s not over here. Once you have setup send and receive email provider with your domain, we need to add send capability to your website (virtual host).

Part 2. Sending email

This is the most complicated part. If you don’t configure it correctly, you will be having your site emails delivered to SPAM inboxes.
You don’t want emails from your website to be delivered to your site visitors SPAM!

Sending email the easy way. Use Mandrill

One of the easiest options, is simply updating your website configuration to make use of excelent Mandrill app.

You have to be registered at Mailchimp in order to be able to use Mandrill. The free account allows 1,000 outgoing emails per month.

Once you are registered with Mandril, update your website app to send emails using Mandrill API or SMTP relay.
For WordPress, you will do this by installing and configuring wpMandrill plugin. It will take care of sending emails using Mandrill API. Next, once a couple emails are sent by your WordPress installation, they will be added to “Sending Domains” in Mandrill, and it will provide you with links to easily setup DKIM and SPF records in your DNS settings.

For other websites, that don’t have a plugin or direct Mandrill support, simply make them use SMTP relay of Mandrill. Any CMS written in PHP nowadays supports sending email using SMTP, so you will not be out of luck here.

Even for the rest of the sites, that do NOT support SMTP, you can (and should) adjust your local MTA (Sendmail or Postfix) to relay mail to Mandrill.

Install postfix and replace in php.ini sendmail_path to:

sendmail_path=/usr/sbin/sendmail.postfix -t -I

Relevant steps for Centos:

yum install cyrus-sasl-plain

Add code to the end of /etc/postfix/main.cf:

# enable SASL authentication
smtp_sasl_auth_enable = yes
# tell Postfix where the credentials are stored
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
# use STARTTLS for encryption
smtp_use_tls = yes
relayhost = [smtp.mandrillapp.com]
smtp_tls_CAfile = /etc/ssl/certs/ca-bundle.crt
# Send from localhost only
inet_interfaces = loopback-only

Create file /etc/postfix/sasl_passwd with contents:

[smtp.mandrillapp.com] MANDRILL_EMAIL:MANDRILL_KEY

And run this command: postmap /etc/postfix/sasl_passwd

The main downside with Mandrill, is monthly cap of free emails, which is 1K. This may be enough for a startup.

The benefits:

  • it will sign your messages with DKIM and will provide easy copy-paste instructions to setup both SPF and DKIM records in your DNS.
  • using Mandrill API to send out emails is faster, and you get a bunch of other free features coming along Mandrill: click and open tracking to name a few.

Sending email the easy way. Use SMTP of your free email hosting

Remember we setup a free email provider to use our domain name? They all come with SMTP sending capability. Simply configure your website CMS (WordPress has a plugin for that) to use SMTP of your email hosting provider. You can also specify SMTP details of your personal Gmail account, but this is NOT RECOMMENDED since Google will try to re-authenticate sending user via Captcha (can your website guess captcha? no? we thought so).

Sending email the hard way. Configure your MTA

This is a lot more complicated if you want to address the SPAM inbox issue. Each of your website needs to use special configuration and modify sendmail_path PHP parameter:

I.e. in PHP-FPM pool configuration, or Apache configuration you have to set it to “/usr/sbin/sendmail -t -i -f username@domain.tld” like this:

php_admin_value sendmail_path "/usr/sbin/sendmail -t -i -f username@domain.tld"

The approach with sendmail_path ensures that the envelope sender address domain matches to the domain of the sender. Confusing, right?

  • The envelope sender address is your server’s email address, e.g. user@web.example.com, whereas web.example.com is the FQDN set up for your server. The user is the actual Linux user on the machine which is routing the email to destination.
  • The actual sender address is typically an email that is in your website’s domain, e.g. noreply@example.com. The noreply can be anything. This is the sender of the email that the recipients will actually see.

For the best results in terms of deliverability of outgoing emails, the domains of envelope sender and actual sender should align. This is why, it is recommended to set your web server’s FQDN to a subdomain of your website(s).


Make sure that your domain’s DNS lists your server’s API as allowed IP for domain in question. Normally you would have an SPF entry like this:

v=spf1 a mx ~all

The SPF entries ensures authentication of the envelope address. So if you haven’t modified the sendmail_path as outlined previously, the envelope address domain is the FQDN of your web server.

The given example SPF entry says, that the owner of the domain of envelope address allows sending emails from it, to:

  • the IP of domain’s DNS A record (your web server IP)
  • the IP of mail exchanger servers (IPs of your free email hosting)

Configure your MTA

MTA is a program that will send mail from your web server. Most popular choices are Sendmail or Postfix.
The most important problem here: even if you have correct SPF record, but your hostname is different than the one in “From:”” header, Gmail might mark the email as spam.

Suppose this configuration:

Server FQDN: server.domain.com
Website: www.example.com
From: info@example.com

As you see, domain.com and example.com are different. You want your email to NOT contain server.domain.com in so called envelope sender header:

The solution is to rewrite outgoing email addresses.
Requirements here: put each domain under separate user (Nginx, Apache).
Suppose that your WordPress installation runs under user exampleuser, and another WordPress instance runs as exampleuser2. When we say “runs”, we refer to the system-wide user PHP is executed with.

Below you can find instruction how to enable outgoing emails rewrite in Sendmail and Postfix (to be added later).

  1. Add the following lines to the /etc/mail/sendmail.mc file:
FEATURE(genericstable, `hash -o /etc/mail/genericstable')
  1. Create /etc/mail/genericstable file containing local users mapped to desired addresses:

exampleuser exampleuser@exampledomain.tld
exampleuser2 exampleuser2@exampledomain.tld

  1. Create /etc/mail/sendmail.gdf file containing the fully qualified name of the local mail server.


  1. Finally, generate a new sendmail.cf file:
cd /etc/mail
make all
/etc/init.d/sendmail restart

Read: Google

Having SPF is usually enough to fight the SPAM issues. But it is important to cover all the bases:


DKIM will sign your email messages so that their CONTENT can be confirmed to originate from specific domains.

Great read about configuring DKIM with Postfix or Sendmail: http://www.stevejenkins.com/blog/2011/08/installing-opendkim-rpm-via-yum-with-postfix-or-sendmail-for-rhel-centos-fedora/

Note: we couldn’t configure it with “rewrite outgoing email addresses”, so best option for sending email from your server the hard way is to use Postfix + outgoing emails rewrite + DKIM signing.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

This site uses Akismet to reduce spam. Learn how your comment data is processed.