With Google Apps no longer being free for small businesses/teams, I'm left pointing my MX records at my application server. I'd still like to receive email at a Gmail address sent to the domain associated with aforementioned MX records.

I have looked at installing sendmail and configuring /etc/mail/virtusertable to contain something like

@mydomain    myemail@gmail.com

I have also looked at installing postfix and modifying /etc/aliases with

admin:  myemail@gmail.com
team:  myemail@gmail.com

Regardless, when I send email to team@mydomain.com the emails never seem to make it to my application server (for example, /var/log/maillog shows nothing added), and definitely don't make it back to my Gmail account.

I am fine discarding postfix and/or sendmail for another alternative; I'm simply looking to accept email on my application server that does nothing but forward said email to a Gmail account. I don't need/want any real email accounts on the server, and this is the only domain on the server.

  • If you want to redirect email to different domains on per-address basis, try using transport tables. serverfault.com/a/184228/23300 – Nic Apr 18 '13 at 6:31
  • How many users do you plan on having? Are you sure this solution is going to be cheaper (and more reliable) than the $50 per user per year that Google Apps now costs? – Ladadadada Apr 18 '13 at 10:58

With sendmail you need to add something like this at the end of you /etc/mail/sendmail.mc:

Kuser user -m -a.FOUND

R$- < @ $=w . > $*        $: $(user $1 $) < @ $2 . > $3
R$- . FOUND < @ $=w . > $*          $@ username < @ gmail.com. > $3

That would forward any email directed to a user of the system (listed in /etc/passwd) to your username@gmail.com. Keep in mind that the left hand side of the rules is separated from the right hand side of the rules with tabs and not spaces. So do not copy paste, type the above rules instead. After that you need to run /etc/mail/make to build sendmail.cf and service sendmail restart in order for the changes to take place.


For starters you need to get a working installation of postfix or sendmail on your server which is a real pain in the ass. Relaying email on postfix once you get it up and running however is a straight forward process.


I'm actually running a postfix/dovecot server that is doing exactly what you need.


If nothing appears in you postfix logs, it looks like you're server doesn't get the incoming connection, because it doesn't feel responsible for the domain you want to send the mail to.

Virtual User and Domain tables are a good start, but make sure postfix feels responsible with adding the domain to "mydestination" like this:

mydestination = localhost, mydomain.tld, mail.mydomain.tld

Don't forget to hash it first:

postmap /etc/postfix/virtusertable

Include your virtusertable in the alias maps:

virtual_alias_maps = hash:/etc/postfix/virtusertable

and last but not least, check that postfix is actually getting the request

dig mydomain.tld MX

and your domain and check for the MX records, that they point to the postfix server. If you just changed it today / MX DNS entries, it could take up to 24hours before the changes become visible because of DNS caching at your DNS, yours provider DNS or other DNS servers of servers which send mail to mydomain.tld


With sendmail you may add something like this to your /etc/mail/sendmail.mc:

define(`LUSER_RELAY',`error:550 User unknown')

It should reject emails to unknown local users after (LUSER_RELAY) and send messages to remaining local email address to username@gmail.com (MAIL_HUB). It is applied after alias expansion and ~/.forward file processing.


  • The method will not handle well rejects by destination email e.g. caused by antispam procedure.
  • DO NOT use the recipe with FEATURE(stickyhost)
  • I post it mainly as an alternative to custom R lines based solutions.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.