Email spoofing has long been a problem on the internet. One of the many solutions to this problem is the adoption of an SPF record. Read on to learn more about the problem of spoofing and a brief introduction to SPF.
|IN THIS ARTICLE||
|The Spoofing Problem||SPF - Sender Policy Framework|
The Spoofing Problem
Email address spoofing is a fraudulent activity in which the sender (i.e. the spammer) forges the envelope sender address to make it seem as though the email originated from a different (legitimate) source. Often, an email user's only indication of this practice occurs if they happen to come across a spam message purporting to be sent from his address. Sadly, this is a rather common occurrence with lasting consequences for the owner of the spoofed domain or address.
The first victim of a spoofing campaign will be your domain's reputation; if you are receiving spam messages from yourself, you can be sure that others are also receiving spam messages that appear to be coming from you. This is obviously not a good thing. The second consequence may be more harmful: among the servers receiving spam messages claiming to come from your domain, some will be using filtering solutions that will flag these emails as spam. These servers will bounce back the email and send DSN messages to your server since the messages appear to be coming from it. If the spamming campaign is massive enough, your server will find itself flooded with DSN messages even though it has not sent any of these emails. Fortunately, there is a solution that can help protect your domain from spoofing: publishing an SPF record.
SPF - Sender Policy Framework
SPF is an open email validation system designed to prevent email address spoofing. The SPFv1 protocol was recognized by the IETF (Internet Engineering Task Force) and first published under RFC 4408 in 2004. It was later formalized in 2016 with RFC 7208.
SPFv1 enables the owner of a domain name to define which servers are authorized to send email for this particular domain name through the use of DNS records.
Both senders and recipients need to be part of the process: the domain name owner does so by publishing his sending policies whereas the recipients configure their email server to check SPF records on all incoming email. When an email comes in from a domain protected by an SPF record, if it is not sent by a server specified in the record, the recipient server will reject it. You are protecting your domain by publishing an SPF record because emails spoofing your domain will no longer be accepted by recipients who make SPF checks on incoming email. Spoofed email will continue to be accepted by recipients that do not use SPF checks. But the SPF technology is spreading and the number of servers who are configured to make SPF checks is growing. In addition, studies have shown that spammers tend to avoid spoofing domains protected by SPF records. Here is an example to illustrate how these rules work.
Bob owns the domain name “example.net” and sends his emails through both his “pluto.example.net” server and his Gmail account. In order to reduce the number of spam emails sent with his domain, he decides to publish the following record:
example.net. TXT “v=spf1 mx a:pluto.example.net include:gmail.com –all”
Which means :
v=spf1: SPF version 1.
mx: Incoming SMTP servers (MX) are allowed to send email.
a:pluto.example.net: The server "pluto.example.net" is authorized.
include:gmail.com: The Gmail servers are also authorized. This is done by checking the SPF record on the domain "gmail.com".
-all: No other servers are not authorized to send emails on behalf of example.net.
Ultimately, the goal behind configuring an SPF record is to block spoofed emails. Rejections will only occur if the SPF record is correctly configured. To make sure that spoofed emails are rejected, the SPF record needs to be configured with the
Since SPF verifications are done during the SMTP transaction, spoofed emails will be rejected with a DSN error message. In order to help diagnose SPF errors, our DSN error messages include a helpful diagnostic page. You can see an example diagnostic page here: http://www.openspf.org/Why?s=mfrom&id=example%40orange.com&ip=184.108.40.206&r=example%40potato.com
The SPF diagnostic page gives context to help you understand what is causing the SPF error and what can be done to correct the problem. It is important to remember that this page is dynamic: if the problem has been fixed, the page will no longer be relevant.
- Complete Text: http://www.ietf.org/rfc/rfc7208.txt
Our team is happy to help you publish a complete and valid SPF record.