Console Login

Stop the Spam Folder Exile: The Battle-Tested Postfix Configuration Guide for 2012

Stop the Spam Folder Exile: The Battle-Tested Postfix Configuration Guide

There is nothing—and I mean nothing—more frustrating than watching a perfectly crafted transactional email vanish into the digital void of a Hotmail or Gmail spam folder. I’ve spent too many sleepless nights tailing /var/log/maillog, watching connection timeouts and 550 errors roll by because a client decided to host their mail server on a dirty IP range with zero reputation.

If you are running a business in Norway, you can't afford to have your invoices or password resets blocked by Telenor's filters. The reality of 2012 is that email delivery is no longer just about moving packets on port 25. It is a game of trust, reputation, and cryptographic verification.

Today, we are going to build a Postfix server on CentOS 6 that actually delivers. No Sendmail spaghetti configuration, just clean, robust Postfix.

The Foundation: Hardware and Reputation

Before we touch a single config file, we need to talk about where this server lives. You cannot build a reliable mail server on a sluggish VPS with noisy neighbors stealing your I/O cycles. Mail queues write to disk constantly. If your disk latency spikes, your mail queue backs up. It’s that simple.

This is why seasoned admins prefer environments like CoolVDS. We utilize KVM virtualization which guarantees that your RAM and disk resources are actually yours. More importantly, for email, you need a provider that offers clean IP addresses and allows you to set your own Reverse DNS (PTR) records instantly.

Pro Tip: If your VPS provider makes you open a support ticket to change your Reverse DNS, leave them. On CoolVDS, you set the PTR record in the control panel, and it propagates effectively immediately. Without a PTR record matching your hostname, you are dead on arrival to Gmail.

Step 1: The Basics (CentOS 6.3)

We are using CentOS 6.3. It’s stable, it’s Enterprise-ready, and it supports the necessary libraries for DKIM and TLS. First, let's strip out Sendmail if it's there and get Postfix in.

yum remove sendmail yum install postfix cyrus-sasl cyrus-sasl-plain mailx chkconfig sendmail off chkconfig postfix on

Once installed, we need to edit the holy grail: /etc/postfix/main.cf. I’ve seen too many tutorials suggest a "minimal" config that leaves you open as an open relay. Do not do that unless you want your server IP listed on Spamhaus within 12 hours.

Step 2: The main.cf Configuration

Open /etc/postfix/main.cf and set these core parameters. Pay attention to myhostname. This must match the FQDN (Fully Qualified Domain Name) you set in your PTR record.


# /etc/postfix/main.cf

myhostname = mail.yourdomain.no
mydomain = yourdomain.no
myorigin = $mydomain
inet_interfaces = all
inet_protocols = ipv4
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain

# Network Safety
mynetworks = 127.0.0.0/8
home_mailbox = Maildir/

# The Greeting - Don't leak too much info
smtpd_banner = $myhostname ESMTP $mail_name

This sets up the basic transport. But now we need to secure the doors. We need to define who can talk to us and who can send mail through us.

Crucial Security Constraints

Add the following to the bottom of your main.cf. This utilizes HELO checks to drop connections from botnets that don't even know their own names.


# Security & Restrictions
disable_vrfy_command = yes
smtpd_helo_required = yes

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

Notice the reject_rbl_client zen.spamhaus.org line. This offloads a massive amount of spam filtering to Spamhaus. If the sender is on their blacklist, we drop the connection before wasting CPU cycles processing the body. Efficiency is key when you are handling high throughput.

Step 3: Authentication (SASL) & Ports

Port 25 is often blocked by residential ISPs to prevent spam. You need to enable the Submission port (587) so your authenticated users can send mail. Edit /etc/postfix/master.cf and uncomment the submission line:


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

This ensures that only people with a username and password can send mail via port 587, and it forces TLS encryption so passwords aren't sent in plain text. For the Norwegian market, where privacy is taken seriously under the Personal Data Act, sending unencrypted auth data is negligence.

Step 4: The Trust Layer (SPF & DKIM)

This is where the amateurs get separated from the pros. Setting up the server is easy. Getting the email delivered requires DNS verification.

SPF (Sender Policy Framework)

Go to your DNS manager (if you host with CoolVDS, our DNS manager propagates changes rapidly). Add a TXT record for yourdomain.no:

v=spf1 mx a ip4:192.0.2.10 -all

Replace 192.0.2.10 with your VPS IP. The -all at the end tells receivers: "If the email didn't come from this IP, delete it."

DKIM (DomainKeys Identified Mail)

SPF verifies the IP, but DKIM verifies the message integrity. We will use opendkim from the EPEL repo.

yum install epel-release yum install opendkim

Edit /etc/opendkim.conf:


Mode    sv
Socket  inet:8891@localhost
Domain  yourdomain.no
KeyFile /etc/opendkim/keys/default.private
Selector default

Generate your keys:

mkdir -p /etc/opendkim/keys opendkim-genkey -s default -d yourdomain.no -D /etc/opendkim/keys chown opendkim:opendkim /etc/opendkim/keys/default.private

Finally, hook it into Postfix by adding this to main.cf:


# DKIM Integration
smtpd_milters = inet:127.0.0.1:8891
non_smtpd_milters = $smtpd_milters
milter_default_action = accept

The Storage Factor: Why SSD Matters

Mail servers are I/O intensive. Every incoming message involves logs, queue writes, virus scanning, and eventual storage. On traditional spinning rust (HDD) VPS hosting, you will see 'iowait' spike during spam waves. This slows down everything, including your SSH session.

At CoolVDS, we deploy high-performance SSD storage. While many providers in 2012 are still charging a premium for this, we believe it's the baseline requirement for a responsive infrastructure. Combined with our low latency to major European exchanges, your SMTP transactions complete in milliseconds, not seconds.

Final Check

Restart everything and watch the logs:

service postfix restart service opendkim restart tail -f /var/log/maillog

Send a test email to a Gmail account. Check the "Show Original" headers. You should see spf=pass and dkim=pass. If you see that, congratulations. You have built a mail server that commands respect.

Don't let your infrastructure be the bottleneck. Whether you need a robust mail relay or a high-traffic web server, quality hosting is the first line of defense. Deploy your next Postfix server on a CoolVDS SSD instance today and stop worrying about your reputation score.