Have you ever received a bounce for spam that was sent by you…only it wasn’t sent by you? Email spoofing is one of the easiest concepts to understand for us, but the hardest to explain to end users who confuse spoofing with email hacking and hijacking. The way I explain it to our customers is that spoofing is simply when someone (usually spammers) sends an email that looks as if it came from one person, when it really came from someone else.
Regardless of what some email providers say, there is no honest and straight forward way to keep people from spoofing your email, unless you have access to the real sender’s mail system. However, there is a way to keep legitimate mail servers from accepting spoofed email by creating an SPF record for your domain.
An SPF record (sender policy framework) in short is a DNS record that you add to your domain’s zone file to specify which hosts are allowed to send mail on behalf of your domain. For the most part you would only want the server hosting your domain to be able to send mail, but hat most of our customers don’t realize is that they unknowingly spoof email all the time! Since ISP’s nowadays block SMTP port 25 for third-party mail servers, a lot of our customers use their ISP to send mail for their domain. This is basically how email is spoofed…you put an email address as the ‘from’ address in an email, and send it from a different mail server. Even though this is legitimate email, they are basically allowing their ISP’s mail servers to send their domain’s email, even though their ISP has no authority or management rights over that email, since the domain is hosted on another server.
We usually require our customers to generate their own SPF records so that they can specify what servers they want to be able to send mail from, that way our hands stay clean if the SPF record causes them to not be able to send email. If you go to www.openspf.org you can easily generate a custom SPF record to add to your DNS zone with little to no hassle. The questions can be a little confusing for newbies, so here’s a quick walkthrough on how to answer them.
Question 1: A-Record
v-nessa.net's IP address is 188.8.131.52 (vps71.inmotionhosting.com). Does that server send mail for v-nessa.net?
The wizard will attempt to resolve the domain to an IP, then do a rDNS on the IP for a hostname. You usually want to say YES unless your mail is hosted on a different server.
Question 2: MX-Record
This wizard found 2 names for the MX servers for v-nessa.net:
vps71.inmotionhosting.com and v-nessa.net. MX servers receive mail for v-nessa.net. Do they also send mail from v-nessa.net?
In most cases, this will be true. Exceptions for this is if you have an irregular MX record modification, or are using another outgoing mail server or domain to send mail.
Question 3: PTR
Do you want to just approve any host whose name ends in v-nessa.net?
Typically, you do not want to enable this setting unless you have mail accounts set up for subdomains or domains that are similar in ending that need to relay through this domain. Or, if you use a subdomain as your sending host (like mail.domain.com, etc)
Question 4: A subs
Do any other servers send mail from v-nessa.net?
The answer is usually no. The only other server that would send on behalf of that domain would be the server name (you may need to ask your host for this), but this was already allowed in question 1. The next two fields can be left blank, unless you specifically have information to add to them.
Question 5: Include
Could mail from v-nessa.net originate through servers belonging to some other domain?
Fill in this field mainly if you are planning on using another mail server or domain (such as your ISP, gmail, etc.) to send mail. Otherwise say no.
Question 6: ~all
Do the above lines describe all the hosts that send mail from v-nessa.net?
Check your answers and hit yes.
At the bottom of the page you’ll see the nicely-generated SPF record that will look something like this:
"v=spf1 a mx ~all"
Adding the Zone Entry
You can add the SPF record either WHM (if you are on a cPanel server) or manually in the zone file of that domain.
The line will look something like this:
v-nessa.net. 14400 IN TXT "v=spf1 a mx ~all"
You can then verify the addition by doing a dig on the domain:
dig v-nessa.net TXT