I am working on creating an SPF (Sender Policy Framework) for our DNS, and need to include in our SPF record the Constant Contact domain so that emails sent out by Constant Contact using our domain name will not be bounced by email servers that look for SPF.
I have searched the discussion pages for SPF references, but have to date failed to find a response that includes an example of a working SPF setting for Constant Contact email.
I suspect the portion for Constant Contact will be mx:in.constantcontact.com, but would like to see some confirmation from anyone else who has already set this up.
We use a spam filter system from Sendio. This is a device that stands between our firewall and email server. They have been very helpful in helping us resolve issues like this. Based on the information I have from Const Contact and their examination dns lookup results, they recommend that our SPF record be configured thus:
The initial mx entry will allow any email coming from servers referenced by our own mx records hosted for our domain.
There are other sources of email using our domain, the rest of the entries document them:
mx:f2.ptassist.com - will allow in email sent on our behalf from this system, which one of our departments uses.
the prt:blackberry.net entry should allow emails sent by staff using blackberrys.
The two remaining ptr entries should accomodate messages coming from constant contact email servers. PRT requires an exact match, you can do this also by specifying IP address ranges (ip4: entries) but if the IP addresses used changes you are screwed. They recommended dropping the "in." part of the constant content domain references.
"-all" will require a match. The other commonly used option is "~all" which they tell me would still allow all messages though, tagged as "questionable" but still coming through so rendering your SPF efforts moot.
I think I am interpreting all of this correctly, but don't hold me responsible if I munged up translation.
It looks like once CC Authentication turned on, emails are constructed so that the email will still appear to to the recipient to come from your domain, and a reply will be sent directly to you, but in the email header (that the reader doesn't see) that SPF type authentication uses, they will embed a different sending email address domain, one that will be confirmed by CC as a valid match. This would not require any specific SPF inclusion on our part at all, but be handled entirely by CC.
The blackberry.net thus far has enabled our blackberry users to send and receive messages to clients and other users on our domain.
The two ptr other entries are for email sent on our behalf by Constant Contact. We are currently NOT using the Constant Contact Authentication feature.
I just sent a test message from Constant Contact and it delivered here just fine, so I can confirm that entry appears to be working as well.
I suspect that if we turned on the Constant Contact authentication feature that we would not have had to include the ptr entries for the two constant contact as they say that once turned on, they structure the email header so that the email appears to the receiving email server as sent from the CC server, with a return address that matches the email source, even though to the human recipient it shows a different sender/reply-to address.
I found it interesting that once the constant contact authentication feature is turned on, emails sent on your behalf from Constant Content will be coming from "ccsend.com" not constantcotnact.com or confirmedcc.com.