Posts Tagged ‘SPF’

Being a good net citizen: SPF, DKIM and DMARC records

Spam and Phishing emails are some of the more visible scourges of the modern internet. No one enjoys opening up their mailbox and seeing junk clutter up the place, or seeing a mail that tempts you to enter credentials somewhere because it looks legitimate. The war against Spam and Phishing is an on-going battle, with many tools deployed to try and keep a user’s inbox clean.

If you own or manage a domain on the internet and that domain makes use of email, it’s only right to be a good net citizen and set up SPF, DKIM and DMARC records. Together those 3 make a 3 pronged fork that can be stabbed into the heart of junk mail, but they each do a slightly different thing. Let’s take a look at them:

SPF essentially denotes who is allowed to send mail for your domain. Anything that doesn’t match the details in the record is to be considered an attempt to spoof your domain and should ideally be rejected, provided the record is set up as such. If you have a small domain with simple records, SPF is incredibly easy to set up. It becomes harder if you are a giant corporation or have lots of mail being sent from third party bulk mailers, but even those use case scenarios can be brought into line so that you have a valid SPF record. If Microsoft, Google and others can do it, why can’t we?

DKIM is a little trickier. DKIM enabled servers sign outgoing mail with a digital signature and lets receiving servers validate the signature using the published key in the DKIM DNS record. This way, mail can be verified as having been sent from domain because the signature can be verified by consulting the DKIM record in’s domain. If the validation fails it’s either because the mail was forged or the message modified on route. Since spammers aren’t running your mail server, they can’t validly sign outgoing messages with your private key, so when a destination server checks the signature, the check will fail.

DMARC sits on top of SPF and DKIM. While SPF contains syntax for what to do when mail fails a check, DKIM does not. DMARC essentially tells a recipient mail server what do with those mail if they fail the SPF/DKIM checks. Mail can either be allowed through to be processed as the destination sees fit, sent to the Spam/Junk folder or rejected outright. Set to reject mode and along with an –all syntax in SPF, this will ensure that spammers cannot spoof mail from your domain (in theory)

It’s not perfect though. In order for the 3 records to be effective, the destination mail server needs to check the records. If the server doesn’t and simply accepts mail as is, junk mail will make it into the inbox from forged senders. The records also don’t help if a spammer compromises a legitimate account in a domain with all 3 records, as when the mail is sent out via that domain, it will pass all checks on the destination end, as it was sent from a domain with valid records. To prevent this, you’ll need to set up rules to detect outgoing spam and block it from being sent. Each mail server will have different instructions on how to do this.

Office 365 and G-Suite all include records for SPF, while DKIM takes a few more steps to set up in Office 365. G-Suite also supports DKIM as far as I know, but since I don’t use the product, I don’t know how hard or easy it is to set up.

While nothing is ever perfect in the war against spammers, a huge amount of junk mail could be stopped cold if more domains published valid SPF, DKIM and DMARC records. Banks and financial institutes that are a favourite target of fraudsters could save themselves a lot of grief by having destination domains reject all mail that isn’t legit. IP block lists and content filtering will remain an important part of the game, but if more junk mail could be stopped at the edge before being accepted and processed, the better off the entire internet will become.

Categories: Internet, My tips and tricks Tags: , ,