Setting up gmail as a relay host in postfix (without creating certificates)

When your linux box needs to send email (e.g., mail sent by a webpage, cron job output, etc), postfix can normally send the email directly to the recipient. However, if your ISP blocks port 25 outbound, or you want to keep a nice log of all outgoing messages, or want replies to arrive in your gmail account, this may not be ideal. One alternative is to use a Gmail as a relay host, i.e., postfix will basically pretend to be a gmail user, and send all mail through that account.

There are already a number of guides on the internet explaining how to set up postfix to relay outgoing email via Gmail:

These guides are excellent, I wouldn’t have been able to set up my server without them. However, they all demand the creation of CAs and self-signed certificates. If you don’t know what I’m talking about, then you’ve come to the right place! And if you do know what a CA is, then the purpose of this post is to point out that creating one is completely pointless in this case. So I’m proud to announce…

A simplified guide: setting up postfix to relay through Gmail

  1. Add the following lines to /etc/postfix/
    relayhost = []:587
    smtp_use_tls = yes
    smtp_sasl_auth_enable = yes
    smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
    smtp_sasl_security_options = noanonymous
    # The following line is optional, but recommended (see below)
    smtp_tls_CAfile = /etc/ssl/certs/Equifax_Secure_CA.pem

    The last line is not necessary for postfix to successfully send messages, but it prevents ‘certificate verification failed’ warnings. I believe the /etc/ssl/certs/ directory is populated by installing OpenSSL.

  2. Place the following in a new file at /etc/postfix/sasl_passwd:
  3. Hide your password, and do some other magic stuff:
    $ cd /etc/postfix   
    $ postmap sasl_passwd          # creates sasl_passwd.db
    $ chmod 600 sasl_passwd sasl_passwd.db
  4. Restart postfix:
    $ service postfix restart      # this varies from system to system
  5. Test:
    $ echo 'It works' | mailx -s 'Test message'

What if doesn’t work — debugging

If you find that the recipient (e.g. doesn’t receive an e-mail, have a look in the log files. They’re located in different places depending on your configuration settings/distribution, but have a look in /var/log/mail.err, /var/log/maillog or /var/log/mail for starters. If the problem isn’t self-evident from looking at these messages, have a look at the official Postfix Debugging Howto for more help — or, leave a comment on this post!

Forwarding emails sent to usernames on your linux box

Utilities (e.g. at, cron, mdadm, etc) often send emails to the user if errors occur. The emails default to username@domain, where domain is the FQDN of the system. If you want these messages to be sent to a different address, create .forward files in the home directory of the relevant users:

# Forward messages for your user
$ echo > ~/.forward      
$ echo 'It works' | mailx -s 'Test message' username

# Forward messages for the root account
$ echo > ~root/.forward  
$ echo 'It works' | mailx -s 'Test message' root

Setting the ‘From’ name

Take with a grain of salt, there’s probably a better way than falling back on the sendmail emulation provided by postfix:

$ sendmail -F 'Name to Appear in From Field'

But wait, if we provide no certificate, will the emails be encrypted? [Optional!]

Yes. The email is encrypted; this can be confirmed with tcpdump. Encryption is accomplished using TLS (see Diffie–Hellman key exchange for an explanation of how two computers can communicate securely with no pre-arranged secrets or certificates.) Certificates are quite separate; they are used to verify whether the Gmail server is really the Gmail server, not some imposter. Of course, certificates and encryption are easily confused, as they’re always found together — there’s no point preparing a secure, encrypted channel to an imposter.

So, Gmail provides the certificate; and postfix can verify the authenticity of this certificate using file provided via smtp_tls_CAfile in step 1 above. The connection is then secured. Postfix then proves its identity using the plain old username and password (which is pretty much the only identity proof that we have at our disposal as a mere Gmail user) and the emails can be sent.

But why does postfix have configuration options to accept certificates and keys? What about configuration options starting with smtpd_ ? [Optional!]

The server/client distinction is very clear cut with many protocols, like HTTP — the web browser is the client, the web host is the server. Postfix is not so straightforward, because it acts as a middle-man — it’s a server when its receiving mail from the outside world, and then it’s a client when it relays that mail towards its final destination. So, postfix can be thought of as an SMTP server (smtpd) and client (smtp) combined. The configuration options are divided into smptd_* and smtp_* accordingly.

If we wanted our postfix server to accept mail on a secure connection from other computers on the network, and provide a certificate proving its authenticity to these other computers, then this is when these other options would become useful. But because we’re only accepting mail from localhost (for now), these options are completely irrelevant.

Leave a comment


  1. Maca

     /  July 25, 2011

    Good work Bob! Hopefully the start of a very fruit-bearing blog.

  2. Max

     /  February 28, 2012

    I follow all steps but I don’t receive the test email at step 5…

    • Robert

       /  February 28, 2012

      Hi Max,

      Sorry to hear that it didn’t work out on the first attempt. Have a go at looking in the log files, which are in /var/log/mail.err or /var/log/maillog or /var/log/mail, depending on your set-up.

      Please let me know what you find, regardless of whether or not you solve the problem. I’d be keen to update my instructions if I’ve missed a step!


      • Max

         /  February 28, 2012

        Hi Robert,
        I copy&paste the row

        “smtp_tls_CAfile = /etc/ssl/certs/Equifax_Secure_CA.pem # optional”

        and left “# optional” part, so postfix could not find CA file… 🙂

        Now i correct the line and mail go fine! 🙂

        Sorry for my English and thank you a lot for your post! 🙂


        • Robert

           /  March 1, 2012

          Hi Max,

          Thanks so much for this tip! I had blindly assumed that one could comment out part of a line, but evidently postfix configuration files only allow entire lines to be comments. I’ve updated the post accordingly.

          Thanks again,

  3. David Grant

     /  October 31, 2012

    I love the page header…. where can I get it? Seriously, I want it!

    Great tutorial, will be setting it up this way in school, since we are blocked from port 25.

  4. javi

     /  January 10, 2013

    good article…. takes me here….

    only one suggestion..the way to change the sender address:

    mail -s “subject” — -r “”


    doesnt work for my officce 365 account but gives me a better output error that sendmail.

    warning:[] offered null AUTH mechanism list


  5. Jon A

     /  November 20, 2014

    I followed what you have above, but my question is what else would need to be configured on postfix? reason I am asking when I setup the test command im not getting any out put and oddly enough gentoo isnt logging anything for me 🙁

    • Jon A

       /  November 20, 2014

      it turns out they are there but in my users .Maildir in their home folder 🙁

      • Robert

         /  November 20, 2014

        Cool, glad you figured it out! Thanks for pointing it out, hopefully other people stuck with the same issue will see your Q&A 🙂

        • Jon A

           /  November 21, 2014

          Hi Robert, Should I also be seeing the email as well in the users gmail inbox?

          • Jon A

             /  November 21, 2014

            disregard my last comment it seems like im having authentication issues 🙁 emails are bouncing and not being delivered it seems like I cannot sign in 🙁

Leave a Reply

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