Constant Contact's Email and Digital Marketing product authenticates your domain through DKIM self-authentication. Publish the records generated in your account, preserve your existing DMARC policy, activate the configuration, then check a delivered message. Adding a Constant Contact include to your root SPF record does not create SPF alignment: this product uses its own envelope-sender domain. Aligned DKIM is the important DMARC path. Constant Contact authentication overview.
Check the product and domain first
This guide covers Email and Digital Marketing, not Constant Contact Lead Gen & CRM. The latter has a separate Company Email Settings workflow and branded return-path configuration. Do not apply the Email and Digital Marketing SPF limitation to every product bearing the Constant Contact name. Lead Gen & CRM authentication documentation.
Teams and Partner-managed accounts have a separate shared-DKIM administration model. Confirm whether the parent organization controls authentication before using this individual-account procedure. Teams and Partner authentication.
Before changing anything, collect:
- The account and product name, intended visible From address, and domain being authenticated.
- Access to that domain's authoritative DNS, with an administrator available during the change.
- A copy of existing SPF, DKIM and DMARC records, including records used by your mailbox provider and other marketing systems.
- The list of Constant Contact accounts sharing this domain.
- A controlled recipient mailbox where you can view full message headers.
Treat this as a change to a live messaging system. Agree on a maintenance window, who can authorize DNS edits, and who will decide whether sending can resume. Export the relevant DNS entries before editing. A screenshot of the new settings alone is not a rollback record.
Verify the custom-domain email address in Constant Contact before selecting it as a From address. After self-authentication, use From addresses on the authenticated domain. Address and domain prerequisites.
You need a domain you control. A personal address at a public mailbox service does not give you access to that provider's DNS. Also distinguish the address people see from the Reply-To mailbox and the bounce address: changing one does not automatically change the others.
Does Constant Contact need an SPF record?
Not an extra root-domain SPF authorization for this sending route. Constant Contact documents that receivers check its SPF domain, rather than your visible From domain. Your message can therefore have SPF pass without SPF alignment. That is different from SPF authentication failing. Self-authenticated DKIM supplies the aligned identity used for DMARC. Official SPF explanation.
Keep the SPF record required by your other senders. Do not remove Microsoft 365, Google Workspace or another legitimate authorization merely because this article says Constant Contact does not need a root include. Conversely, adding another service to a root record cannot change the envelope identity of an already-sent message.
For employee mail through Microsoft 365, use the separate Microsoft 365 authentication guide. Its mailbox route and Constant Contact's campaign route need their own evidence.
An SPF owner name must not publish multiple SPF policies. If an unrelated sender requires an addition, merge it into the existing policy only after evaluating the complete configuration. SPF limits DNS-querying terms, including nested includes, to ten during evaluation. These are reasons to avoid speculative additions, not reasons to delete a record without understanding its users. SPF specification, RFC 7208.
Choose CNAME or TXT self-authentication
The current setup path is profile name → Settings → Advanced settings → Add self-authentication. Select your verified domain and the appropriate DKIM method. Constant Contact allows one authenticated domain per account; its TXT method is intended for multiple accounts sharing a domain. If the domain is already authenticated in another account, follow that TXT route rather than replacing the other account's CNAMEs.
For CNAME setup, copy every generated hostname and target. For TXT setup, coordinate the DNS change before selecting Generate key: the vendor warns that sending is unavailable until the generated key's DNS configuration propagates. Publish only the public record, never private key material. Complete Check status and Activate after DNS and DMARC are ready. Allow for the vendor's stated propagation window of up to 48 hours, without treating waiting as a fix for a wrong record. Official self-authentication steps.
Create a handover worksheet with one row for each generated record: purpose, type, complete owner name, complete value, account, and date copied. Leave values blank until you obtain them from the account. A selector shown in a screenshot or another company's support ticket is not a value you can safely reuse.
Publish the records without disturbing other mail
Map the provider's hostname to the DNS editor carefully. Some editors append the zone automatically. If the required full owner is SELECTOR._domainkey.example.com, a relative-name editor expects SELECTOR._domainkey; entering the full name there might create a doubled suffix. SELECTOR and example.com here are placeholders, not Constant Contact's issued record. Constant Contact DNS-host guidance.
For an issued full owner SELECTOR._domainkey.news.example.com, enter SELECTOR._domainkey.news in a suffix-appending example.com zone, or SELECTOR._domainkey in a separately delegated news.example.com zone. If _domainkey.news.example.com itself is delegated, enter SELECTOR with that zone's administrator. A full-name field takes the complete owner. These are naming illustrations, not account-generated values. Preserve existing NS delegation and active selectors; do not change nameservers, DNSSEC, mailbox MX or forwarding merely to expose a parent-zone record. DNS zone boundaries.
A CNAME value is a destination hostname, not a URL or a DKIM key. A DKIM TXT value is the complete public-key record, not a CNAME destination. Preserve punctuation and key data. Do not put DKIM text inside your DMARC policy, and do not combine different DKIM selectors into one record.
Check whether the proposed owner already has a record before saving. A CNAME cannot coexist with ordinary other data at the same owner name. If there is a conflict, identify its user and resolve the design with the account or DNS administrator rather than deleting it. Different selectors can support different sending systems on the same domain. DNS alias rules, RFC 1034.
For the CNAME self-authentication method only, apply these alias controls; they do not apply to the separate direct-TXT key method. Where literal CNAME answers are required, the end state is a DNS-only alias returning the exact issued target, without HTTP proxying or flattening hiding it. Turn the relevant per-record Flatten control off when available and ensure applicable zone-wide settings preserve those aliases. On Cloudflare, flatten-all cannot be overridden per record; apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are conditional DNS-host behaviors, not assumed controls in every panel. If mandatory behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration with the DNS owner and sending service. Do not blindly change the whole zone or remove an existing NS delegation. Cloudflare CNAME verification, flattening controls and limits.
Keep DMARC safe and understand alignment
DMARC succeeds when at least one passing SPF or DKIM identity aligns with the visible From domain. Relaxed alignment allows the same organizational domain; strict alignment requires an exact domain match. Thus a cryptographically valid DKIM signature from an unrelated service domain does not authenticate your brand for DMARC. Current DMARC standard, RFC 9989.
First inspect the existing policy at the applicable _dmarc name. Keep an established policy and reporting destinations; do not replace p=reject or p=quarantine with a generated starter record. Do not add a second DMARC policy. For a subdomain, also establish which parent policy applies before deciding a new child record is necessary.
Only if no direct or applicable inherited policy exists, and the domain owner approves an appropriate monitored rollout, a first policy may use this baseline:
Type: TXT
Full owner for From example.com: _dmarc.example.com
Relative owner in zone example.com: _dmarc
Value: v=DMARC1; p=none
Replace the example domain. For From news.example.com, the full owner is _dmarc.news.example.com; enter _dmarc.news in the parent example.com zone or _dmarc in a separately delegated news.example.com zone. A full-name editor uses the complete owner. Do not create a second policy or a child override of existing protection.
p=none requests no DMARC enforcement and does not itself request reports. Add an approved rua destination only with a monitoring and data-sharing plan. Check all legitimate senders before stronger enforcement. RFC 9989 supersedes RFC 7489 and removes pct; do not design a new rollout around that old percentage tag. DMARC policy discovery.
Compare the Organizational Domain of the aggregate-report URI's host with the Organizational Domain of the domain where the DMARC policy was found, which is not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as the policy domain is excepted; a different hostname alone does not make it external. Follow the reporting service's exact authorization instructions when needed. This protocol check is separate from the domain owner's approval to share report data with that recipient. RFC 9990 section 4.
Verify public DNS, then verify actual delivery
Use the exact names from the worksheet. These are read-only examples to adapt, not commands already run:
dig +short CNAME DKIM_OWNER_FQDN
dig +short TXT DKIM_OWNER_FQDN
dig +short TXT _dmarc.FROM_DOMAIN
For the CNAME method, expect the issued destination; resolve the destination's TXT record to inspect the public key. For the TXT method, expect the complete issued key at its selector owner. A successful DNS answer proves publication, not that the account is signing with that key. If cached and authoritative answers differ, compare them before changing the record again.
Once the account is activated, send an authorized, representative message to a mailbox you control. Use the intended campaign route and From address. Open the received message's raw source and record:
- Visible From domain and Return-Path domain.
- The receiving service's trusted
Authentication-Results. - DKIM result plus the signature's
d=signing domain ands=selector. - SPF result and
smtp.mailfromidentity. - DMARC result and
header.fromidentity.
A DKIM lookup is formed from s=, _domainkey, and d=. That ties the delivered message to the record you actually published. DKIM verification model, RFC 6376.
Establish which results were generated inside the receiving service's known processing boundary and how that service removes, ignores or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving-mail administrator to confirm the boundary. A familiar authserv-id string or header position alone is not proof. Reject attacker-supplied or otherwise untrusted fields; obtain the receiver's own diagnostic evidence when provenance is uncertain. Operational receiving-result trust.
Acceptance means the intended brand remains in From, the intended Constant Contact signature from this account passes DKIM and aligns with From, and the trusted receiver reports dmarc=pass for that From. SPF may pass using Constant Contact's domain without aligning. Do not reject a successful deployment solely for that expected mismatch. Save the sample date and route; a test from a different account does not validate this one.
Investigate actual SPF errors separately even when aligned DKIM makes DMARC pass. Use the observed smtp.mailfrom owner: fail or softfail calls for checking the connecting source and applicable authorization; permerror calls for duplicate-policy, syntax and nested lookup-limit checks; temperror calls for DNS-availability investigation and a retest after recovery. For a provider-owned envelope, give Constant Contact a minimized header sample through your approved support process. Do not try to repair its policy by adding a speculative include to your root. A passing but unaligned provider identity is not one of these errors. SPF result definitions.
Troubleshoot the failing layer
Hostname not found: compare the complete public name with the account worksheet. Check the authoritative DNS provider, doubled suffixes, wrong record type, and propagation. Constant Contact distinguishes not-found, invalid-name and invalid-value errors; use the actual error rather than rebuilding every record. Official troubleshooting.
Another account already authenticates the domain: review the shared-domain TXT method. Do not seize its selector by changing the target.
DNS looks right but DMARC fails: inspect the received message. Is the intended From domain present? Does the passing DKIM signature use that domain or an aligned domain? Is a strict policy requiring an exact match? Does its selector match the account you edited?
Sending stopped during TXT setup: compare the new generated public key with DNS and finish verification before resuming. Repeated key generation can make it harder to know which copy is current.
Authentication passes but messages reach spam: investigate consent, complaints, engagement, volume and content separately. Authentication is not an inbox guarantee, nor proof that a message's contents are trustworthy.