SPF Framework reduces email fraud and spoofing
Email frauds and scams are successful in part because the email of the sender appears to be from a legitimate source. Sender Policy Framework (SPF) allows email servers to double check that an email came from an authorized source, and reject mail before it lands in anyone’s inbox.
A SPF record is a DNS TXT record published by a domain which lists the specific IP addresses or names of servers which are permitted to send its mail. A SPF-aware email server handling incoming mail will check the source IP of a message against the SPF record listed for the incoming message’s domain before passing the message to the destination inbox.
A domain may publish a SPF record, and mail servers may be SPF-aware, but this does not prevent spam — there is no heuristic engine built in to SPF to analyze message contents. SPF is simply a gatekeeper, typically assuming any received mail is “guilty” of fraudulence unless proven innocent.
SPF is primarily useful in protecting any outside emails from being sent using your domain name and reducing fraud attempts against your customer base, because a spammer won’t be able to fake an email address from your domain. If he/she has actually compromised a server within a SPF-protected domain, it becomes more traceable.
A second benefit of SPF is it reduces backscatter, an indirect method of spam caused when a spammer uses a domain, or more specifically a specific email address (spoofing), as the “from” or “reply-to” address while hammering thousands of targets, invalid or not.
Typically, in a backscatter strategy, the contents of the spam message will still be delivered to the from/reply-to address, only encapsulated by scores of “Your message could not be delivered”, “bulk unsolicited email” and other server warning replies. A SPF-aware server will see that the spoofed sender email address isn’t from an authorized source, and will block it whether or not the destination address actually exists.
SPF in some cases can break mail forwarding from outside the domain to within, which is expected, since the message envelope is preserved during forwarding. This is addressed with Sender Rewriting Scheme (see http://www.openspf.org/SRS).
Naturally, email servers need to be SPF-aware to take advantage of a domain’s SPF record. A number of mail servers natively support SPF, including Courier, Exim, Communigate Pro — see www.openspf.org/implementations for the full list as well as extensions and patches for existing mail servers (Postfix, Sendmail, IIS, Exchange). Add the appropriate extensions your email servers and coordinate with business partners to do the same.
A SPF policy is a DNS TXT record, specifies the SPF version used, contains a list of permitted sources or matching methods (called “mechanisms”), typically followed by “-all” or some variation. A framework query tool is available for looking up a domain’s SPF record (www.spf-all.com), used in the following SPF implementation examples.
Complete syntax documentation is available here.
Example 1 (Bitsighttech.com):
bitsighttech.com. IN TXT “v=spf1 include:_spf.google.com ~all”
- v=spf1 — indicates the record is using SPF version 1 (standard implementation)
- include: _spf.google.com — the SPF record at _spf.google.com is looked up, “and the IP blocks referenced in it”.
- ~all — a “soft fail” which allows all mail through but “marks” failures; “The soft fail can be used when there is a lightweight … spam filtering engine.”
What exactly is substituted in an include: mechanism? An additional query of _spf.google.com reveals that its SPF record is yet another set of include: references :
v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all
Examination of the SPF record for _netblocks.google.com reveals a large set of IP blocks:
v=spf1 ip4:220.127.116.11/19 ip4:18.104.22.168/19 ip4:22.214.171.124/20 ip4:126.96.36.199/18 ip4:188.8.131.52/17 ip4:184.108.40.206/20 ip4:220.127.116.11/16 ip4:18.104.22.168/20 ip4:22.214.171.124/20 ip4:126.96.36.199/16 ?all
Example 2: Amazon.com:
amazon.com. IN TXT “v=spf1 include:spf1.amazon.com include:spf2.amazon.com include:amazonses.com -all”
This record delegates all SPF checking to the spf1 and spf2.amazon.com servers, which most likely link to another subset of SPF records, similar to Google.
Example 3: Set up a SPF record for example.com using specific IP addresses of example.com’s mail servers, and block all other sender origins:
example.com IN TXT “v=spf1 ip4:192.168.34.2 ip4:192.168.35.6 -all”
The “-” modifier in front of “all” will return a SPF FAIL result for any mail from servers other than the two IP addresses listed.