SPF record setting for Constant Contact

[sedacog]

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.

Can anyone help?

Thanks
SEDACOG ITG

[DadBlaze]

If you go to the My Settings tab, you should choose to have "Authentication" active -- and you will find that the sender is actually "ccsend.com"

So a simple TXT record like:
v=spf1 mx ptr include:ccsend.com ~all

Should probably handle it.

Of course, you can use the SPF Wizard to get a TXT record appropriate for your domain.

[BobB50]

This thread is the first result in Bing and Google searches when looking for "constant contact spf" and because it's so outdated it really needs taken down because it's now WRONG information.  The first response in the thread recommends including ccsend.com but that isn't even mentioned in the  knowledgebase article

The knowledgebase states to include constantcontact.com but nothing is said about ccsend.  According to openspf.org, this would likely cause an SPF check against your domain to fail, but even if it didn't, it's highly recommended to not use too many 'include' mechanisms:  "SPF implementations MUST limit the number of mechanisms and modifiers that do DNS lookups to at most 10 per SPF check, including any lookups caused by the use of the "include" mechanism or the "redirect" modifier"

HTH

(http://www(dot)openspf(dot)org/RFC_4408#processing-limits)

[sedacog]

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:

"v=spf1 mx mx:f2.ptassist.com ptr:constantcontact.com ptr:confirmedcc.com ptr:blackberry.net -all"

Read the record as follows:

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.

[DadBlaze]

Unfortunately, I don't have access to my email headers since I am at my "day job" (IT worker at the Kennedy Space Center).

However, in a SPF TXT record, you can always add additional hosts:

v=spf1 mx ptr include:ccsend.com include:constantcontact.com ~all

and that would solve your problem.

(Remember, if you use the domain, then any subdomains - in. or ccm16. would be included).

[sedacog]

I think what I am seeing is that both may work.
I did finally find some information here that describes the authentication you describe.

Constant Contact Authentication

From email address and Sender Header address.

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.

I expect that both solutions may work just fine.

[CyberNorris]

Thanks for that FAQ article with the domain names and IP addresses. That helped identify what needs to be in the SPF record.

I host my own domains and email... have done so since around '95. I also do information security consulting, including proper DNS setup.

Prior to this, only my inbound mail servers have been allowed to send email from my domain. Thus my SPF record was quite simple:

v=spf1 mx -all

This identifies that any MX record for the domain is allowed to send and nothing else.

After reading that FAQ article, my SPF record is now:

v=spf1 mx include:ccsend.com include:constantcontact.com include:confirmedcc.com -all

I added in the ccsend.com domain since it was mentioned here.

As noted above, you should not use the ~all as it negates the value of the SPF.

[sedacog]

Cyber,
The SPF record we are using right now is:

v=spf1 mx ptr:blackberry.net ptr:constantcontact.com ptr:confirmedcc.com -all

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.

[Amber_L]

Hello @BobB50,

Thank you for reaching out about this post coming up as the first result on your search. We don't have control over what posts will pull from searches in external tools, so we always recommend using the Knowledgebase directly, to make sure you're seeing the most up to date information. I apologize for any confusion this may have caused. It sounds like you were able to find the information you needed but we do have separate articles regarding self publishing and the Authentication option if you'd like to learn more. If you have additional questions, please reach out to our Account Review team directly, and they'll be more than happy to address any concerns! 

[BobB50]

Thanks for the reply, Amber.  It's just that the interwebs are becoming very cluttered with bad (read: outdated) information so, in a way, you can control what appears in a search engine by removing this thread.  Again, it's wrong information so why have it out there?  The thread is 11 years old.  I don't recall the last time I've read tech information from 11 years ago that's still relevant today.

[Frankie_P]

Hi @BobB50

I can completely understand the importance of sharing the correct information show. So thank you for bringing this to our attention! In the meantime, we will archive this thread so it may have restricted access. Making this change will help to adjust these search results over time.