![\"Forwarding](\"https://vic.demuzere.be/assets/articles/images/cdS9v3btV7quai0cIHaCm1ubUdI98ZJQ.png\")
My personal e-mail address is managed by Google for Work, as the spam filtering in Gmail is better than anything I could do myself. The problem is that I have a few additional domains that don't have any e-mail users. I have to use an external forwarding service as my grandfathered Google account doesn't allow me to add more domains. Fortunately setting up Postfix to forward mail from my other domains was pretty easy.
\n
This also works if you're using a normal hosted webmail service (gmail, hotmail, yahoo...) and want to receive e-mail from your own domain straight to your usual inbox. This allows you to use your favorite e-mail service yet look a bit more professional.
\nThe Postfix server in my example receives an e-mail addressed to email@example.com and forwards that to vic@demuzere.be. Note that this breaks SPF but keeps DKIM signatures intact. An intact DKIM signature is enough to pass DMARC validation.
Postfix is included in the Debian repositories. Exim is installed by default and will be removed when you attempt to install Postfix. Unless you're already using e-mail on the server this shouldn't be an issue.
\napt-get install postfix\nWhen the configuration dialog pops up, simply select No configuration.
The relevant configuration is located in /etc/postfix/main.cf.
Define for which domains you want to forward e-mail. Note that you can specify multiple virtual domains. We let Postfix know that our address mappings will be listed in the virtual file inside the configuration directory.
virtual_alias_domains = example.com example.net\nvirtual_alias_maps = hash:/etc/postfix/virtual\nNow that postfix knows for which domains to accept e-mail, we can start creating the individual addresses inside the virtual file. The syntax is a simple key-value pair list. Note that it's also possible to define more complex regex-based addresses, but I didn't need that for my simple setup.
email@example.com vic@demuzere.be\nother@example.com destination@gmail.com\nthird@example.net hello@hotmail.com\nIn case you want to forward all e-mail (catch-all) for a certain domain, simply leave away the user part. If you're setting both specific users and a catch-all address, the latter will only work for unknown users.
\n@example.com destination@gmail.com\nSave the changes by running postmap on the virtual file.
postmap /etc/postfix/virtual\nIn my case, the destination e-mail address is on my own domain. Even though e-mail for the domain is hosted elsewhere, Postfix thought it was responsible and kept the e-mail instead of forwarding it. This was solved by setting the domain for the Postfix server to a subdomain that I don't actually use.
\nmyhostname = myserver.demuzere.be\nmydomain = myserver.demuzere.be\nmyorigin = myserver.demuzere.be\nNote that this solution only works if you're using the Postfix server to forward to external services. In case you're using the server for actual mailboxes, watch out when modifying these settings!
\n","url":"https://vic.demuzere.be/articles/forwarding-email-postfix-debian/","date_published":"2015-04-16T10:50:00Z","date_modified":"2026-05-13T17:33:24Z","language":"en"},{"id":"https://vic.demuzere.be/articles/email-authentication-with-spf-dkim-and-dmarc/","content_html":"The Simple Mail Transfer Protocol, used for sending e-mail messages, has been written in the 1970s. It was not designed to be secure.
\nSMTP is a pretty simple protocol, and it follows the idea of classic mail: You write the address on the front of the envelope, your own address on the back, and you send it. There is no way for the recipient to check if the address you've written on the back is really yours.
\nE-mail has become the most important means of "serious" online communication. Accounts on most sites are connected to an e-mail address, including e-commerce. If you receive an e-mail from your bank, how do you know if it's really your bank that has sent the e-mail?
\nYou can't, not automatically.
\nYou could phone your bank and ask them if they've sent it. But that's not something most people would do. People want to read their e-mail and usually trust the sender line shown in their mail client.
\nThere has been a solution for this problem for ages. Standards like S/MIME and OpenPGP allow you to sign e-mail messages. Everyone that trusts your public key can be pretty sure you are who you say you are.
\nMost desktop e-mail clients support S/MIME and OpenPGP, but the number of users is small. A select group of people that really cares about privacy and security uses it for sending e-mails. (OpenPGP is used for other things as well: A lot of GNU/Linux packages are signed using OpenPGP).
\nThis solution isn't suitable for the masses though. Keeping your private certificate secure (and maintaining a web of trust in the case of OpenPGP) is too much work. It should be easier!
\nPeople that lack the required knowledge to set up their own e-mail server usually use the servers of their provider, or a webmail service. This is where we have to implement the authentication if we want to reach everyone.
\nA few standards have been developed to make this happen.
\nSPF allows server administrators to keep a whitelist of servers allowed to send e-mails for their domain. The server receiving the e-mail can then check if it came from an allowed IP.
\nThe whitelist is stored in a TXT or SPF record in DNS. As the domain administrator is (or should be) the only one able to change the DNS records for his domain, this is considered a safe place to store the whitelist.
\nFor example, the SPF record for demuzere.be:
\ndemuzere.be. IN TXT "v=spf1 include:_spf.google.com -all"\ndemuzere.be. IN SPF "v=spf1 include:_spf.google.com -all"\nThis record basically tells you that you should read the SPF record on _spf.google.com, and disallow all other servers.
\nThe official SPF website has a page with tools for setting up and checking SPF records.
\nThe problem with SPF is that it breaks when an e-mail forwarder forwards your e-mail.\nIn this case, the receiving server will see the IP of the forwarder, and not that of the original sender.\nFor the same reason, this also breaks mailing lists.
\nOne solution that does not break forwarders is S/MIME and OpenPGP, as the message containing the signature stays intact when forwarding an e-mail.\nSo why not use this same technique on the server?
\nThat's where DKIM comes in!\nIt signs the e-mail body and a few critical headers on the server before sending it to the recipient.
\nThe public key is read from DNS (for the same reasons the whitelist for SPF is stored there).\nThe receiving server can validate the message using the public key and a signature in the e-mail headers.\nForwarders and mailing lists keep these headers intact, and don't break DKIM.\n(Unless they're not configured correctly..)
\nFor example, the DKIM record for demuzere.be:
\ndemunet._domainkey.demuzere.be. IN TXT "v=DKIM1\\;k=rsa\\;p=MIGfMA [..] AQAB\\;t=s"\nDKIM allows you to set multiple public keys (the key name is "demunet" in the record shown above). The reason to allow this is simple: You might want to let a third party sign e-mails on your behalf. Companies using a third party service for sending bulk e-mail can give them a separate key, and revoke it if needed.
\nBut how should the receiving server know if it should check for SPF and DKIM records? SPF can be checked easily:\nIf there is no SPF record, the sender doesn't use it. But what for DKIM? You have to know the public key name in order to check if it exists.\nThere is no way to know if an unsigned e-mail should have been signed.
\nThere have been a few proposals on how to solve this. One of them was Author Domain Signing Policy (ADSP).\nIt wasn't popular: The biggest webmail providers didn't implement it, and then it simply doesn't work.
\nThe latest try is DMARC.\nBehind the ridiculously long name hides yet another DNS record.\nThis time it allows you to specify a policy as to how the receiving server should threat your messages.\nThe difference with ADSP is that DMARC also supports reporting.\nReceiving servers can send you reports about the number of messages it received from your domain, what they did with them, and why they decided to do that.
\nYou can suggest what to do with messages that fail DKIM and SPF tests.\nPossible options are reject, quarantine (sends them to the spambox most of the time) and none.\nThis last option simply sends reports, but doesn't stop the e-mails from reaching the inbox if something is wrong with them.
\nA last example, the DMARC record for demuzere.be:
\n_dmarc.demuzere.be. IN TXT "v=DMARC1\\;pct=100\\;p=reject\\;adkim=s\\;aspf=r"\nMy policy is to reject messages that fail DKIM tests (all messages should be signed). My SPF policy isn't set to strict: As explained earlier, this might cause forwarders and mailing lists to fail.
\n