News & Announcements, Tutorials/Tips, Ubuntu Server

How to configure Ubuntu 14.04 server to forward root mails to your email address

This short tutorial shows how to configure a Ubuntu 14.04 Cloud server to forward system-generated mails sent to the root account to your email address.

Why would you want to forward mails sent to root to an email address?

Because most properly-configured Cloud servers are managed using a (normal) user account with sudo (root) privileges. So unless you switch to root while logged in as a normal user, and then type the mail command, you will not see those emails.

Here, for example, is the output of the mail command after switching to root on one of my servers:

That’s a lot of unread messages. Some of those messages might contain important information about the server, some of which could be the result of cron jobs or from system alerts triggered by unauthorized user activity. For example, here’s the content of one of those emails sent to the root account after an unauthorized (and failed) user activity:

Related Post:  Creativity: The key to the Virtual Reality gambling experience of the future

That’s an alert you won’t see if you don’t read emails sent to root. So this tutorial will show you how to configure the server to make it easy for you to read such emails – by sending them to your email address. This tutorial assumes, of course, that you have access to and manage a Cloud server running Ubuntu 14.04.

Related Post:  5 things to do that will boost the security profile of your smartphone

To forward roots mail to an email address, open the /etc/aliases file with your favorite text editor. The default content should read:

Edit it so that it reads:

That will forward all system-generated emails sent to root to the specified email address. Replace with your real email address. Save and close the file, then run the newaliases command to effect the change.

That’s it. If you don’t receive the expected emails, check you Spam folder.

Please share:

We Recommend These Services

Register now for Blockchain & Decentralized Tech SuperSummit, international conference on blockchain technology in Dallas, TX (USA), April 1 - 4, 2019

Reasons to use control panel for your server

Learn how to trade cryptocurrencies using technical and fundamental analyses at BDT SuperSummit

Launch an SSD VPS in Europe, USA, Asia & Australia on Vultr's KVM-based Cloud platform starting at $5:00/month (15 GB SSD, 768 MB of RAM).


  1. Nice tip, though you may want to specify:

    The server needs to not be behind a NAT/router, or the remote MDA will not accept it : your box will introduce itself with “EHLO methisyou” but the MDA’s reverse lookup will detect you are “actually” “public.ip.number” (your public IP)

    Do you know of a simple setup that solves this reverse-lookup barrier – either by causing the sendmail MTA to declare itself as necessary, or by using another MTA that can still be used in bash scripts…? 🙂

    • [subscribe] oops 🙂

    • I hope you realize that a real domain was removed from that code block. The only real issue you have to worry about is if the receiving end starts marking your emails as spam. I’ve never had that happen, but that’s the kind of problem that SPF, DKIM and OpenDMARC are designed to solve.

      • I know that if this fictional is considered public in this example – however I was wondering if there was an easy way to allow this to work in the general use case (id est, NAT notwithstanding) with the standard sendmail

        I am referring specifically to a use case of the server you are managing/monitoring being behind a NAT which is trying to directly access the MDA of something like a mail address. In such a setup, managed-server tries to connect to (say Google’s) MDA saying “EHLO managed-server” ; Google then traces back your IP with DNS reverse lookup to find that you’re showing as some which does not resolve to “managed-server” and rejects the message altogether…

        • No, I’ve not considered that particular use case, but if your server is sitting behind a router and the router’s public IP is also your server’s, wouldn’t the process of establishing an RDNS record follow the standard process of setting up such a record?

          Also, isn’t RDNS just one reason why emails coming from a particular box/domain might be rejected? If the RDNS test fails, but the emails are signed using DKIM, there’s a very strong chance that the receiving server will not mark them as spam. That makes it look/sound as if RDNS and protocols like DKIM are totally, completely different things, but in reality, doesn’t DKIM accomplish the same thing as RDNS?

          For the record, I’ve been forwarding these emails to a GMail, Yahoo, and Fastmail accounts without ever establishing an RDNS record or even using SPF or DKIM and they’ve always been accepted. The only time Google’s SMTP server rejected my emails was when the From address was not a real email address.

Leave a Comment

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