SPF, DKIM & DMARC for Constant Contact.
Constant Contact authenticates your domain through what it calls "self-authentication" — a DKIM-based flow, not a shared SPF line you paste. Click your profile name (upper-right) -> My Account / Account settings, open the Advanced settings tab, and click Add self-authentication; there you pick "Self-authenticate using DKIM CNAME records" (the recommended option) and Constant Contact hands you two CNAME records that delegate DKIM signing back to its ccsend.com infrastructure, plus a starter DMARC record. Each CNAME sits on your domain as a ctct1._domainkey / ctct2._domainkey selector and points to Constant Contact's rotating signing keys at dkim1.ccsend.com / dkim2.ccsend.com. Once they resolve and you click Activate, Constant Contact signs your campaigns as your own domain, DMARC passes on DKIM alignment, and the "via ccsend.com / on behalf of" note Gmail attaches to unauthenticated Constant Contact mail disappears. There is no useful SPF include to add to your root domain — and, importantly, adding one would not make DMARC pass.
Why authenticate Constant Contact?
Self-authenticating your domain in Constant Contact is not housekeeping — it decides whether your campaigns reach the inbox. Since February 2024, Gmail and Yahoo have required every bulk sender (roughly 5,000+ messages a day) to pass SPF, DKIM, and DMARC with alignment, and Microsoft extended the same rules to its consumer inboxes (Outlook, Hotmail, Live) for high-volume senders in 2025. Until you self-authenticate, Constant Contact sends under its own shared domain: recipients see the mail isn't cryptographically from you, your From address doesn't align, DMARC can't pass, and your sending reputation is pooled with every other unauthenticated Constant Contact sender. There is a Constant Contact-specific twist that makes DKIM non-negotiable: Constant Contact keeps its own Return-Path on its bounce domain (shared1.ccsend.com for paid accounts, shared2.ccsend.com for trial), so SPF is always evaluated against ccsend.com and never aligns to your From domain — DKIM signed as your domain is the only mechanism that can carry your DMARC pass. Skip self-authentication and you have no aligned authentication at all. Since February 2024 Constant Contact DKIM-signs self-authenticated domains by default, so completing this flow is what flips signing on for your domain.
The SPF reality for Constant Contact
Constant Contact is a DKIM-CNAME provider, and here is the part almost every older tutorial gets wrong: there IS a shared include, spf.constantcontact.com (it really resolves — v=spf1 ip4:208.75.120.0/22 ip4:205.207.104.0/22 ~all, a single DNS lookup with no nested includes) — but adding it to your root SPF does nothing for DMARC. Constant Contact sends every campaign with an envelope sender / Return-Path on its own bounce domain (shared1.ccsend.com for paid accounts, shared2.ccsend.com for trial, both authorized under ccsend.com), because Constant Contact — not you — processes the bounces. SPF is always checked against that envelope domain, so SPF resolves and even passes against Constant Contact's servers, but it never aligns with your organizational From domain, and DMARC only counts SPF when it aligns. That is exactly why Constant Contact's self-authentication flow asks for DKIM CNAMEs and a DMARC record and never asks you to touch SPF: DKIM signed as d=yourdomain.com is the mechanism that aligns and carries your DMARC pass. You can safely leave spf.constantcontact.com off your root SPF — it passes the raw SPF check against Constant Contact's IPs but buys you zero DMARC alignment, while burning one of your 10 SPF lookups. Reserve your root SPF record for senders that actually put your domain in the Return-Path — Google Workspace, Microsoft 365, a transactional relay — and let DKIM do the work for Constant Contact.
Two ways to set it up
DKIM CNAME self-authentication (recommended)
- Two CNAME records (ctct1._domainkey / ctct2._domainkey) delegate DKIM to Constant Contact's ccsend.com signing keys
- Constant Contact holds the private keys and rotates the keys behind those selectors for you — you never re-edit DNS
- The simplest and most secure path; it's the option Constant Contact recommends
- Adds zero DNS lookups to your root SPF — CNAMEs don't count and there is nothing to merge
DKIM TXT record (manual key)
- Constant Contact generates a public/private key pair and shows one TXT record with a numeric, account-specific selector (like 10008432._domainkey)
- You paste the full v=DKIM1; k=rsa; p=... public key yourself
- No automatic key rotation — if the key ever changes you must re-publish it, and a stale key silently breaks DKIM
- Only worth it if your DNS host genuinely can't add the CNAME delegation
Step by step
- 1
Open self-authentication
Sign in, click your profile name (upper-right) -> My Account / Account settings, open the Advanced settings tab, and click Add self-authentication. If you lose the screen, return via Account settings -> Advanced settings -> self-authenticate.
- 2
Choose the CNAME method
Select 'Self-authenticate using DKIM CNAME records' and click Continue. This is the recommended path because Constant Contact manages key rotation for you. Only pick 'Self-authenticate using a DKIM TXT record' if your DNS host can't add CNAMEs.
- 3
Select your sending domain
Choose the domain that matches the From address on your campaigns (e.g. yourdomain.com). Self-authentication is per domain, so pick the exact one you send from, then click Continue to reveal the records.
- 4
Copy the two CNAME records
Constant Contact displays CNAME 1 and CNAME 2. Each has a Name/Host on your domain (a ctct1._domainkey / ctct2._domainkey selector) and a Value that points into Constant Contact's signing infrastructure (100._domainkey.dkim1.ccsend.com / 200._domainkey.dkim2.ccsend.com). Copy both exactly from the screen — don't hand-type them.
- 5
Add the two DKIM CNAMEs
At your DNS host create each as a CNAME record: Host = the ctct1/ctct2 _domainkey label Constant Contact lists, Value = the matching *.dkim*.ccsend.com target. Keep the type as CNAME (never A or TXT). If your registrar auto-appends your domain, enter just the selector label (e.g. ctct1._domainkey) so you don't double it.
- 6
Publish the DMARC record
Constant Contact's flow also gives you a starter DMARC TXT record (often just v=DMARC1; p=none;). Add it at host _dmarc; adding a rua=mailto:dmarc@yourdomain.com gives you the aggregate reports. Skip this only if you already have a _dmarc record — a domain must have exactly one.
- 7
Turn off the Cloudflare proxy
If your DNS is behind Cloudflare, set each DKIM CNAME to 'DNS only' (grey cloud). An orange-cloud proxied CNAME won't resolve to ccsend.com, and Constant Contact's Check status / Activate step will fail — a commonly reported Constant Contact + Cloudflare snag.
- 8
Check status, then Activate
Back in the self-authentication screen click Ok. Give DNS roughly 24-48 hours to propagate, then click Check status. Once the CNAMEs resolve, click Activate to switch on DKIM signing for your domain. Don't click too early — re-check after propagation rather than restarting the flow.
- 9
Send from the authenticated domain and check headers
Send a real campaign or test from an address on the authenticated domain, open it in Gmail, and use the three-dot menu -> Show original. Confirm DKIM: PASS with d=yourdomain.com (not ccsend.com) and DMARC: PASS. SPF will show the ccsend.com/shared domain and won't align — that's expected; DKIM carries the pass.
Records to add
Constant Contact generates the exact values in its setup wizard — these show the shape of what you'll add at your DNS host.
| Type | Host | Value |
|---|---|---|
| CNAME | ctct1._domainkey | 100._domainkey.dkim1.ccsend.comDKIM key 1 — the ctct1 selector on your domain is a CNAME that delegates to Constant Contact's shared, auto-rotated signing key at dkim1.ccsend.com. Illustrative: copy the exact Name/Value from the self-authentication screen. |
| CNAME | ctct2._domainkey | 200._domainkey.dkim2.ccsend.comDKIM key 2 — a second delegating CNAME (ctct2) to Constant Contact's dkim2.ccsend.com key lets Constant Contact rotate keys without you editing DNS. Illustrative — copy the exact values shown in your account. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comDMARC policy — Constant Contact provides a starter (often just v=DMARC1; p=none;) in the flow; adding rua= gives you the aggregate reports. Keep exactly one _dmarc record per domain; start at p=none and tighten later. |
| TXT | 10008432._domainkey | v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...(public key from Constant Contact)Alternative DKIM TXT method only — here the selector IS a number unique to your account (Constant Contact uses numeric selectors like 10008432 for TXT). No automatic key rotation; use only if you can't add the CNAMEs. Don't add this AND the CNAMEs. |
| TXT | @ | v=spf1 include:spf.constantcontact.com ~allLegacy/optional — NOT recommended and NOT needed. Constant Contact owns the Return-Path (shared1/shared2.ccsend.com), so this passes but never aligns and does nothing for DMARC, while costing 1 SPF lookup. Skip it and rely on DKIM. |
Keep exactly one SPF (v=spf1) TXT record on your root domain — merge every sender into it. Two SPF records is itself an error.
The 10-lookup budget
SPF is capped at a hard 10 DNS lookups — go over and it returns a permerror and stops validating everywhere. Here's what Constant Contact's setup costs against that budget.
Constant Contact's recommended setup adds 0 lookups — all 10 stay free for the senders that do need an include.
DKIM
DKIM is the whole game for Constant Contact — it's the only mechanism that can align to your domain — and there are two ways to set it up. The recommended path is DKIM CNAME self-authentication: Constant Contact hands you two CNAME records whose hosts sit on your domain as a ctct1._domainkey / ctct2._domainkey selector and whose values point into its signing infrastructure at 100._domainkey.dkim1.ccsend.com / 200._domainkey.dkim2.ccsend.com. Because those hosts are CNAMEs — not TXT records you paste — Constant Contact holds the private keys and rotates the published keys behind those shared selectors without you ever touching DNS again, which is why it calls this the simplest and most secure option and 'manages key rotation for you.' The alternative is the DKIM TXT method: Constant Contact generates a public/private key pair and shows a single TXT record whose host is a numeric, account-specific selector like 10008432._domainkey and whose value is v=DKIM1; k=rsa; p=<public key>. You paste that in, but Constant Contact can't rotate it for you — if the key ever changes you have to re-publish the TXT, and a stale key silently breaks DKIM, so prefer the CNAME method unless your DNS host can't do the delegation. Either way, publish the record(s), wait roughly 24-48 hours, click Check status, and then click Activate — signing only starts once the domain is Activated, after which Constant Contact signs your mail with d=yourdomain.com (the signature carries s=ctct1) so DKIM aligns and carries your DMARC pass. The exact host labels and values are shown on the self-authentication screen, so always copy them rather than reusing a tutorial's example.
DMARC
DMARC is a separate policy record on your domain, but Constant Contact is unusually helpful here — its self-authentication flow actually provides a starter DMARC record for you to publish, which many ESPs don't. Add it at _dmarc.yourdomain.com starting with v=DMARC1; p=none; (add rua=mailto:dmarc@yourdomain.com so you receive the aggregate reports). p=none is monitor-only: it changes nothing about delivery while you watch the aggregate (rua) reports to confirm your mail authenticates. The Constant Contact-specific thing to understand is that Constant Contact can only ever be DKIM-aligned — SPF is evaluated against its ccsend.com bounce domain and never aligns — so your DMARC pass rides entirely on DKIM (relaxed alignment, the default, matches the DKIM d=yourdomain.com to your organizational domain, and strict alignment works too since the signing domain is exactly yours). Watch the reports for a week or two to make sure Constant Contact and every other legitimate sender pass DKIM aligned, then ramp the policy to p=quarantine and eventually p=reject. Keep exactly one _dmarc record for the whole domain no matter how many senders you use — if you already have a _dmarc record, don't add Constant Contact's second one; just make sure your existing record is in place and covers this mail.
Check it actually worked
Don't trust Constant Contact's 'Activated' badge alone — confirm it on a real message. Send a campaign or test from an address on the self-authenticated domain, open it in Gmail, and choose the three-dot menu -> Show original: you want DKIM: PASS with signed-by / d=yourdomain.com (NOT ccsend.com), and DMARC: PASS. SPF will show the ccsend.com / shared bounce domain and won't align — that is expected and fine, because DKIM is what carries the pass for Constant Contact. Spot-check the raw records too: dig CNAME ctct1._domainkey.yourdomain.com should return the 100._domainkey.dkim1.ccsend.com target, and dig TXT _dmarc.yourdomain.com should return your policy. Then run your domain through Qualisend's domain health check to confirm both DKIM selector CNAMEs and the DMARC record resolve cleanly, and once DMARC aggregate reports start arriving, drop one into the DMARC report analyzer — Constant Contact should show up as a DKIM-aligned, passing source (with SPF unaligned, which is normal for this provider).
Common gotchas
- DNS setup
Adding include:spf.constantcontact.com does NOT make DMARC pass. Constant Contact owns the Return-Path (shared1.ccsend.com for paid, shared2.ccsend.com for trial), so SPF is checked against ccsend.com and never aligns to your domain. The include passes the raw SPF check but contributes nothing to DMARC — and needlessly costs one of your 10 SPF lookups. DKIM is the only aligned mechanism; leave SPF alone.
- DNS setup
Constant Contact can only be DKIM-aligned, never SPF-aligned. So if DMARC still fails, the fix is always DKIM (self-authentication published and Activated) — never chase an SPF include or Return-Path change, because Constant Contact doesn't let you own the envelope domain.
- DNS setup
Cloudflare proxy breaks it: set every DKIM CNAME to 'DNS only' (grey cloud). An orange-cloud proxied CNAME won't resolve to ccsend.com, so Check status and Activate fail — a widely reported Constant Contact + Cloudflare issue.
- DNS setup
Host-field doubling: many registrars auto-append your domain, so entering ctct1._domainkey.yourdomain.com becomes ctct1._domainkey.yourdomain.com.yourdomain.com. Enter just the selector label (e.g. ctct1._domainkey) if the panel adds the domain for you.
- Coverage
Give DNS 24-48 hours before clicking Check status. Clicking too early makes the status check fail; just re-run Check status after propagation rather than restarting the whole self-authentication flow.
- DNS setup
Copy the exact Name and Value from the self-authentication screen — don't hand-type or reuse another account's. With the CNAME method your hosts are a ctct1._domainkey / ctct2._domainkey selector pointing to Constant Contact's shared signing selectors (100._domainkey.dkim1.ccsend.com / 200._domainkey.dkim2.ccsend.com); with the TXT method the selector is instead a number unique to your account (like 10008432._domainkey). Either way the values are account-specific, and a mistyped or borrowed record silently fails DKIM.
- DNS setup
The DKIM CNAME method rotates keys automatically; the DKIM TXT method does not. If you pick TXT, a future key change means you must re-publish the record yourself, and a stale key silently breaks DKIM — prefer the CNAME method.
- Breaks auth
Self-authenticate the exact domain in your From address, and repeat for each one. A record on yourdomain.com does not authenticate a From on a subdomain or a second brand domain — every sending domain needs its own CNAMEs and its own DMARC coverage.
Build your SPF record
Constant Contact doesn't need an SPF include: on your root domain — use the generator to assemble one clean record for your other senders, and keep it to a single line.
Sending sources
Search for each platform you send email through and tick it.
Search for your email platform above, or .
This domain's own servers
Authorize the domain itself, if it sends mail directly (not through a platform above).
Other senders & IPs
Anything not in the list — another provider's SPF host, or specific IP addresses.
We add the include: prefix — enter the hostname your provider documents.
Policy for everyone else
What receivers should do with mail from any server not listed above (the all mechanism).
No senders yet, so every message would hit the ~all policy. Add the platforms you send through in step 1.
- Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
- Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
- Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.
Authentication published? The next step is sending to a clean, verified list.
Verify a listConstant Contact SPF — FAQ
Related reading
Once it's published, confirm everything resolves with the domain health check, then read who's sending as you with the DMARC report analyzer. Browse all sending sources in the generator. Authentication is only half of deliverability, though — a listed sending IP or domain still lands you in spam no matter how clean your SPF is, so it's worth watching the blacklists with blacklist monitoring.
Authenticated — now keep the list clean
Passing SPF, DKIM, and DMARC gets you to the inbox; a clean list keeps you there. Verify yours — start free with 100 credits, no card required.