When you create e-activist actions and/or Netdonor pages, then it's likely that you will send out email messages on behalf of your organization and your supporters. Here are the main examples (subject to how your actions are set up in our software):
Your supporter writes a message to a local politician: we send an email from your supporter to the local politician.
Your supporter adds their name to an online petition or writes a message to a local politician: we send a 'thank you' email from your organization to your supporter.
You send out a broadcast to all of your supporters: we send an email to each recipient from you to your supporters.
Technically what we are doing is called 'spoofing'. This essentially means that we are pretending to send emails from an email domain that is not within our control. To give you a specific example, let's say your supporter named John Smith - johnsmith@hotmail.com - writes to a local politician using our software. Let's say John Smith is writing to Mary Jones Member of Parliament. When the message sent by John Smith, coming from our email server, arrives at the email server that handles Mary Jones' incoming email, it will see that that sender is writing from a hotmail address. But Advocacy Online is clearly not hotmail, so we are pretending to send this email from hotmail to Mary Jones MP. We are 'spoofing' this email.
Generally, 'spoofing email' is not a problem because there are millions of emails that are 'spoofed' every day. However, sticking with the example above, if Mary Jones' email server was set up to check if the email from John Smith was sent by a server authorized by hotmail to send out an email from its domain, it could do so. Mary Jones' email server would look up the DNS record (all domains have one) for hotmail.com to see if our server was one of the servers authorized by hotmail to send emails from its domain. They would be looking at the DNS record to see if hotmail had a 'sender policy framework' or SPF record for their domain. The SPF record would tell the server if the IP address for the server that sent the email is authorized by the domain administrators to do so. If the SPF record did not list the IP address for our email server, it could decide to reject the email or put it in the spam folder.
An increasing percentage of email domains maintain SPF records (50% post filtered mail in 2009 according to Wikipedia) and the number is growing. It's not known what percentage of email servers check the SPF records for all incoming emails. A relatively small percentage of servers completely reject mail if an SPF check fails.
So what does this mean? There isn't very much we can do in the context of the specific example above because hotmail will never authorize our servers to send mail from their domain (and your supporters will be using hundreds of different email domains in their email address).
But, whenever we send 'thank you' emails from you to your supporters after they take action in one of your campaigns, or whenever we deliver an email broadcast to your supporters, it is possible to improve deliverability by creating and implementing an SPF record for your sending domains.
If your 'thank you' emails, or outbound broadcast emails, are being sent from a domain that is being used to send and receive emails beyond the emails generated via Engaging Networks, then you need to amend your existing SPF record. This assumes that you already have an SPF record. If you don't already have an SPF record in place then you need to create one that includes your email servers and Engaging Networks' email servers.
For example, if Oxfam was sending 'thank you' emails to supporters from campaigns@oxfam.org.uk, and this domain is also being used by Oxfam staff to send and receive emails via their own mail servers, then Oxfam would have to amend their existing SPF records to add the Engaging Networks mail servers (or create a new one if they didn't already have an SPF policy).
In many cases, organizations will create a specific email domain for use with emails generated by Engaging Networks. So Oxfam could, to continue with the same example, register a new domain like www.oxfammail.org.uk and create DNS host records that confirmed our servers as the authoritative servers to manage mail for this domain (we can provide you with the IP addresses to enter). Oxfam could then also create a new SPF record specifically for this domain to further improve deliverability. So they would then send out 'thank you' emails and broadcasts from campaigns@oxfammail.org.uk. If a recipient email server checked to see if the Engaging Networks servers were authorized to send emails from this domain, the answer would come back as positive.
Creating an SPF record and adding an SPF record to your DNS entries should only be done by someone who is familiar with the process. SPF records are in fact text entries and each ISP that hosts DNS records will provide different facilities to create and add SPF records.
The first step is to create the SPF record itself, which should be done by your IT department or ISP. If you are updating an existing SPF record please speak with your ISP about amending this record and using the appropriate syntax. Once your SPF record (text file) is created using the steps below, you will then need to add this text file to your DNS record. Again, this is something your IT department or ISP should implement since it involves your DNS record.
The following rule should be added to your SPF record by your IT department or ISP:
include:_spf.e-activist.com
You should avoid creating more than one rule (i.e. more than one line that begins v=spf1). See below for examples of merging rules into one line.
For example: if you are only using Engaging Networks to send emails 'from' the given email address (so there are no additional IP addresses required for other mail servers), the full rule would just be:
v=spf1 include:_spf.e-activist.com ~all
However, if you need to include additional IP addresses because you send emails from other mail servers as well, the rule will have the following form (these are example IPs, you will need to drop the real ones into place):
v=spf1 mx ip4:66.11.156.248/29 ip4:66.11.152.144/29 include:_spf.e-activist.com ~all
© Engaging Networks | Company registered in England and Wales | Company number: 03848111