Now that you know how to configure an SPF record for your domain(s), the natural next step, if you administer an email server, is to start checking SPF records for mails you receive.
Now, spammers are infamous for not respecting rules, not “playing nice”, so, you might ask, what makes me think they’ll set up SPF records for their domains, which would be kind of self-defeating? The obvious answer is that SPF doesn’t depend on the spammers’ collaboration. Since legitimate email senders use SPF to tell the world which servers they use to send email, it prevents others — such as the aforementioned spammers — from faking sender addresses to pretend they’re from those senders / domains.
To put it simply: if there’s an SPF record for the “gmail.com” domain, then you can — and should — reject mail purporting to be from firstname.lastname@example.org that doesn’t come from the servers listed in that record. In other words, anyone who fakes a @gmail.com address can’t fool your server, assuming you have it configured to use SPF.
Now, how to do that? There are many ways, of course, depending on the email server you use. The simple recipe below uses postfix-policyd-spf-perl to make Postfix reject mail from domains with properly configured SPF records, when the mail comes from an unauthorized server (that is, one not listed on the record.) This assumes you already have Postfix up and running.
- install postfix-policyd-spf-perl. In Ubuntu, just do an
apt-get install postfix-policyd-spf-perl.
- add this line to /etc/postfix/main.cf:
spf-policyd_time_limit = 3600s
- add the following to /etc/postfix/master.cf:
policy-spf unix - n n - - spawn user=nobody argv=/usr/bin/policyd-spf
(change the path of policyd-spf if it’s installed somewhere else; that’s where the Ubuntu package puts it.)
- in /etc/postfix/main.cf, find the smtpd_recipient_restrictions section, and, immediately after permit_mynetworks (and permit_sasl_authenticated, if you’re using that), add:
- restart Postfix. Check your logs to see if everything is working properly.
Now, remember when in part 2 I mentioned a lesser-known reason for configuring the SPF record for your domain? It’s this: it’ll stop a lot of incoming spam. These days, a lot of spam email pretends to be from you (that is, it uses your email address as both the “From:” and “To:”), or at least from your domain (e.g. administrator@yourdomain, manager@yourdomain, and so on.) I don’t know why spammers do that, but apparently it works, or else they wouldn’t do it (maybe victims get confused and think the email comes from someone in their company, or maybe webmail services tend — or at least did so once — to trust the user’s own address, I don’t know.) Well, if you have SPF for your domain and your email server checks SPF records for incoming mail, then spam messages such as these will be always rejected, even when other methods of stopping spam (RBL lists, SpamAssassin, etc.) fail. Never again will you receive emails pretending to be from your own address.
- SPF, part 1: what is SPF, and how to fight spam with it
- SPF, part 2: how to configure SPF for a domain
- An Anti-Spam gateway #4: Postfix, part 2
- An Anti-Spam gateway #3: Postfix
- An Anti-Spam gateway #11: amavisd-new and Postfix