Do you get tired of getting e-mails that are sent to you, but not actually from you? What happens when a spammer e-mails 1000 people using firstname.lastname@example.org and then you get a ton of kick back messages, or people complaining you are sending them spam? If you implement this method, and the server the e-mail is being sent to also takes it into account, you might be able to put a stop to that spam.
For example, you receive an e-mail from email@example.com, yet it isn’t actually an e-mail that you sent- it is spam.
By implementing the method called Sender Policy Framework (SPF), you can do something about it. You can add some information to your domain name that says “all e-mails sent using firstname.lastname@example.org are spam, except for e-mails that are sent from this mailserver and this mailserver.”
Any server that checks for SPF records will help handle spam. So it is helpful for not only your e-mail account, but also other mailservers that implement SPF (such as at Hotmail/AOL). Spam software is also implementing SPF to increase/decrease the probability of an e-mail message being flagged as spam (such as Spam Assassin).
It is also useful at helping to keep your domain out of some arbitrary blacklists run by ISPs or webhosting providers. Some will check for valid SPF records and weigh that against blacklisting you. It may show them that you are aware of the problem enough to publish such records.
The basic way you implement this, is in regards with domain records. Every domain name keeps a list of records, where you can define certain things relating to your domain (for example, you are hosting your website with one company, yet you are handling your e-mail with another company, in order to do this you would need to edit a domain record).
There are a few questions you need to ask yourself before you can implement this…
1) What mailservers are you planning to send e-mails from?
– Here’s a situation… You have a hosting account with X host, and your domain name example.com. You also use Cox as your ISP. When you send an e-mail using something like Microsoft Outlook and your ISP’s outgoing mailserver (SMTP) for example.com (which is hosted with X host), then the e-mail comes from email@example.com. However, it doesn’t come from the X host mailserver, but instead the ISP’s mailserver (such as smtp.west.cox.net). You will need to know every mailserver you plan to use to send e-mails from. Usually, it will just be your web host; however, some people send mail using their domain name and their ISP’s mailserver.
2) What do you want the mailserver to do when a message is sent using example.com, but NOT from the mailservers you listed?
~all tells the receiving mailserver what to do in case of a failed test. ?all tells the server that email should come from X host but, accept it from other places too because we’re not certain where all email is coming from.
~all tells the server that email should all come from X host but, to not reject the emails completely.
~all softfails the email which means it is received but, the person it is sent to could be given a warning about the email being possibly forged or the emails could be moved to a spam box.
-all tells the receiving server that you are certain all email for the domain will come from servers in the record and if it doesn’t it should be rejected outright as a forged email or moved to a spam box based solely on that criteria without considering what is in the email.
How to implement this
1) The first step is to answer the two questions above. The critical part is finding out what mailservers you plan to send e-mails from. Contact your web host and ask them what the outgoing mailserver is (usually it is something like smtp.hostname.com)
2) Next, think about how e-mails should be handled. Should you tell the mailserver that you want to flag the message as 100% for sure spam? Or maybe just say there is a high chance that it is spam, but it might not be? The suggested setting is simply ?all. This will let the mailserver know you have implemented the SPF method, and weigh that when determining if something is or isn’t spam.
3) Edit the DNS Zone for example.com. Since an SPF record is a TXT record, you will add something like this:
example.com. IN TXT “v=spf1 a:smtp.example.com a:smtp.west.cox.net ?all”
This will say “all e-mails sent from my domain: example.com are supposed to come from the mailservers smtp.example.com and smtp.west.cox.net. If the e-mail is not coming from either of the two mailservers, there is a chance it is a spam message.”
If you are not sure how to edit a record for your domain, your web host should be able to help you do it yourself. If you are on a cPanel/WHM server, log into WHM and click on ‘Edit DNS Entry’.
The great thing about this is that only mailservers that implement the SPF check will actually look for this. So if you have it, and the mailserver you are using doesn’t use it, it won’t hurt anything at all (it will just be ignored, or as if you didn’t even have it). If you have it enabled and the mailserver checks for it, then
Let’s say that you only send e-mails using the example.com’s mailserver, and have the record setup for that mailserver only. If you decide that you want to setup e-mail for example.com on your home computer, and you use your ISP’s outgoing mailserver (such as smtp.west.cox.net), then it may or may not be flagged as spam.
So as long as you list the mailservers you plan to use, then everything should be fine. Most people only use one or two mailservers to send e-mail, so it really isn’t a big problem to list them.
Arizona Web Design – Mr Bobs Web Design in Arizona
The Arizona Web Hosting Challenge