Spam Filtering Techniques
Yahoo! confirm withdrawal from Goodmail Certified mail.
Mar 5th
Today Yahoo! confirmed that as of this month they no longer participate in Goodmail certified mail. It has not be confirmed as to why Yahoo! have withdrawn from the scheme but it is well known amongst the industry that Yahoo! have had continued infrastructure issues with their inbound mail and this may be related.
Its not all bad news for Goodmail customers however, last month we reported on a rumour that hotmail were due to start supporting the certified mail scheme. We still believe this is likely to happen.
Yahoo! today announced to the industry today that…
On March 24th, we will decommission the MX record for ‘gms.mail.yahoo.com’, the dedicated domain to which senders have been routing CertifiedEmail for Yahoo! Mail recipients. To ensure no disruption of email delivery to Yahoo!, we recommend clients consult with Goodmail and make any necessary changes to their email systems in advance of this date.
Email Manuals advise is that you should imediately stop sending goodmail certified messages to Yahoo! domains including rocketmail.com and ymail.com as you will not be receiving the benefits which come from doing so. Instead you should deliver mail, uncertified, to Yahoo!’s mainsteam MX records which are published in the normal manor.
Microsoft/Hotmail to support Goodmail Certified Mail?
Feb 10th
Whilst browsing the web for email deliverability related stories that may have broken in the time it took me to drive from work to home I came across an article published only a few minutes ago. The article published on the deliverability.com site claims that today goodmail have announced that Microsoft mailboxes would soon support the goodmail certified mail programme run by Goodmail systems.
If this is true then Goodmail have just added the worlds largest consumer mailbox provider to their list of ISP partners which already boasts Yahoo!, AOL, MySpace and large US ISPs such as Comcast and Cox.net.
Email Manual have been unable to verify the rumour and has not seen any communication from either goodmail nor Microsoft to be able to confirm the claim and at time of writing this there is no mention of it on the Goodmail systems press release page.
That being said, Hotmail/live/Microsoft mailboxes which are rumoured to be around 270 million in volume would be a huge boost for the company which operates a certified mail scheme which can be optionally subscribed to through ESP’s who are partnered with goodmail.
The scheme which charges ESPs an additional CPM rate for mail destined for goodmail supported inboxes to allow their customers to particpiate claims to have delivered 30-40% better ROI and clickthrough rates for some customers. A customer must be able to demonstrate an existing good deliverability and low spam complaint rate to participate.
The goodmail scheme works slightly differently with different ISPs but can offer some or all of the following benefits:
- Guaranteed to hit the inbox rather than the junk folder
- Images and links turned on by default within the email client.
- A blue certified mail envelope next to the email in the inbox to assure recipients the email is genuine.
For more information contact your email service provider.
Important information for users of spamassassin.
Aug 25th
Recently it has been widely published that bl.open-whois.org, a blocklist which was included within the default install of spamassassin has been taken offline and is no more.
Users of the open source spamassassin application started to report that emails were being marked as spam wrongly. Upon investigation it appears that the domain open-whois.org had fallen into the hands of cyber squatters, presumably because the previous owner of the domain did not reregister the domain.
Although the cyber squatter probably didn’t take on the domain for any malicious reason, it does mean that they have the ability to control the DNS servers for the domain and return results which could cause spamassassin to block and/or bounce inbound emails scanned by spamassassin at worse case, or the best case is that spamassassin will have to do unnecessary lookups to a non-existent blocklist which will cause up to 60 second delays for each inbound email.
As I write this the domain is completely unresponsive to DNS requests and is not returning false positives but Email Manual advice to users of spamassassin would be to reconfigure spamassassin to not check the bl.open-whois.org blocklist to prevent this issue from impacting your inbound email.
This can be done by either upgrading spamassassin to 3.2.x version of spamassassin or by removing any rules which mention bl.open-whois.org from the rules/72_active.cf file within your spamassassin installation folder.
spamassassin 3.2.x is available for download here.
Googlemail and the new anti-phishing key.
Jul 13th
Googlemail which came out of beta last week has today announced a new anti-phishing key.
The new key is designed to give googlemail/gmail users confidence that emails they receive from financial organisations are in fact genuine rather than spam or phishing emails attempting to dupe them of their account details and ultimately cash.
The key will be shown next to the from name of the sender when Google knows that the sender is genuine. This will in turn provide confidence to end users that the email is safe to open and click on.
The key (shown below) is similar to the blue envelope used by Goodmail certified mail which Yahoo! and AOL are partnered with. Goodmail can be used by any sender who is partnered with an ESP capable of sending goodmail certified messages provided their spam complaint rates fall below the Goodmail acceptable spam complaint threshold.

New Gmail anti-phishing key.
The google scheme however will likely be free but limited to a small amount of organisations for some time until it can be rolled out to a wide range of senders effectively by Google.
The idea of the scheme is that google will display a key icon next to mail it knows is genuine. Google say the following criteria must apply for a sender to be considered for the new scheme:
- The sender must be DKIM signing their outbound email
- The organisation sending the email is a target for phishing scams
- Google must be rejecting all other email claiming to be originating from these senders.
Right now this new feature is not mainstream and instead is available from within the Googlemail Labs section of the site and is restricted to only protecting users from email claiming to be from paypal or ebay at the moment.
If you have a googlemail/gmail account and wish to turn this feature on you can do so by Turning on “Authentication icon for verified senders” from the Labs tab under Settings.
Google hope to expand this feature in the future and allow more senders to join this scheme.
To read the google blog post on this new feature click here.
What are feedback loops (fbl’s) and how can they help my deliverability?
May 22nd
Feedback loops are schemes operated by ISP’s for email marketers, ESP’s and other organisations that send large amounts of email to optionally sign up for.
Typically to sign up the person or organisation applying for the feedback loop will need to prove that they are responsible for the mail being sent from the IP addresses or domains on which the feedback loop is being setup on so be prepared to fax or send documentation and to be able to receive email on your domains abuse address.
Once verified and the application is accepted by the ISP the ISP will then start emailing an email address defined within the application each time one of your emails is reported as spam by the subscriber by clicking the “this is spam”.
The email sent to this address will be an ARF message, abuse report format. This is an email identifying itself as an ARF message with an attachment of the original message that was sent to the complainant. The receiving mail server should pass this to either a human helpdesk if your volume is low to be unsubscribed from the list or alterntively be passed to a processing application if you send large volumes of email.
This processing application will read the ARF message and the email attached within it, identify either through the to email address or the headers in the message which subscriber is complaining and unsubscribe them from the lists automatically.
So how does this help me?
Although it may seem like a bit of a waste unsubscribing users who complain once, in the long term it will pay dividends. By unsubscribing users who complain once you are reducing the likelihood of them complaining again, this means your overall complaint rate per IP or domain is kept low which is the key metric that ISP’s use to choose whether or not to deliver your messages. By keeping your complaint rate low from your messages to ISP’s which have feedback loops they are much more likely to allow your messages straight through to the inbox ensuring you continue to get your emails to the subscribers who actually want to receive them.
In addition, some ISP’s, after you have established a good record on their feedback loop, will actually allow you to apply for a whitelist which allows you to skip some if not all of the spam filtering that they use. AOL for instance is one ISP which operates a whitelist scheme in addition to a feedback loop.
For a full list of feedback loops and information on how to sign up, click here.
If you use an ESP to deliver your campaigns on your behalf, they should already have these feedback loops in place. Ask them and if not see if these can be implemented on your behalf.
Why should I implement a SPF record on my domain?
May 19th
In our earlier post titled ‘What is SPF?‘ we established what sender policy framework was and how it works.
This time Email Manual will look at the reasons for implementing an SPF record on your domain and discussing the common objection.
Prevent potential damage to your brand.
By implementing an SPF record (sender policy framework) spammers and phishers are less likely to choose your domain as their ‘cover’ domain.
This is because spammers will seek domains which do not implement any form of email authentication as there is a higher chance they will get through spam filters at the receiving domain. Without SPF/email authentication when the remote mail server receives an email it will have no way to verify or check whether the email is likely to be genuine or not and will therefore have to rely on unreliable content filtering to establish whether the email is likely to be spam or not. Content filtering relies on patterns like words or phrases within the body or subject of the message and the receiving mail server will make a decision on whether your email is genuine purely on the content of your message. With SPF the spam filter at the remote mail server will be able to make a more informed decision as to whether the message is genuine or not.
If you do implement SPF however it is still possible that spammers will attempt to use your domain as their cover domain and attempt to deliver messages using it. When this happens the remote mail server will check against your SPF record and recognize that the source of the email it has just received is not authorised to send email for your domain and is likely to block or quarantine your message. This means that if your customers or potential customers are the target of the spam the vast majority of the emails will be blocked which will reduce the impact to any of your non internet savy client base. In addition to helping your own client base and protecting your own brand you are also allowing the wider internet community to cut down on the amount of spam on the internet by being able to pickup on more of it and block it.
SPF can also help you reduce the amount of users that blacklist your domain. Lets imagine a scenario when you have not implemented SPF, a spammer has successfully delivered email to many domains around the word seemingly coming from your domain/brand. In this instance there are likely to be many people around the world marking these emails as spam. Many spam filters use bayesian techniques for the spam filter to “auto learn”. This means that once a user has marked an email coming from your domain as spam, the spam filter will analyse every part of the email, looking for phrases, html patterns, images and the from domain and email address. If the spammer is sending many different emails using your domain one of the few things that will remain consistent will be your domain name and the spam filter will pickup on this. If you then send the mail server that has auto learnt about your domain and the large amount of spam coming from it, a genuine email, the chances are it will be blocked. The chances of this happening will be much reduced if you had implemented SPF.
Spam filters don’t only negatively score emails which fail the SPF check. If an email from a domain passes an SPF check, it is quite feasible that the administrator of that spam filter has added a policy to positively score that email. This means that genuine email from your domain is MORE likely to be delivered to the inbox of the person you are sending an email to.
In Summary then the reasons for implementing SPF are :-
- You domain is less likely to be used by a spammer.
- If your domain is used by a spammer, the emails are far more likely to get blocked.
- You help reduce the amount of overall spam on the internet.
- Your domain is less likely to be blacklisted by bayesian spam filters.
- Genuine email is more likely to get through spam filters.
That being said however, the biggest objection to SPF is that many people think that it ‘breaks’ email forwarding. This is where the email is received by one mail server and then forwards it to another for a particular account or domain. Although this is true if the email server receiving the forwarded mail does inbound SPF checking there are several workarounds you can put in place.
One of most commonly used workarounds is to whitelist the mail server that forwards mail to your own. This means that it can fail the SPF check but you can still choose to allow the email through. The vast majority of mail servers allow whitelisting and this is normally very easy to implement. If you however can not support whitelisting there is another option. The other option is that instead of forwarding from the original domain that the email was sent from, you can instead “resend” the email, e.g take the contents of the original email, put it into a new email and send it from a domain which will not fail SPF checks.
I think you will agree that the benefits far outway the negatives, especially as only a small percentage of domains and users forward mail so no doubt you now want to know how you can go about implementing your SPF record on your domain(s). Email Manual will be posting a guide tomorrow on how to create your SPF record and within a couple of days we will have a guide on how you can implement the SPF record on both BIND and Microsoft DNS servers, why not subscribe via twitter or our RSS feed to be notified of when these guides are available.
What is SPF (Sender Policy Framework)?
May 18th
SPF, or sender policy framework is a non-commercial open standard designed to help IT administrators reduce inbound spam to their users and help prevent their domain being spoofed by spammers or phishers.
SPF works by allowing domain owners to publish via TXT DNS records to the internet which IP’s, hostnames and servers are authorised to send email from that domain. The idea being that the receiving mail server will check the DNS records for the domain claiming to be sending the email to ensure the source IP which an inbound email originated from IS authorised to send email on behalf of that domain.
A typical SPF record assuming the inbound and outbound mail servers shared the same IP would look as follows:-
“v=spf1 a mx –all”
- A – the A record of the domain e.g usually the web server.
- MX – any of the MX records for the domain e.g the servers which accept inbound email for this domain.
In the example of emailmanual.co.uk this means that the following IPs and hosts would be allowed to send email for this domain:-
- A – 146.101.148.154
- MX – mail.emailmanual.co.uk and mail10.emailmanual.co.uk – 146.101.148.129 and 146.101.148.154
SPF also allows for an administrator to define during implementation through the use of switches how harshly email which fails the SPF check should be treated.
The different types of SPF switch:
- ?all – Indicates that this domain is testing SPF and that the record should be ignored for the most part.
- ~all – Indicates that the domain has published its SPF record and if an email fails the SPF check for this domain it should be treated as a softfail.
- -all – Indicates that the domain has published its SPF record and if an email fails the SPF check for this domain it should be treated as a hardfail.
It is at the receiving domain administrators discretion what they do with the email which fails the SPF check and different types of failure can be treated in different ways. Mail administrators may choose to:
- Bounce all email that fails the SPF check
- Bounce email that hard fails and quarantine email that softfails
- Mark email that fails whether hard or soft failures as spam but deliver them.
- Any combination of the above.
This is part of the EmailManual series on SPF, coming soon:-
- Why should I introduce SPF on my domain?
- A guide to implementing SPF on Windows DNS server.
- A guide to implementing SPF on Bind.
Online Trust Alliance shows more than 50% of .Gov domains do not comply with Email Authentication Standards
May 12th
Further to yesterdays article on fortune 500 companies and US government domains and their non-compliance to adhere to widely used email authentication standards we thought you might like to see the Online Trust Alliance findings for the .gov domains.
Government Agencies such as the Whitehouse, Secret Service and the Federal Communications Commission all fail to adhere to these standards.
A full list of .Gov domains which were analyzed is available from the OTA here.
Brands must do more to protect their subscribers from phishing.
May 11th
According to the OTA (Online Trust Alliance) organisations must do more to protect their email subscribers from being victims of phishing scams.
Phishing scams are emails sent by a spammer which mimics a well known brand in order to get the subscriber to disclose usernames and passwords or other personal information. For instance every one of us has received an email claiming to be from our banks. Most of these are easy to spot and consequently easy to ignore but some are not. Spammers will often put in considerable effort, registering similar domains to the genuine brand, putting many hours into the site design containing the genuine brands logos etc which often makes them indistinguishable to the average internet user.
The online trust alliance released a report last month claiming that 56% of .gov Web sites and 45% of leading e-commerce sites are not taking appropriate e-mail and domain security measures.
The report measured 25 government domains, as well as the top 300 online retailers as measured by sales volume during a 10 day period last month.
Analysis was done against the DNS records of the US government and ecommerce sites which shows whether the organisation uses SPF, Domain keys or its slightly younger sister, DKIM and found that a huge percentage of these domains had not adopted one of these email authentication technologies which allows spam filters to pickup on phishing emails/spam and either block or quarantine them.
Whilst big brands and government organisations continue to fail to adopt these sorts of technologies there will always be successful phishing scams. If large organisations like these started to adopt these technologies, spam filters could become more aggressive against domains that don’t authenticate correctly which will apply pressure for smaller brands and individual companies to follow suit which would dramatically help reduce the amount of phishing and spam emails sent across the globe.
A Gartner survey of 5,000 adults in the US estimated that 24.4 million Americans have been duped by a phishing e-mail in 2006. If the larger organisations did their bit in helping IT departments block these sorts of emails it would undoubtedly save the economy millions of pounds which are lost to fraudsters every year.
Email Manual Recommendations:
- Implement SPF on your domain, initally with softfail, then switch to hardfail once you have gained confidence.
- Implement Domain Keys/DKIM on outbound email.
- Block inbound email which hardfails SPF checks.
- Block inbound email which is not Domain key/DKIM signed where the policy record for the domain indicates all mail should be signed.

