Stop Getting Blacklisted: The Definitive Postfix Configuration Guide for 2012

I have seen grown systems administrators cry over mail logs. I have watched perfectly good marketing campaigns vanish into the void of the Yahoo! bulk folder. Why? Because configuring an email server in 2012 is not just about installing software; it is about engaging in active warfare against spammers, open relays, and the capricious nature of IP reputation.

If you are still running your corporate mail off a shared hosting plan or a dusty box in your closet, you are asking for trouble. Latency matters. Disk I/O matters. And if your Reverse DNS (rDNS) doesn't match your HELO banner, you might as well be sending smoke signals.

In this guide, we are going to build a Postfix server that actually delivers. We will focus on the strict requirements of Norwegian ISPs and the standards expected by Datatilsynet (The Norwegian Data Inspectorate). We will be using a CoolVDS instance running CentOS 6, primarily because email queues on rotational HDD storage are a bottleneck I refuse to deal with anymore. SSDs are the only way to handle Maildir structures effectively.

1. The Foundation: Hostname and DNS

Before we touch a single config file, we need to talk about identity. Postfix identifies itself to other servers (like Gmail or Hotmail) using a hostname. If that hostname doesn't resolve back to your IP address, you are dead in the water.

The Golden Rule: Forward DNS (A Record) == Reverse DNS (PTR Record) == Hostname.

On your CoolVDS panel, navigate to the Network tab and set your Reverse DNS to mail.yourdomain.com. Do not skip this. I once debugged a client's server for three days only to find their provider had locked the PTR record to a generic static-ip-85-x.isp.no. Don't be that guy.

Now, set the hostname on the box:

# For CentOS 6
sed -i 's/HOSTNAME=.*/HOSTNAME=mail.yourdomain.com/' /etc/sysconfig/network
hostname mail.yourdomain.com

2. Installing and Configuring Postfix

Forget Sendmail. It’s archaic and the configuration syntax looks like someone fell asleep on a keyboard. We use Postfix. It is modular, secure by design, and fast.

yum install postfix cyrus-sasl cyrus-sasl-plain
# Or for Debian/Ubuntu fans
apt-get install postfix libsasl2-2 sasl2-bin

The main.cf Configuration

The default configuration is too permissive. We need to lock it down. Open /etc/postfix/main.cf. We are going to edit the critical parameters. I prefer using postconf -e to avoid syntax errors, but manual editing works if you are careful.

Here is a battle-tested configuration block for a standalone mail server:

# IDENTITY
myhostname = mail.yourdomain.com
mydomain = yourdomain.com
myorigin = $mydomain

# NETWORK
inet_interfaces = all
inet_protocols = ipv4
# Note: Enable IPv6 only if you have a configured AAAA record and PTR!

# DELIVERABLES
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
home_mailbox = Maildir/

# RELAY CONTROL (CRITICAL)
ynynetworks = 127.0.0.0/8
relay_domains = $mydestination

Pro Tip: Always use Maildir/ format instead of mbox. Mbox stores all emails in a single file. If that file gets corrupted, you lose everything. Maildir stores one file per email. This generates massive I/O operations (IOPS) when reading a full inbox. This is why we run on CoolVDS SSD arrays; standard SATA drives choke on the random read/write patterns of high-volume Maildir access.

3. Security: Preventing Open Relays

An open relay is a server that allows anyone on the internet to send email through it. If you configure an open relay, your IP will be blacklisted by Spamhaus within hours. We prevent this using smtpd_recipient_restrictions.

This is where the magic happens. We want to reject anything that isn't explicitly allowed.

smtpd_recipient_restrictions = 
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
    reject_invalid_hostname,
    reject_non_fqdn_hostname,
    reject_non_fqdn_sender,
    reject_non_fqdn_recipient,
    reject_unknown_sender_domain,
    reject_rbl_client zen.spamhaus.org

This configuration checks against the Spamhaus RBL (Real-time Blackhole List) immediately. It saves CPU cycles by dropping connections from known spammers before processing the message body.

4. Authentication (SASL)

You need to send mail from your iPhone or Outlook. For that, you need SASL authentication. Postfix doesn't handle auth itself; it hands it off to Cyrus SASL or Dovecot.

Edit /etc/postfix/master.cf to enable the submission port (587). ISPs often block port 25 for residential users, so port 587 is mandatory for your remote users.

submission inet n       -       n       -       -       smtpd
  -o smtpd_enforce_tls=yes
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject

5. Deliverability: SPF and DKIM

Setting up the server is only half the battle. You need to prove you own the domain. In 2012, if you don't have SPF, you look suspicious. If you don't have DKIM, you look amateur.

SPF (Sender Policy Framework)

This is a DNS TXT record that lists the IPs authorized to send mail for your domain. It is simple but effective.

The -all at the end is a hard fail. It tells receivers: "If the mail didn't come from these IPs, delete it."

DKIM (DomainKeys Identified Mail)

DKIM signs your emails cryptographically. We use opendkim. It's available in the EPEL repository for CentOS.

yum install opendkim
# Generate keys
mkdir /etc/opendkim/keys/yourdomain.com
opendkim-genkey -D /etc/opendkim/keys/yourdomain.com/ -d yourdomain.com -s default
chown -R opendkim:opendkim /etc/opendkim/keys

Once generated, you will get a TXT record content in default.txt. Publish this to your DNS. Then, link Postfix to OpenDKIM in main.cf:

smtpd_milters = inet:127.0.0.1:8891
non_smtpd_milters = $smtpd_milters
milter_default_action = accept

6. The Norwegian Context: Compliance and Latency

Operating in Norway brings specific challenges. Under the Personal Data Act (Personopplysningsloven), you are responsible for the security of personal data, which includes email metadata. Hosting your mail server on a provider with physical infrastructure outside the EEA can complicate compliance.

Furthermore, latency to the Norwegian Internet Exchange (NIX) in Oslo affects how snappy your IMAP connection feels. A server in Dallas will always feel sluggish compared to one in Oslo or Amsterdam. CoolVDS peers directly at major European hubs, ensuring that when you hit "Send," the packet isn't taking a scenic route across the Atlantic.

Why Infrastructure Matters

I mentioned SSDs earlier. Let's look at the numbers. A busy Postfix server handling spam filtering (SpamAssassin), virus scanning (ClamAV), and writing to Maildir can easily hit hundreds of IOPS. A standard 7200 RPM SATA drive caps out around 80-100 IOPS. When you hit that cap, email delivery slows down, load averages spike, and iowait eats your CPU.

At CoolVDS, the underlying KVM infrastructure utilizes pure SSD storage in RAID configurations. This isn't just a luxury; for a functional mail server in a corporate environment, it is an operational necessity. You avoid the "noisy neighbor" effect where another VPS doing a backup kills your email performance.

Final Thoughts

Configuring Postfix is a rite of passage. It demands attention to detail and a respect for standards. Do not cut corners on DNS. Do not ignore your logs (check /var/log/maillog religiously). And for the love of uptime, host it on hardware that can keep up with the I/O.

Ready to deploy? Don't let slow I/O kill your response times. Deploy a CentOS 6 instance on CoolVDS in 55 seconds and get your mail flowing correctly.