How To Setup A Mail Relay Server To Relay Mail Through MXRoute [CentOS, Alma, Rocky]

FrankZ · January 2023

This is a guide on how to set up a sendmail mail relay server to relay outbound mail via MXRoute. You will not need to have a reverse DNS (ptr) record for this VM's IPv4 address or worry about IP reputation. You can use this relay server to relay mail through MXRoute from any other VPS as well.
If you're sending a limited amount of mail this outbound only mail relay server can be setup on a small VM with as little as 1 core, 512MB Ram, 5GB disk. If you send a lot of mail than you should up size your VM accordingly.

In part one of this guide we will set up an outbound only mail relay server that will connect and send mail via MXRoute.
In part two we will show how to set up sendmail on any VPS that you want to relay mail through the outbound only mail relay server that you set up in part one. You can also use postfix or any other mail service on the secondary servers to relay through the outbound only mail relay server.

NOTE: In an effort to make this rather long guide a more reasonable size I have put many of the code blocks that you will need to copy into display pull downs. You will need to click the to see this information.

Part One

Install required packages

CentOS 7:
yum -y install sendmail sendmail-cf cyrus-sasl cyrus-sasl-plain
yum -y remove postfix

CentOS 8, Alma8linux, Rockylinux:
dnf -y install sendmail sendmail-cf cyrus-sasl cyrus-sasl-plain
dnf -y remove postfix

Make sure your hostname is set

Edit /etc/hosts and ensure there is a line [your IPv4] tab [your host name]
Edit /etc/sysconfig/network and ensure there is a line HOSTNAME=[your host name]

Setup the certificates

Get a cert from Let's Encrypt for your mail relay server (I am not showing how to do this here)
Make a subdirectory called "certs" under /etc/mail/:
mkdir /etc/mail/certs

Copy the cert template in this drop down to /etc/mail/certs/sendmail.pem using a text editor

After copying the cert template to /etc/mail/certs/sendmail.pem you will need to modify the following:
1. Replace Put your mail relay host private key here with the private key you received with your certificate from Let's Encrypt for your relay mail server host name.
2. Replace Put your mail relay host certificate here with the certificate you received from Let's Encrypt for your relay mail server host name.

While in the directory /etc/mail/certs execute the commands:
openssl dhparam -out dhparam.pem 4096
and
ln -s /etc/ssl/certs/ca-bundle.crt ca-bundle.crt
and
chmod 600 dhparam.pem sendmail.pem

You should now have three files in your /etc/mail/certs directory

ca-bundle.crt [a soft link]
dhparam.pem
sendmail.pem

The certificate will need to be undated before it expires.
I should add a script to auto update the mail server cert from LetsEncrypt. (coming soon™)

Configure sendmail.mc

Move the original sendmail.mc to sendmail.mc.org:
mv /etc/mail/sendmail.mc /etc/mail/sendmail.mc.org

Copy the code in this drop down to /etc/mail/sendmail.mc using a text editor

divert(-1)dnl

dnl #

include(`/usr/share/sendmail-cf/m4/cf.m4')dnl

VERSIONID(`setup for linux')dnl

OSTYPE(`linux')dnl

dnl #

dnl # Do not advertize sendmail version.

dnl #

define(`confSMTP_LOGIN_MSG', `$j Sendmail; $b')dnl

dnl #

dnl # default logging level is 9, you might want to set it higher to

dnl # debug the configuration

dnl #

dnl define(`confLOG_LEVEL', `9')dnl

dnl #

dnl # Your outgoing mail will be sent out through an external MXRoute server

dnl # Change the friday.mxlogin.com to the MXRoute server to which you have been assigned

dnl #

define(`SMART_HOST',`friday.mxlogin.com')dnl

define(`RELAY_MAILER_ARGS',`TCP $h 587')

define(`confAUTH_MECHANISMS', `EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl

FEATURE(`authinfo',`hash /etc/mail/authinfo')dnl

dnl #

define(`confDEF_USER_ID', ``8:12'')dnl

define(`confTO_CONNECT', `1m')dnl

define(`confTRY_NULL_MX_LIST', `True')dnl

define(`confDONT_PROBE_INTERFACES', `True')dnl

define(`PROCMAIL_MAILER_PATH', `/usr/bin/procmail')dnl

define(`ALIAS_FILE', `/etc/aliases')dnl

define(`STATUS_FILE', `/var/log/mail/statistics')dnl

define(`UUCP_MAILER_MAX', `2000000')dnl

define(`confUSERDB_SPEC', `/etc/mail/userdb.db')dnl

define(`confPRIVACY_FLAGS', `goaway,restrictqrun')dnl

define(`confAUTH_OPTIONS', `A')dnl

PrivacyOptions=nobodyreturn

dnl #

define(`confCACERT_PATH', `/etc/mail/certs')dnl

define(`confCACERT', `/etc/mail/certs/ca-bundle.crt')dnl

define(`confSERVER_CERT', `/etc/mail/certs/sendmail.pem')dnl

define(`confSERVER_KEY', `/etc/mail/certs/sendmail.pem')dnl

define(`confCLIENT_CERT', `/etc/mail/certs/sendmail.pem')dnl

define(`confCLIENT_KEY', `/etc/mail/certs/sendmail.pem')dnl

define(`confDH_PARAMETERS', `/etc/mail/certs/dhparam.pem')dnl

dnl #

define(`confTO_IDENT', `0')dnl

FEATURE(`no_default_msa', `dnl')dnl

FEATURE(`smrsh', `/usr/sbin/smrsh')dnl

FEATURE(`mailertable', `hash -o /etc/mail/mailertable.db')dnl

FEATURE(`virtusertable', `hash -o /etc/mail/virtusertable.db')dnl

FEATURE(redirect)dnl

FEATURE(always_add_domain)dnl

FEATURE(use_cw_file)dnl

FEATURE(use_ct_file)dnl

dnl #

dnl # The following limits the number of processes sendmail can fork to accept

dnl # incoming messages or process its message queues to 20.) sendmail refuses

dnl # to accept connections once it has reached its quota of child processes.

dnl #

define(`confMAX_DAEMON_CHILDREN', `20')dnl

dnl #

dnl # Limits the number of new connections per second. This caps the overhead

dnl # incurred due to forking new sendmail processes. May be useful against

dnl # DoS attacks or barrages of spam. (As mentioned below, a per-IP address

dnl # limit would be useful but is not available as an option at this writing.)

dnl #

define(`confCONNECTION_RATE_THROTTLE', `3')dnl

dnl #

dnl # The -t option will retry delivery if e.g. the user runs over his quota.

dnl #

FEATURE(local_procmail, `', `procmail -t -Y -a $h -d $u')dnl

FEATURE(`access_db', `hash -T<TMPF> -o /etc/mail/access.db')dnl

FEATURE(`blacklist_recipients')dnl

EXPOSED_USER(`root')dnl

dnl #

dnl # The following causes sendmail to only listen on the IPv4 loopback address

dnl # 127.0.0.1 and not on any other network devices. Remove the loopback

dnl # address restriction to accept email from the internet or intranet.

dnl #

DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl

dnl #

dnl # The following causes sendmail to additionally listen to port 587 for

dnl # mail from MUAs that authenticate. Roaming users who can't reach their

dnl # preferred sendmail daemon due to port 25 being blocked or redirected find

dnl # this useful.

dnl #

DAEMON_OPTIONS(`Port=submission,Addr=127.0.0.1, Name=MSA, M=Ea')dnl

dnl #

dnl # The following causes sendmail to additionally listen to port 465, but

dnl # starting immediately in TLS mode upon connecting. Port 25 or 587 followed

dnl # by STARTTLS is preferred, but roaming clients using Outlook Express can't

dnl # do STARTTLS on ports other than 25. Mozilla Mail can ONLY use STARTTLS

dnl # and doesn't support the deprecated smtps; Evolution <1.1.1 uses smtps</td>

dnl # when SSL is enabled-- STARTTLS support is available in version 1.1.1.

dnl #

dnl # For this to work your OpenSSL certificates must be configured.

dnl #

DAEMON_OPTIONS(`Port=smtps, Name=TLSMTA,Family=inet,Addr=127.0.0.1,M=s')dnl

dnl #

dnl # The following causes sendmail to additionally listen on the IPv6 loopback

dnl # device. Remove the loopback address restriction listen to the network.

dnl #

dnl DAEMON_OPTIONS(`port=smtp,Addr=::1, Name=MTA-v6, Family=inet6')dnl

dnl #

dnl # enable both ipv6 and ipv4 in sendmail:

dnl #

dnl DAEMON_OPTIONS(`Name=MTA-v4, Family=inet, Name=MTA-v6, Family=inet6')

dnl #

dnl # We strongly recommend not accepting unresolvable domains if you want to

dnl # protect yourself from spam. However, the laptop and users on computers

dnl # that do not have 24x7 DNS do need this.

dnl #

dnl # FEATURE(`accept_unresolvable_domains')dnl

dnl #

dnl # Also accept email sent to "localhost.localdomain" as local email.

dnl #

LOCAL_DOMAIN(`localhost.localdomain')dnl

dnl #

dnl # The following example makes mail from this host and any additional

dnl # specified domains appear to be sent from mydomain.com

dnl #

dnl MASQUERADE_AS(`mydomain.com')dnl

dnl #

dnl # masquerade not just the headers, but the envelope as well

dnl #

dnl FEATURE(masquerade_envelope)dnl

dnl #

dnl # masquerade not just @mydomainalias.com, but @*.mydomainalias.com as well

dnl #

dnl FEATURE(masquerade_entire_domain)dnl

dnl #

dnl MASQUERADE_DOMAIN(localhost)dnl

dnl MASQUERADE_DOMAIN(localhost.localdomain)dnl

dnl MASQUERADE_DOMAIN(mydomainalias.com)dnl

dnl MASQUERADE_DOMAIN(mydomain.lan)dnl

define(`confHELO_NAME',`myhost.mydomain')

define(`confDOMAIN_NAME',`myhost.mydomain')

CLIENT_OPTIONS(`Addr=Family=inet,Addr=123.123.123.123')

CLIENT_OPTIONS(`Family=inet6,Addr=::ffff:123.123.123.123')dnl

dnl # FEATURE(`require_rdns')

DAEMON_OPTIONS(`Name=MTARelay,Family=inet,Port=2525')

dnl #

LOCAL_CONFIG

dnl # Certificates and keys must also have been configured

O CipherList=ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:!DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

dnl # Disable SSLv2, SSLv3, TLSv1.0 (TLSv1.1 and TLSv1.2 should be supported)

O ServerSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3 +SSL_OP_NO_TLSv1 +SSL_OP_CIPHER_SERVER_PREFERENCE

dnl # Set options required when operating as client to remote servers

O ClientSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3 +SSL_OP_NO_TLSv1

MAILER(smtp)dnl

MAILER(procmail)dnl

dnl MAILER(cyrusv2)dnl

After copying the code to /etc/mail/sendmail.mc you will need to modify the following:
1. Change friday.mxlogin.com to the mail server you were assigned by MXRoute.
2. Change both occurances of 123.123.123.123 to the IPv4 of your mail relay server.
3. Change both occurances of myhost.mydomain to the hostname.domainname of your mail relay server.

After making the above changes execute the command:
m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf

Setup MXRoute authinfo

Copy the code in this drop down to /etc/mail/authinfo using a text editor

AuthInfo:friday.mxlogin.com "U:[your user name]@friday.mxlogin.com" "I:[your user name]@friday.mxlogin.com" "P:[your password]" "M:LOGIN PLAIN"

After copying the code to /etc/mail/authinfo you will need to modify the following:
1. Change both occurances of [your user name] to the username that you were assigned by MXRoute.
2. Change all occurances of friday.mxlogin.com to the mail server you were assigned by MXRoute.
3. Change [your password] to the password that you were assigned by MXRoute.

After making the above changes ensure that you are in the directory /etc/mail and execute the command:
makemap hash authinfo < authinfo

Enable sendmail, saslauthd, and reboot

Execute the following commands to enable sendmail and saslauthd to start on boot and then reboot:
/usr/bin/systemctl enable sendmail.service
/usr/bin/systemctl enable saslauthd.service
reboot

Set SPF DNS record

Add the IPv4 address of this mail relay server and MXRoute to your DNS spf record:
TXT "v=spf1 +ip4:[IPv4 address of this mail relay server] include:mxlogin.com -all"

Is it working ?

Test if everything works as expected by running this command:
echo "Subject: hello" | sendmail you@yourdomain
(replace you@yourdomain with your email address)

Check the log file:
cat /var/log/maillog

If you see stat=Sent (OK, you are sending your mail through MXRoute:

Jan 9 16:40:55 f sendmail[2246]: 309KF3K5001390: to=<you@yourdomain>, ctladdr=<root@[your relay mail server]> (0/0), delay=01:25:51, xdelay=00:00:01, mailer=relay, pri=750282, relay=friday.mxlogin.com. [159.69.65.104], dsn=2.0.0, stat=Sent (OK id=1pEzt1-0004Nf-UP)

If you see stat=Deferred, it is not working:

Jan 9 15:30:02 f sendmail[1848]: 309KF3K5001390: to=<you@yourdomain>, ctladdr=<root@[your relay mail server]> (0/0), delay=00:14:58, xdelay=00:00:00, mailer=relay, pri=390282, relay=friday.mxlogin.com., dsn=4.0.0, stat=Deferred

NOTES

If you make any revisions to /etc/mail/sendmail.mc you will need to execute:
m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf

If you make any revisions to /etc/mail/authinfo you will need to execute:
makemap hash authinfo < authinfo

Then restart sendmail:
/usr/bin/systemctl restart sendmail.service

So that the changes you made will take effect.

Are we done yet ?

If you are NOT planning to have any other VMs relay through this mail relay server you are done. All mail from this VM will relay via MXRoute. While sendmail is listening on port 2525 no mail will be relayed except from localhost.

If you DO want to relay other VMs mail through this mail server to also send their mail via MXRoute then continue below.

Allow other VMs to relay through this server

Open /etc/mail/access in your favorite text editor and add each of the VMs that you want to allow mail to relay through this server by adding their IP address, each on a seperate line, at the bottom of the file as Connect:123.123.123.123 RELAY.

An example file is shown in this drop down. Change 123.123.123.123 to the IPv4 of the VM you wish to allow to relay via your mail relay server.

# Check the /usr/share/doc/sendmail/README.cf file for a description
# of the format of this file. (search for access_db in that file)
# The /usr/share/doc/sendmail/README.cf is part of the sendmail-doc
# package.
#
# If you want to use AuthInfo with "M:PLAIN LOGIN", make sure to have the
# cyrus-sasl-plain package installed.
#
# By default we allow relaying from localhost...
Connect:localhost.localdomain RELAY
Connect:localhost RELAY
Connect:127.0.0.1 RELAY
#
Connect:123.123.123.123 RELAY

After you have added all the VMs you wish to allow to relay to MXRoute via this mail server, and saved the file, execute this command:
makemap hash /etc/mail/access.db < /etc/mail/access

Restart sendmail:
/usr/bin/systemctl restart sendmail.service

You will need to execute the two commands above anytime you make any additions or subtractions to the /etc/mail/access file for the changes to take effect.

Don't forget to open your firewall

To relay mail via your outbound only mail server from other VMs you must open your firewall for port 2525 access.

For firewalld:
firewall-cmd --permanent --zone=public --add-port=2525/tcp
service firewalld stop
service firewalld start

Part Two

In part two we will show how to set up sendmail on any VPS that you want to relay mail through the mail relay server that you set up in part one. It's much easier and faster.

Install required packages

CentOS 7:
yum -y install sendmail sendmail-cf
yum -y remove postfix

CentOS 8, Alma8linux, Rockylinux:
dnf -y install sendmail sendmail-cf
dnf -y remove postfix

Make sure your hostname is set

Edit /etc/hosts and ensure there is a line [your IPv4] tab [your host name]
Edit /etc/sysconfig/network and ensure there is a line HOSTNAME=[your host name]

Edit the sendmail.mc file

Open /etc/mail/sendmail.mc with your favorite text editor and add the lines in the pull down near the bottom of the file between the quoted lines shown above and below the pull down box.

dnl MASQUERADE_DOMAIN(mydomain.lan)dnl

CLIENT_OPTIONS(`Family=inet6,Addr=::ffff:123.123.123.123')dnl
define(`SMART_HOST',`myrelay.mydomain')dnl
define(`RELAY_MAILER_ARGS', `TCP $h 2525')dnl

MAILER(smtp)dnl
MAILER(procmail)dnl
dnl MAILER(cyrusv2)dnl

After copying the code to /etc/mail/sendmail.mc you will need to modify the following:
1. Change 123.123.123.123 to the IPv4 of the server that is being installed.
2. Change myrelay.mydomain to the hostname.domainname of your mail relay server from part one.

After making the above changes execute the command:
m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf

Enable sendmail and reboot

Execute the following commands to enable sendmail to start on boot and start now :
/usr/bin/systemctl enable sendmail.service
reboot

Set SPF DNS record

If you have not done so previously, add the IPv4 address of the mail relay server and MXRoute to your DNS spf record of the domains for which this VM will be sending mail:
TXT "v=spf1 +ip4:[IPv4 address of mail relay server] include:mxlogin.com -all"

Is it working ?

Test if everything works as expected by running this command:
echo "Subject: hello" | sendmail you@yourdomain
(replace you@yourdomain with your email address)

Check the log file:
cat /var/log/maillog

If you see stat=Sent, and Message accepted for delivery you are sending your mail through your mail relay server:

Jan 10 04:27:12 localhost sendmail[2993586]: STARTTLS=client, relay=my.relayserver., version=TLSv1.3, verify=OK, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
Jan 10 04:27:13 localhost sendmail[2993586]: 30A9RCpK2993585: to=you@yourdomain, ctladdr=<root@localhost> (0/0), delay=00:00:01, xdelay=00:00:01, mailer=relay, pri=149367, relay=my.relayserver. [IPv4 for my.relayserver], dsn=2.0.0, stat=Sent (30A9RCkP001947 Message accepted for delivery)

On the mail relay server from part one these are the logs of the same email message successfully being relayed through to MXRoute:

Jan 10 04:27:13 my sendmail[1947]: 30A9RCkP001947: from=<root@the1stvps>, size=11346, class=-60, nrcpts=1, msgid=<202301100927.30A9R2jw2993246@the1stvps>, proto=ESMTPS, daemon=MTARelay, relay=the1stvps [IPv4 of 1st vps]
Jan 10 04:27:16 my sendmail[1949]: STARTTLS=client, relay=friday.mxlogin.com., version=TLSv1.2, verify=OK, cipher=ECDHE-RSA-AES128-GCM-SHA256, bits=128/128
Jan 10 04:27:17 my sendmail[1949]: 30A9RCkP001947: to=<you@yourdomain>, delay=00:00:04, xdelay=00:00:04, mailer=relay, pri=239346, relay=friday.mxlogin.com. [159.69.65.104], dsn=2.0.0, stat=Sent (OK id=1pFAuc-0004BM-Uh)

If you see stat=Deferred Connection timed out , it is not working.
In this case the firewall was not open for port 2525 on mail relay server:

Jan 10 04:24:01 localhost sendmail[2987677]: 30A8S7uH2987677: to=<you@yourdomain>, delay=08:45:57, xdelay=00:00:00, mailer=relay, pri=931045, relay=my.mailrelayserver., dsn=4.0.0, stat=Deferred:Connection timed out with my.mailrelayserver.

If you see stat=User unknown , it is not working.
In this case the IPv4 of this server was not in the /etc/mail/access file on the mail relay server:

Jan 10 22:30:47 localhost sendmail[3093806]: 30B3UkCR3093806: to=you@yourdomain, delay=00:00:01, xdelay=00:00:01, mailer=relay, pri=32612, relay=my.relayserver. [IPv4 of my.relaysever], dsn=5.7.1, stat=User unknown

This will be shown on the mail relay server as the following Relaying denied error.

Jan 10 22:30:47 my sendmail[1363]: 30B3UjUR001363: ruleset=check_rcpt, arg1=<you@yourdomain>, relay=the1stvps [IPv4 of 1st VPS], reject=550 5.7.1 <you@yourdomain>... Relaying denied

Are we done yet ?

Yes, for this guide that is it for now.....
But no you are not done yet. At a minumum servers that send outbound mail should use DKIM in addition to having SPF records and all the good stuff that MXRoute provides.

A warning from MXRoute so as to not cause problems

@jarland said:
It’s worth noting that a slight variation on this kind of setup consumes a significant amount of my time trying to protect the infrastructure from being overwhelmed by pure junk that drags down IP reputation by increasing the association between our IPs and spam folders. These are the big line items:

Almost no one who does this cares that their hostname isn’t an actual valid domain, forcing me to locate all of their server hostnames and add them to a banned sender list so they get errors instead of flooding the queue with junk I can’t deliver or bounce.

That cron job you have set to run every minute sends a notification, and the person who sets this up commonly has all of these emails sent to their Gmail address.

A simple command line interface or a cron job notification lacks the required headers that a legitimate email client would add without the user noticing.

Number 1 causes our mail queues to be packed full of “root@vps{1..999}” emails that I can’t and won’t deliver because they’re not from valid envelope senders. But I can’t say that these are inherently bad and prevent them from going out before I identify each one of them because temporary DNS issues could cause a sending address to appear invalid that isn’t later. So I queue them, but then I audit the queues every day for this junk and use it to build my banned sender list (ex. *@localhost, *@vps1, *@vps.local, etc.).

Number 2 loops in with #1, and the two items work hand in hand to try to overly associate our IP addresses with Gmail’s spam folder, and number 3 comes in here as part of that. A bad sending address, a cron job notification that the user never meant for human consumption (and will never read, save for the 1 in a million user who might), and a lack of valid headers combined with Gmail’s threading feature mean you see one little junk email in your Spam folder, but you actually sent 1,440 junk emails per cron job to Gmail that were all destined to the spam folder. Combine that with the 600 other users doing the same thing, and you then have 864,000 emails from our platform daily, which are guaranteed to land in Gmail’s spam folder. Almost none of those users even meant to send those emails. The users rarely have any idea that they sent them, and they have no plan of gaining anything from it. It’s hard to let all of that through and then tell people I’m focused on doing everything I can to ensure inbox delivery.

All this to say, it’s good to be able to configure your systems to do this, but please keep one thing in mind: The MXroute platform is designed to send emails that are intended for either human consumption or automatic processing. It is not intended to be used as a garbage delivery system for Gmail. It also can’t be used as a garbage delivery system for Gmail, expecting that intentionally sent emails have a high probability of landing in the inbox. It can be one or the other. It can’t be both. Doing everything I can to get intentional emails into the inbox has always been my top focus. So please, if you do this, take a moment to consider what your server is doing and how it may use this configuration in ways you weren’t thinking of at the time.

Do make sure that your sending addresses are always valid. If your hostname isn’t valid, has no MX or SPF records itself, then your cron jobs and other system emails are going to be sending as invalid envelope senders. Think “root@localhost” that’s not valid, even “[email protected]” is invalid if myvps.mydomain.tld lacks valid MX/SPF. Most of that is fine if you’re sending to yourself to be delivered to an inbox on the same MXroute server that your service is hosted on, but if you’re sending these out to remote recipients that’s when you really need to dot your I’s and cross your T’s, making sure you have everything done properly.

AuroraZero · January 2023

Mason · January 2023

Thanks for the contribution and easy-to-follow write-up, @FrankZ!

yoursunny · January 2023

What's the purpose of including the mail relay server's IP address in the SPF record?
This IP wouldn't connect to recipient MX servers.

Not_Oles · January 2023

Hi @FrankZ! Thanks for the great article! I seem to recall hearing somewhere that using the hardfail qualifier "-all" in the spf record might result in emails becoming slightly more likely to be classified as spam. Apparently, and counter intuitively, the softfail qualifier "~all" might work better for deliverability. I wish I remembered the source for this. ¡Saludos!

Ganonk · January 2023

very nice tutor 💯

Flying_Chinaman · January 2023

very nice turtle💯

imok · January 2023

That's a lot of steps.

ehab · January 2023

@imok said:
That's a lot of steps.

i can help you .... give me your passwords,

Mason · January 2023

@imok said:
That's a lot of steps.

"No thanks, God, that's a lot of steps." - @imok

vyas · January 2023

@imok said:
That's a lot of steps.

@FrankZ means business. he is implying, "Step up or be left out."

AlwaysSkint · January 2023

@FrankZ said: If you're sending a limited amount of mail..

FrankZ · January 2023

@yoursunny said:
What's the purpose of including the mail relay server's IP address in the SPF record?
This IP wouldn't connect to recipient MX servers.

Force of habit. On the few occasions that I have had issues connecting to MXRoute and send mail directly from the relay server, I have sometimes forgotten to add the IP of the relay server to the SPF record, which with the hard fail SPF record causes mail to be rejected. Force of habit also has me set up a reverse DNS entry for the relay server by default even though that is also not required to send outbound mail via MXRoute.

@Not_Oles said: Hi @FrankZ! Thanks for the great article! I seem to recall hearing somewhere that using the hardfail qualifier "-all" in the spf record might result in emails becoming slightly more likely to be classified as spam. Apparently, and counter intuitively, the softfail qualifier "~all" might work better for deliverability. I wish I remembered the source for this. ¡Saludos!

Hi Tom and thank you for the compliment on my first attempt at this sort of thing
Most people do use the the softfail qualifier "~all" instead of the hardfail qualifier "-all" and it is reasonable to do so. Personally I do not recommend doing this as the softfail qualifier is taken by many receiving mail servers as "even if the sending server does not match the SPF record it is still ok to accept mail from the server". If someone has set up the outbound mail server as I have shown above, the hardfail qualifier "-all" should not be an issue as the SPF record should always match the sending mail server. The biggest reason I recommend the hard fail in the SPF record is that mail that is sent from email servers that you do not control, who are spoofing your domain as the sender may be accepted with a softfail, with a hardfail those emails should always be rejected by the receiving mail server.

@imok said:
That's a lot of steps.

I was probably overly explicit, so it looks more intimidating than it is. If there is any demand I can turn this into a couple of install scripts so that it would be easier to install. You would still need to set a few things manually like the SPF record, but the script would do most of the heavy lifting.

@AlwaysSkint said:

@FrankZ said: If you're sending a limited amount of mail..

Corrected. If you only found one error in my long post I am going to consider that a success.

AlwaysSkint · January 2023

I'll give this a run through (with CWP installing the core software), when/if the $6 Dallas VPS gets activated.

JDMcPea · January 2023

This is probably obvious to more experienced folks but what is the advantage of setting up an outgoing mail relay on a VPS to send mail mail to an MXRoute account? Wouldn't it be easier to direct your outgoing mail straight to MXRoute instead of having it go through an extra relay point?

Isn't the MXRoute service an outgoing mail relay itself (as well as other things)?

DISCLAIMER: I iz notz zo zmarty

FrankZ · January 2023

@JDMcPea said:
This is probably obvious to more experienced folks but what is the advantage of setting up an outgoing mail relay on a VPS to send mail mail to an MXRoute account? Wouldn't it be easier to direct your outgoing mail straight to MXRoute instead of having it go through an extra relay point?

Isn't the MXRoute service an outgoing mail relay itself (as well as other things)?

DISCLAIMER: I iz notz zo zmarty

Hello. The relay is to send mail out through MXRoute to other mail servers like gmail and such. Not to send email to MXRoute, as you are correct that would not serve any real purpose. The reason I like to relay my outbound mail through MXRoute is that @Jarland is very good at deliver-ability so I don't have to worry about if the mail gets to the recipient.

The idea behind a relay of this type is so that if you have various different web servers that send outbound mail, as an example a forum, you could setup that VPS to relay its mail via the relay server, then through MXRoute, and finally to the destination mail server of the recipient. You could of course just do part one of this tutorial on each server that you wanted to send outbound mail from, if you only had a few servers. I normally have at least 40 servers sending some outbound mail so I find it more convenient to set up a couple of relay servers and have all the other servers send mail through the relays.

Another reason, or use, for the relay is if your VPS host blocks email ports (25, 465, 587) by using the relay which is on port 2525 these servers can still send outbound email via the relay.

jarland · January 2023

It’s worth noting that a slight variation on this kind of setup consumes a significant amount of my time trying to protect the infrastructure from being overwhelmed by pure junk that drags down IP reputation by increasing the association between our IPs and spam folders. These are the big line items:

Almost no one who does this cares that their hostname isn’t an actual valid domain, forcing me to locate all of their server hostnames and add them to a banned sender list so they get errors instead of flooding the queue with junk I can’t deliver or bounce.
That cron job you have set to run every minute sends a notification, and the person who sets this up commonly has all of these emails sent to their Gmail address.
A simple command line interface or a cron job notification lacks the required headers that a legitimate email client would add without the user noticing.

Number 1 causes our mail queues to be packed full of “root@vps{1..999}” emails that I can’t and won’t deliver because they’re not from valid envelope senders. But I can’t say that these are inherently bad and prevent them from going out before I identify each one of them because temporary DNS issues could cause a sending address to appear invalid that isn’t later. So I queue them, but then I audit the queues every day for this junk and use it to build my banned sender list (ex. *@localhost, *@vps1, *@vps.local, etc.).

Number 2 loops in with #1, and the two items work hand in hand to try to overly associate our IP addresses with Gmail’s spam folder, and number 3 comes in here as part of that. A bad sending address, a cron job notification that the user never meant for human consumption (and will never read, save for the 1 in a million user who might), and a lack of valid headers combined with Gmail’s threading feature mean you see one little junk email in your Spam folder, but you actually sent 1,440 junk emails per cron job to Gmail that were all destined to the spam folder. Combine that with the 600 other users doing the same thing, and you then have 864,000 emails from our platform daily, which are guaranteed to land in Gmail’s spam folder. Almost none of those users even meant to send those emails. The users rarely have any idea that they sent them, and they have no plan of gaining anything from it. It’s hard to let all of that through and then tell people I’m focused on doing everything I can to ensure inbox delivery.

All this to say, it’s good to be able to configure your systems to do this, but please keep one thing in mind: The MXroute platform is designed to send emails that are intended for either human consumption or automatic processing. It is not intended to be used as a garbage delivery system for Gmail. It also can’t be used as a garbage delivery system for Gmail, expecting that intentionally sent emails have a high probability of landing in the inbox. It can be one or the other. It can’t be both. Doing everything I can to get intentional emails into the inbox has always been my top focus. So please, if you do this, take a moment to consider what your server is doing and how it may use this configuration in ways you weren’t thinking of at the time.

Do make sure that your sending addresses are always valid. If your hostname isn’t valid, has no MX or SPF records itself, then your cron jobs and other system emails are going to be sending as invalid envelope senders. Think “root@localhost” that’s not valid, even “[email protected]” is invalid if myvps.mydomain.tld lacks valid MX/SPF. Most of that is fine if you’re sending to yourself to be delivered to an inbox on the same MXroute server that your service is hosted on, but if you’re sending these out to remote recipients that’s when you really need to dot your I’s and cross your T’s, making sure you have everything done properly.

JDMcPea · January 2023

@FrankZ said:

@JDMcPea said:
This is probably obvious to more experienced folks but what is the advantage of setting up an outgoing mail relay on a VPS to send mail mail to an MXRoute account? Wouldn't it be easier to direct your outgoing mail straight to MXRoute instead of having it go through an extra relay point?

Isn't the MXRoute service an outgoing mail relay itself (as well as other things)?

DISCLAIMER: I iz notz zo zmarty

Hello. The relay is to send mail out through MXRoute to other mail servers like gmail and such. Not to send email to MXRoute, as you are correct that would not serve any real purpose. The reason I like to relay my outbound mail through MXRoute is that @Jarland is very good at deliver-ability so I don't have to worry about if the mail gets to the recipient.

The idea behind a relay of this type is so that if you have various different web servers that send outbound mail, as an example a forum, you could setup that VPS to relay its mail via the relay server, then through MXRoute, and finally to the destination mail server of the recipient. You could of course just do part one of this tutorial on each server that you wanted to send outbound mail from, if you only had a few servers. I normally have at least 40 servers sending some outbound mail so I find it more convenient to set up a couple of relay servers and have all the other servers send mail through the relays.

Another reason, or use, for the relay is if your VPS host blocks email ports (25, 465, 587) by using the relay which is on port 2525 these servers can still send outbound email via the relay.

@FrankZ Thanks for your answer- I now understand that one advantage would be if my VPS provider blocks the email ports then setting up a relay on another VPS would be a good solution.

I think I phrased my question poorly- what I meant to write was is why not have outgoing email relayed directly through (not to) an MXRoute account? Assuming my host does not block email ports. For example- lets say I have a VPS with a WordPress website and the Contact form is set up to send outgoing messages through MXroute, which then delivers them reliably to Gmail, Outlook, etc.

Or I could have it set up to send the WordPress email first to a relay server that I have set up on another VPS, which will then send the email to MXroute, which will then send to Gmail, etc.

One possible advantage I can think of (please let me know if this is not accurate) is that when I get an account with MXRoute they limit the servers/IP addresses that I can use to send outgoing mail through their service? In that case a setting up my own relay on a VPS would allow an unlimited number of IPs/servers from which I can send email through MXRoute?

FrankZ · January 2023

@JDMcPea Your assessment is correct. The relay server in Part 1 can be setup on any VPS. In your example of the VPS with the WordPress site you could set up the mail server as described in Part 1 on the same VPS as the WordPress site and do not do Part 2.
You would need to set WordPress to use Mail SMTP instead of the default wp_mail (PHP mail) by going to the menu item "WP Mail SMTP", choosing "Other SMTP" and entering localhost as the SMTP server. In this case I would also suggest setting up OpenDKIM, on the same VPS which will be a tutorial I will be putting up shortly as a companion to this one or if you do a google search I am sure you can find a tutorial regarding OpenDKIM that you can use. It this scenario your email would go directly to MXRoute from your WP VPS with no second VPS but your email is still being relayed via MXRoute.

flips · January 2023

I guess you would also add a step for autoupdating the .pem, tied into letsencrypt setup ... (Unless I missed that when reading through)

FrankZ · January 2023

@flips said:
I guess you would also add a step for autoupdating the .pem, tied into letsencrypt setup ... (Unless I missed that when reading through)

Thank you for pointing that out, you are correct, that step is not included and should be. I will make a note in the above that the cert step should be redone as the cert expires.

flips · January 2023

For Lighty I found Dehydrated easy to use to add a hook/script to generate the pem and reload the web server ...

ariq01 · March 2023

I was looking for this to setup my fail2ban notifications, and I found your article.
Thanks man

*edit, sorry didn't mean to necropost, can I cite this thread in my blog post?

FrankZ · March 2023

@ariq01 said: can I cite this thread in my blog post?

Feel free.

legendary · March 2023

300 mails/hour could be easily exhausted with buggy cron. Be sure to tight up your system messaging before relay setup.

I would like to see proper guides for exim, postfix and qmail. And some amavis rules maybe? Lets get fancy!

ariq01 · March 2023

I'm using Ubuntu 20.04,

- using libsasl2-2 sasl2-bin libsasl2-modules rather than cyrus-sasl cyrus-sasl-plain
- replace everything /sendmail-cf/ to /sendmail/cf/ in Makefile
- replace on /etc/mail/sendmail.mc to from sendmail-cf/ to sendmail/cf/ too

Everything on step 1 completed, vm and service restarted, but still no luck

Mar 19 09:35:27 email sendmail[2254]: NOQUEUE: SYSERR(root): hash map "Alias0": unsafe map file /etc/aliases.db: Permission denied
Mar 19 09:35:27 email sendmail[2254]: NOQUEUE: SYSERR(root): Cannot create database for alias file /etc/aliases
Mar 19 09:35:27 email sm-mta[2163]: restarting /usr/sbin/sendmail-mta due to signal
Mar 19 09:35:27 email sm-mta[2163]: error: safesasl(/usr/lib/sasl2/Sendmail.conf) failed: Permission denied
Mar 19 09:35:27 email sm-mta[2271]: starting daemon (8.15.2): SMTP+queueing@00:10:00
Mar 19 09:35:27 email sm-mta[2271]: STARTTLS=server: file /etc/mail/certs/ca-bundle.crt unsafe: No such file or directory
Mar 19 09:35:44 email sendmail[2299]: 32J9ZitB002299: from=root, size=33, class=0, nrcpts=1, msgid=<[email protected]>, relay=root@localhost
Mar 19 09:35:44 email sm-mta[2300]: 32J9ZioN002300: SYSERR(root): collect: Cannot write ./df32J9ZioN002300 (bfcommit, uid=0, gid=120): Permission denied
Mar 19 09:35:44 email sm-mta[2300]: 32J9ZioN002300: from=<[email protected]>, size=304, class=0, nrcpts=1, proto=ESMTP, daemon=MTA, relay=localhost [127.0.0.1]
Mar 19 09:35:44 email sendmail[2299]: 32J9ZitB002299: [email protected], ctladdr=root (0/0), delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=30033, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: 421 4.3.0 collect: Cannot write ./df32J9ZioN002300 (bfcommit, uid=0, gid=120): Permission denied

*Edit: nevermind, I'm using msmtp msmtp-mta right now

somik · May 2023

@Mason said:

@imok said:
That's a lot of steps.

"No thanks, God, that's a lot of steps." - @imok

New tutorial:
Step 1, Install Virtualmin Panel
Step 2, From Virtualmin Panel, Go to Webmin > Servers > Postfix Mail Server > SMTP Authentication And Encryption
Step 3, Change "Send outgoing mail via host", "Use SASL SMTP authentication", "SMTP login to outgoing mail host"

That is what I use to send emails through my prefered SMTP relay. It works perfectly for my use case.

How To Setup A Mail Relay Server To Relay Mail Through MXRoute [CentOS, Alma, Rocky]

Part One

Install required packages

Make sure your hostname is set

Setup the certificates

Configure sendmail.mc

Setup MXRoute authinfo

Enable sendmail, saslauthd, and reboot

Set SPF DNS record

Is it working ?

NOTES

Are we done yet ?

Allow other VMs to relay through this server

Don't forget to open your firewall

Part Two

Install required packages

Make sure your hostname is set

Edit the sendmail.mc file

Enable sendmail and reboot

Set SPF DNS record

Is it working ?

Are we done yet ?

A warning from MXRoute so as to not cause problems

Comments