In this post, which is part 1 of the series, I discuss Sender Policy Framework (SPF) in more detail.
SPF – how it works…
Spam and phishing emails often use forged “from” addresses or fake mail servers to convince the mailbox owner that they are receiving a legitimate email.
This has negative effects on both the email recipient, who may act on the illegitimate email; and the company whose brand reputation is tarnished by the fake email.
What is SPF?
SPF is an email validation system used by receiving mail servers to validate that the message it has received is from a legitimate source. It does this by checking the envelope sender address (sometimes called the return-path). This address resides in the message headers and is not immediately visible to the message recipient. In other words, if a sender doesn’t use SPF, the recipient gets an email from a seemingly trusted source (joe@mycompany.com), however the envelope sender address is actually from an unknown source (Phisher@fakecompany.com).
Email recipients will not be aware that the sender is fake, unless they check the message headers. SPF removes this burden from the end user, by detecting if the email has been spoofed (Forged to appear as if it is from a legitimate/known source). The incoming mail server checks with the sender’s DNS server if the address sending the email is authorized to send on the domain’s behalf. If not, the email gets rejected and will not reach the recipient.
Because the DNS is managed by the domain owner and never by phishers or spoofers, there is no way that an unauthorized mailserver can pretend to send from a domain using SPF.
A real life example:
Meet Joe. Joe works at “My Company”. The domain administrator for “My Company” sets up SPF for all servers that are allowed to send on behalf of “My Company”. This can include internal servers, as well as servers hosted by external vendors.
Once off: Joe’s domain administrator sets up his DNS record to ensure that the sending server f(Mailserver 1) is granted permission to send for the “My Company” domain.
- Joe from “My Company” wants to send a message to Mike.
- Joe sends an email to Mike using Mailserver 1.
- Mike’s mailserver receives the connection from Mailserver 1
- Mailserver 1 will say Helo to Mike’s mailserver (Helo is a command used by mailservers to identify themselves)
- Mike’s mailserver will use the Helo command to check the sender’s domain (mycompany.com) to confirm that Mailserver1 has permission to send on its behalf
- Mailserver 1 will say Helo to Mike’s mailserver (Helo is a command used by mailservers to identify themselves)
- Pass: Yes, the domain has permission to send – the message is delivered Mike’s mailbox
A phisher wants to send a message to Mike forging Joe’s Mailserver 1:
- An email is sent to the Mike using the forger’s Mailserver X
- Mike’s mailserver receives the connection from the forgers Mailserver X
- Mailserver X will say Helo to Mike’s mailserver pretending it is from mycompany.com
- Mike’s mailserver will use the Helo command to check the sender’s DNS (mycompany.com) to confirm that Mailserver X has permission to send on its behalf
- Mailserver X will say Helo to Mike’s mailserver pretending it is from mycompany.com
- Fail: The message comes from an unauthorized server. It is considered fake and not from Joe at My Company. Mike’s receiving mailserver can reject this message and it never reaches Mike’s inbox.
How to implement SPF :
- If you are a domain owner, make sure that you identify all authorized hosts that send email on your behalf.
- Add this information to your DNS record (click here to learn how How To)
- Receiving mail server owners need to make sure that their mail servers are SPF aware and enabled. Use the standard DNS queries to check SPF information of inbound emails before forwarding to the recipient’s mailbox
- If you are Joe or Mike, mention to your domain owner that SPF is an open standard framework available to email senders free of charge and ask if it has been implemented on both outbound and inbound mail servers.
To wrap up, SPF authenticates sending servers and provides protection against “envelope sender address” forging.
Look out for my next post on DKIM, where I will explain how to protect your ‘from address’ (the address a recipient sees in their mailbox) and avoid the subsequent impact on your domain reputation.
(58)
