Building a Bulletproof Postfix Mail Server on Linux
If you have ever tried to run a business using the default email service provided by cheap shared hosting, you know the pain. One neighbor on the same IP address sends a blast of pharmaceutical spam, and suddenly your invoices to clients in Oslo are bouncing. Your IP is blacklisted by Spamhaus, and you spend three days begging a sysadmin to move you to a different node.
It is time to stop the madness. You need your own MTA (Mail Transfer Agent).
Running your own mail server has a reputation for being difficult. In reality, it is about discipline. If you control the stack, you control your reputation. This guide focuses on Postfix, the modular, secure replacement for Sendmail. We will configure it on a standard Linux VPS (CentOS 6 or Debian 6 Squeeze) to handle traffic reliably without getting flagged as an open relay.
The Prerequisite: A Clean IP and Reverse DNS
Before you even touch yum or apt-get, check your infrastructure. Postfix cannot fix a bad network reputation. Major providers like Gmail and Hotmail rely heavily on Reverse DNS (PTR records) to verify that the IP sending the mail actually belongs to the domain claiming to send it.
Do not skip this step. Log into your CoolVDS control panel and ensure your PTR record matches your hostname exactly (e.g., mail.yourdomain.no). If your VPS provider doesn't allow custom PTR records, move. It is 2011; this is non-negotiable for email hosting.
1. Installation and Basic Configuration
Let's assume a fresh install of CentOS 6. Remove Sendmail if it's there to avoid conflicts.
yum remove sendmail
yum install postfix
On Debian 6:
apt-get install postfix
Once installed, open the main configuration file at /etc/postfix/main.cf. We are going to edit the core parameters to define identity. Do not rely on defaults.
myhostname = mail.yourdomain.no
mydomain = yourdomain.no
myorigin = $mydomain
inet_interfaces = all
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
The Storage Format Debate: Maildir vs. Mbox
By default, many distros still default to mbox (one giant file for all emails). This is a performance nightmare if a mailbox grows beyond a few hundred megabytes. Locking issues will kill your I/O.
Force Postfix to use Maildir (one file per email). It scales better and makes backups easier.
home_mailbox = Maildir/
2. Securing the Relay (The "Don't Get Blacklisted" Section)
The fastest way to destroy your server's reputation is to become an open relay, where spammers use your bandwidth to send junk. We need to lock down smtpd_recipient_restrictions. This tells Postfix who is allowed to send mail.
Add this to your main.cf:
smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
reject_rbl_client zen.spamhaus.org
Let's break that down:
- permit_mynetworks: Allows your local server to send mail (e.g., PHP scripts running on localhost).
- permit_sasl_authenticated: Allows users with a valid login (username/password) to send mail, even if they are on a dynamic IP at a coffee shop.
- reject_unauth_destination: The most critical line. Rejects mail that isn't for you, unless the sender is authenticated.
- reject_rbl_client: Queries Spamhaus in real-time. If the connecting IP is a known spammer, Postfix drops the connection immediately. This saves CPU cycles.
3. Authentication with SASL
Postfix doesn't handle authentication itself; it outsources it. In 2011, the standard is using Dovecot or Cyrus SASL. Dovecot is generally more forgiving to configure.
Ensure your /etc/postfix/main.cf knows how to talk to the auth daemon:
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
smtpd_tls_security_level = may
Note the TLS setting. You should generate a self-signed certificate (or buy one from RapidSSL) so that authentication credentials aren't sent over the wire in plain text. openssl is your friend here.
Pro Tip: Watch your logs like a hawk during the first 24 hours. Tail /var/log/maillog. If you see "Relay access denied" for your own legitimate users, check your SASL config. If you see it for strangers, congratulations, your security settings are working.
4. Local Nuances: Norwegian Privacy & Latency
Why host this in Norway instead of a cheap US datacenter? Two reasons: Latency and Law.
If your users are in Oslo or Bergen, the round-trip time (RTT) to a server in Texas adds noticeable lag to IMAP syncing. Every folder click feels sluggish. Hosting on a Norwegian VPS (like CoolVDS) keeps pings under 10ms for local users.
More importantly, we have the Personopplysningsloven. The Data Inspectorate (Datatilsynet) is becoming increasingly strict about where personal data—including email archives—lives. Keeping your email infrastructure physically located within Norway simplifies compliance with local data retention rules.
5. The Hardware Reality
Email is I/O heavy. It's not just receiving the message; it's the virus scanning (ClamAV), the spam scoring (SpamAssassin), and the disk writing. On a standard VPS with oversold resources, your mail queue will back up during peak hours.
This is where virtualization type matters. We use KVM at CoolVDS because it provides guaranteed resources. Unlike OpenVZ, where a neighbor's heavy database can starve your Postfix process of RAM, KVM isolates your kernel. Combine that with our RAID-10 storage arrays, and your mail server won't choke when Monday morning traffic hits.
Final Testing
Once you restart Postfix (service postfix restart), send a test email to a Gmail account. Check the headers. You want to see "Received-SPF: pass".
If you haven't set up your SPF TXT record yet, go to your DNS manager and add: v=spf1 mx a ip4:YOUR_IP_ADDRESS ~all. This simple text string tells the world that your VPS is authorized to send email for your domain.
Don't let email deliverability happen by accident. Take control of your headers.