Skip to content →

How to use your private gmail account with you own domain

Using your own mailserver as a forwarding server to Gmail.

In this article I try to describe how email works and how you can use your own server as a forwarding server to your google mail address. So in the end you can use your own yourname@yourdomain.com address with Google Mail or Google Inbox.

The company I work at runs regular short talks about stuff that interests us. These are my notes for a talk about Email and mailservers.

So this is not a detailed instruction on how to setup all the bits and pieces, but it will give you an overview on what parts you’ll have to put together. There is lots of great documentation on the internet for every single part.

Incoming Mail

MX Records

A sending email server looks for the MX record to determine the destination host.

After looking up the destination hosts IP. The sending server tries to deliver the mail to this server. The receiving server has to handle it now. Since email is almost unusable these days without spam protection, the most effort on this setup goes into the protection against spam email and preventing the google servers from blocking us.

The receiving mailserver needs to feel responsible for handling incoming mails to that domain:

Anti-Spam Rules

There are 2 principles of spam prevention:

  1. Server only restrictions and filtering.
  2. Checks where the sender and the receiver implement a certain protocol to check the validity of the mail.

There are multiple ways and stages on how to prevent spam email from going any further. On a server you should try to put the most expensive (in terms of effort the server has to put into) last.

  1. Simple checks on the mailserver whereas the sending system fulfills certain requirements, such as
    1. valid static ip address
    2. has a reverse dns entry
    3. submits a valid sender domain
    4. isn’t listed on a blacklist
  2. Virus and pattern checking on the server

The simple checks postfix does on my system look like this:

This just allows everything that comes from the localhost address and everything that I put into postfix via an sasl authenticated connection (these are mails that I send myself, so usually no spam). Than there are a few very simple checks e.g. if the sending server has a valid hostname. At the end there are a few more expensive blacklist lookups. The vast majority of spam is blocked just by these rules.

Spamassasin/Amavisd-new

After an email passed the mailservers first line of filtering I pass the mail through amavis (and spamassassin) which performs mainly a pattern matching and assigns every email a certain probability of being spam. I also do a quick virus check through clamav for every mail with attachments here. All I can say here is, that I basically use the default configuration that comes with the Debian/Ubuntu packages.

During this step I also check for the SPF and DKIM headers. These just add (or subtract) to the probability of an email being spam, but are never for themself a sufficient indicator of a mail being spam or ham.

The result of this check gets added as a header and if the probability of this mail being spam is higher than a certain number, the mail will be dropped.

SPF/SRS

Whereas the usefulness of SPF is discussable, I decided to deal with it. SPF mainly is a list of mail servers that is allowed to send emails for a certain domain. So the receiving server can do a DNS lookup and check if the mail it is processing comes from an allowed server.

You can find a good description of SPF and all its problems here: https://en.wikipedia.org/wiki/Sender_Policy_Framework

You can see here that at point of writing this, I still had my providers mailservers listed in this setting.

As you can imagine this has a lot of drawbacks:

  1. Now everyone using the mailservers of ispgateway.de is allowed to send mail that comes from my domain. Imagine you have to do this with the google mail servers. SPF gets practically useless because of this.
  2. Another big problem with SPF is forwarding. Since a forwarded mail still comes from a domain we do not control, but our mail servers, to the receiving end (in our case google) appears to be sending mails for them, SPF will always fail.

Because of point two, SRS got invented, which rewrites the senders return-to header. After doing that every mail we forward appears to be coming from our server and looks something like this:

At this point we really made SPF useless. Now all the mails forwarded from our server will not get downrated because of a false SPF header. The problem is that we need to be extra careful not to forward to much spam. Otherwise google might start thinking that our server is sending out a lot of spam and blocks us.

I still decided to implement SRS and use postsrsd for it.

https://de.wikipedia.org/wiki/Sender_Rewriting_Scheme

DKIM

After everyone realized that SPF was kindof a failure DKIM came up. DKIM uses a public private key process to verify that:

  1. A mail got sent from a server that knows that domains private key and is therefore an eligible sender for that domain.
  2. A mail did not get modified on the way from the sending to the receiving server.

https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail

DKIM is a quite efficient tool against phishing. Whenever in doubt if the mail you got is legit, look for a valid DKIM header. Most of the “big” sites use it and google verifies it.

valid DKIM from paypal
valid DKIM from paypal

To get this to work you need to setup opendkim and put your public key into a DNS TXT record:

There is a private key that belongs to this and only our mailserver knows. It now can sign every mail. The receiving server can use the public key to check if that signature is valid. I verify the dkim signatures and let amavis let the check influence the spam rating.

DMARC

DMARC is sort of a meta system for DKIM an SPF. It tells a receiving mailserver how it should handle failed SPF or DKIM checks. It also uses TXT DNS entries:

With p=reject I could tell every receiving mailserver for my domain to just reject every message that does  not have a valid DKIM signature and SPF header. I don’t use it, since sometimes I just like to test things out and than get confused when my mails just get dropped.

Funny story though is that some big time players have their DMARC entry very wrong:

But their Packstation reminder mails get send out without a valid DKIM, so google just does not accept them and my server gets this in return:

However sometimes they pass. I do not know how google handles this, but I get these mails in my spam folder every once in a while (and they are legit). There you can see that the dmarc check fails because of a missing DKIM signature.

failed dkim dhl

So be carefull if you set this for your domain and make very sure that you configured your shit correctly. Otherwise your mails might get dropped.

Aliases/Forwarding

After all these checks got applied and the mailserver is still thinking that the mail is worth delivering we just have to make sure that every mail we accept gets forwarded to our Gmail account:

See this link to see a visual representation of this setup working:

https://kaitimmer.de/cgi-bin/mailgraph.cgi

You can see, that the vast majority of spam is just plain rejected by one of the early stages of postfix basic checks. The more expensive checks do not contribute that much.

At this point we talked about all the needed building blocks for receiving emails. Now the only thing left to do is to forward them to our google mail account. Since forwarding is the same thing as just sending out an email, we now need to build a fully functioning sending email server, which than in return is also able to forward all our mails.

I monitor my server with statuscake. There are lots of free services out there, just pick one and make sure you get your notifications directly to your gmail address (or a completely different account that you read).

Outgoing Mail

Authentication

A big risk is that you might become an open relay, so that everyone can send mail via your server. Spammers scan IP ranges for open relay mail servers all the time. Make sure you read up on how to prevent that  and run an open relay test as soon as you open up your smtp ports to the internet.

Postfix works well with saslauthd.

SSL

To allow your server to send and receive emails through an ssl encrypted connection you’ll need a valid certificate. I use letsencrypt for that.

Since the letsencrypt certificates are only valid for a few month, the certbot-auto tool checks if there are certs that need to be renewed and if so gets a new valid certificate.

The check_new_cert.sh just checks if we got a new certificate and restarts postfix otherwise postifx is not able to use the new cert.

You can (and should) test your whole sending setup here:

http://www.mail-tester.com/

Published in Solutions

Comments

Leave a Reply

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