Before we get started, I would like to say once and for all, here at Anchor;
we hate spammers. In saying this however, we do recognise that many of our customers have a legitimate requirement to send out large volumes of email to distribution lists in a largely automated fashion; some legitimate reasons may include sending periodic newsletters to an existing customer base or providing an update on products and services to prospective clients on a purely opt-in basis.
Through working in this industry and providing this solution for clients we've noticed a trend in recent times where legitimate emails can be flagged as spam and thus end up being blocked or trapped up in spam filters. This article is designed to cover off what steps can be taken to prevent this from happening to your cleverly crafted email. Before proceeding however, it is important to make sure that what you are doing is complaint with the Spam Act of 2003. Our article on
responsible email marketing covers the crux of this legislation in a nice, easy to read format without much of the legalese.
Basic Technical Configuration
The vast majority of the technical changes are things which will need to be setup by your hosting provider. If you're an Anchor customer, please
contact us and we can assist you with having this configured.
Use one unique IP address for mailouts
When sending out bulk email is it important to ensure that this email is coming from a consistent IP address. If you have a
dedicated server or a
virtual private server and all of the emails are going to originate from this machine, then there is a pretty safe bet than this is always going to happen. If the emails appear to come from various IP addresses for the one domain then mail servers start to assume that addresses are being
spoofed and start incorrectly flagging the email as spam.
Related to this is the concept of "IP reputation"; some providers, particularly Hotmail and Yahoo!, will not accept large volumes of mail from unknown IP addresses. Some spammers try to get around these "large volume" limits by spreading mail over a range of source addresses. This is called snow-shoeing and is considered to be malicious behaviour, so you really want to stick to using one or two IP addresses for mailouts.
Set a reverse DNS entry for an IP address and make sure that the forward look up matches
DNS is a detailed (but not overly complex) topic. Without getting too much into the nitty gritty, whenever you make a request for a web address say www.anchor.com.au your computer automatically translates this to an IP address so it can be found on the Internet. Translating from a hostname to an IP address, is technically referred to as a forward DNS look up. There is a second type of DNS look up which is commonly referred to as a reverse look up, which is not surprisingly, the exact inverse of a forward lookup. Ie, translating an IP address to a host name.
A large amount of spam originates from machines where the DNS does not match this configuration and it is becoming more and more common for email to be flagged as spam (or out-right rejected) if the DNS records are not consistent.
Make sure that the same (valid) email address appears in the "From" header for every email sent
This is rather straight-forward. Spammers often will try to use obfuscation to hide their true identify, and one easy method is to randomly generate a From address (or use many addresses from a larger pre-defined list). Maintaining a consistent address is going to increase the integrity and reputation of your mailings.
Use SPF (Sender Policy Framework) Records
Sender Policy Framework is a relatively new technique used to prevent sender address forgery. Unfortunately, when SMTP (which is the protocol largely behind the the delivery of email) was originally invented it was only every used to send messages from one machine to another machine on a small closed network. As such, there was very little need for sender verification as there was only a finite number of potential senders and a reply wouldn't get back to the original sender unless it was set correctly. Rapidly this method of communication grew, largely unchanged and ended up becoming adopted on larger scales. Before too long it got to the point where it become unwieldy to change the underlying protocol without interrupting mail flow for everyone on the internet.
As result, we're left with a system that allows email to be modified by ANYONE before it is sent to appear to come from someone totally different. This is in some large part why spam has become the Internet's ongoing plague.
SPF works by setting an additional DNS record on the domain to list all the servers which are allowed to send email appearing to originate from your domain. If you are planning on doing bulk emailing it is imperative that these get set correctly.
When setting this, it is important to keep in mind all mail servers where mail may originate from (such as your office or any other SMTP servers).
The following page can also assist with creating your SPF records
http://www.openspf.org/ however, ultimately, these will need to be applied by whoever is hosting the DNS on your domain.
Finally, as an important side note - SPF can in certain circumstances break mail forwarding. When implementing SPF records it is important to keep this in mind and make sure that your mail infrastructure is configured correctly.
Once again, If you are an
Anchor customer, this is something we can assist you with.
Domain Keys / DKIM
DomainKeys is a technology that seems to have come from various organisations in the email industry, in particular Yahoo!. Its purpose is to verify the domain of the sender and the integrity of any messages.
This standard has largely been ratified by the IETF and has more commonly become referred to as DKIM (
DomainKeys Identified Mail).
It is based on public-key cryptography to allow the sender to electronically sign legitimate emails in a way which can be confirmed by the recipient mail server.
This is a relatively new method which is yet to show a large adoption rate. This is something you will need to speak to either your
web hosting provider or resident system administrator about if you would like to implement it.
Policy Considerations
Subscription/Consent to receive
Without wanting to dwell too much on the Spam Act, by definition, spam is unsolicited email. So when sending bulk email, any recipient MUST have consented to receiving the email. Acceptable ways of a customer giving consent:
- Sending an email specifically requesting to be subscribed to a list
- Manually checking a box on a web form or within a piece of software
All requests should then be verified using a double-opt in mechanism.
A real world example of a double opt-in would include:
- Someone filling in a form on a website listing their email address requesting to receive a mailing list
- Email being sent to provided email address, with a link to click on to confirm consent to receive further emails.
The spam laws also state that you can also send emails providing if "inferred consent" has been provided.
For instance:
- You are allowed to send emails to your client or other stakeholders where an existing business relationship exists. Technically however, once this business relationship ceases to exist then you should have a mechanism in place to ensure that emails are no longer sent. To continue to do so may result in this being held against you as spam.
- You can send emails when someone has conspicuously published a work-related email address (for example on a website or publication) and the email relates directly to that person's line of work, unless the publication includes a statement saying that the person does not want to received unsolicited email.
This is where it gets a little bit vague and there is a lot of grey area and you will tend to find that many people disagree upon what is and isn't inferred consent in the second case. Keeping in mind that the most likely way to end up on blacklists is to have people complaining about received email saying it was unsolicited and the ambiguity surrounding this second section, if high percentage successful mail delivery is your aim then we would recommend sticking to people who genuinely want to see your email and avoid using the second inferred consent argument.
Unsubscribe and Maintenance of lists
Users must be able to unsubscribe from mailing lists. The method of unsubscribe must be obvious and simple, with information included in every bulk mailout sent.
Some common unsubscribe methods:
- A prominent link in the body of an email leading users to a page confirming his or her subscription (no input from the user, other than confirmation, should be required).
- By replying to your email with the word 'unsubscribe' in the body of the message.
Confirmation of successful unsubscription should be provided upon receipt of a request.
Also, processes should be in place to:
- Automatically unsubscribe emails that bounce
- Do not continually resend emails that receive permanent errors
- Periodically send confirmation messages to keep the list up-to-date
Most importantly, all methods must work consistently. If you are not actively taking this into account then having email delivery problems at some point in time is virtually inevitable.
Email Format
The following should be kept in mind when composing the email:
- If using HTML, emails must be formatted to w3.org standards.
- Messages should indicate that they are bulk mail, using the 'Precedence: bulk' header field.
- The subject of each message should be relevant to the body's content and not be misleading.
- Do not attempt to hide the true sender of the message or the true landing page for any web links contained in the message.
See also:
References/External Links
