I have been getting a lot of bounced mail reports for email that I have not sent. This is generally due to a spammer selecting your domain at random and pretending to be you when they send out the spam; it does not necessarily mean that they have compromised your server. Most of the major email providers have implemented a method of verifying that the person sending the mail is allowed to use that server. This requires you to set up a SPF record in your DNS which is a fairly simple process. All you need to do is add a record of the form
IN TXT "v=spf1 a mx ~all"
IN SPF "v=spf1 a mx ~all"
to your DNS file. If you are hosted with Westhost, then the file we have to edit is /var/named/db.mydomain.com – however, you will need to submit a support ticket with Westhost to get them to do the job for you as it requires root access. It is possible that your DNS server will not support the SPF record, so just add the TXT record. However, getting your record set up is a bit of a black art! I had to read the full text of the SPF specification before I fully understood how it worked. The definition above is all 90% of sites will need, however you can use either OpenSPF’s or Microsoft’s Sender ID Wizard to help you. I recommend that you end your definition with ~all (tilde all) until you have verified that your configuration is correct then replace it with -all (minus all) to exclude all unspecified IP addresses. This will prevent your mail from being rejected by other servers if you got something wrong.
There are a couple of extra parameters you can include. If you use subdomains (For example firstname.lastname@example.org) then you will need to add the ptr definition. Also, if you have a static ip, then you can add either an ip4: or ip6: entry as appropriate (example ip4:10.0.0.1). Finally, Apache Virtual Hosts do not appear to need extra records of the form
IN TXT "v=spf1 a mx redirect:PrimaryDomain.com ~all"
Note If you want you can have separate entries for your virtual domains by specifying the domain name. For example
domain1.com IN TXT “v=spf1 a mx ptr ip4:xxx.xxx.xxx.xxx -all”
domain2.com IN TXT “v=spf1 a mx -all”
Now the whole purpose of SPF filtering is to prevent people from using unauthorised servers to send email pretending to be a different domain. So, if you use someone else’s server to send email pretending to be from your domain (such as your ISP’s, Yahoo’s or Hotmail’s server), then you can add their definitions to your SPF record. This obviously opens up your domain to abuse by spammers and so is not best practice – better to use your own server where possible. If you still want to do so, then keep the definition as restrictive as possible, so add mx:yahoo.com rather than include:yahoo.com. You do not need to do this if you are using GMail as they add a ‘Sender’ field to the header which identifies you as a GMail account holder (which is why some clients display the message as being From email@example.com On Behalf of firstname.lastname@example.org) and the SPF check goes back to Google.
If you are using your own server to send email out for your Hotmail, Yahoo or similar account, then STOP it! It is possible that your email is being rejected by your recipient’s server because the Hotmail, Yahoo or other server does not have your mail server listed as a valid device – and you are not going to get them to change their record for you!!
Once you have set up your record, allow several hours for your DNS record to propogate its way around the internet and then check your record using the validator at SEO Consultants or the DNS Report tool at DNS Report. Finally, send a blank email from your mail server to email@example.com and wait for the reply. If everything is OK, then you can edit your SPF record so that it ends in -all as explained earlier.
You are now half way through the process. At this stage, you have protected your domain so your emails should be less likely to be bounced and you should not get the bounced mail reports for email sent by other people. You now have to configure your server to reject email that is not coming from an authorised server, but this requires Sendmail 8.13 before we can implement it and will have to wait for another day. (As will the DomainKeys standard implemented by Yahoo!)
For further details, visit EmailAuthentication.