Confirm the product and the message route
SharpSpring is now Constant Contact Lead Gen & CRM. The provider identifies it as a distinct product from Constant Contact Email and Digital Marketing. Use the Lead Gen & CRM instructions for this guide, even if an account, integration or billing screen still carries the SharpSpring name. SharpSpring rebrand notice, product identity and differences.
Identify whether the message is a marketing send through the platform or Smart Mail through a synced mailbox. The provider documents custom Mail Sync as sending Smart Mail through the user's SMTP account. That route needs authentication owned by the connected mail service, not an assumption that the marketing domain configuration covers it. Mail Sync for Custom Providers, Understanding Custom Mail Sync.
Inventory the instance, brands, intended From domains, automated templates and personal-mail routes. Assign an account administrator and DNS owner. This guide focuses on the platform's documented marketing-domain authentication and checks a synced-mail route only as a separate dependency. Do not apply instructions from the other Constant Contact product merely because the company name matches.
Plan around the default domain limit
The provider documents a default limit of one domain authenticated with DKIM and SPF per Lead Gen & CRM instance. Domain verification is a preceding step, not proof that signing is ready. The verification instructions use Company Email Settings and the sending-domain area; they offer a verification email and note that an existing working site-tracking configuration can establish verification without that email. Verifying Domains, verification workflow and default limit.
Check the existing authenticated domain before adding a second brand or changing a shared setting. Record which campaigns and automations rely on it. A second visible domain in a list must not be taken as proof that multiple domains can sign simultaneously under the account's entitlement. Obtain written provider confirmation for any configuration beyond the documented default.
If a domain change is planned, have the business owner approve the affected From identities and launch timing. Avoid switching an active instance while queued campaigns still expect the earlier domain. Keep a baseline received message and a pre-change export of the relevant DNS owners so the team can distinguish the new setup from historical working behavior.
Obtain the managed CNAME set from the instance
The current authentication page describes Company Email Settings, domain verification and a DNS setup tool; it also retains the labels DKIM & Sending Domains, Set Up DKIM and Get My CNAME Settings. Use the current account screen to obtain its issued values. The documented authentication records are the em, s1 and s2 CNAME entries, with link and owner treated separately for optional link branding. Return to the tool to verify publication. Lead Gen & CRM authentication, Getting Started and Setting Up DKIM and SPF.
Save each full record owner and target, including the record type, TTL and the account or instance that issued it. Do not copy a target from another organization's screenshot. If the interface presents a different arrangement, preserve that evidence and ask the provider to confirm its applicability before translating it into the older documented form.
The provider's CNAME explanation describes delegation of key management and provider-managed rotation. Its Name field identifies the DNS owner; Data supplies the target. A target hostname is not a DKIM public-key string to paste into TXT. Keep the issued CNAME relationship rather than flattening it into a copied downstream key. Understanding CNAME Records, CNAME Records.
Publish without breaking an existing owner
Query the proposed owners before making changes. A CNAME cannot simply be added alongside conflicting data at the same owner. If a hostname already serves another platform, stop and resolve the collision with both service owners. Do not delete a working website, tracking service or key to force the new record to validate.
Check whether the DNS editor appends the domain automatically. Compare the final fully qualified owner and target with the issued pair. Use DNS-only records where the DNS service offers a web-proxy mode that would otherwise obscure the alias, following that DNS service's documentation. Save authoritative answers and external resolver observations with timestamps.
The provider's CNAME guidance also discusses DNS hosts that reject underscores and recommends resolving that with the DNS provider or an appropriate supported domain arrangement. Removing the underscore is not a valid workaround: it changes the owner the verifier looks up. Understanding CNAME Records, CNAME Underscores.
Inspect the SPF identity through the issued envelope-related alias and the received message. Avoid adding a generic SendGrid or Constant Contact include at the apex as a substitute for this setup. A provider's underlying delivery service does not make every generic setup recipe appropriate to this instance. If an independent SPF edit is required, retain one policy at the evaluated owner and assess nested DNS lookups. RFC 7208, Selecting Records and DNS Lookup Limits.
Treat tracking links as a separate change
The authentication article warns that adding and later removing link and owner records on a secured site can break real-message links or tracking and may require backend support. Review that warning with the website owner before enabling optional branding. Its cal record belongs to Meetings custom-domain configuration, not the core authentication process. Lead Gen & CRM authentication, Understanding CNAME Records and Regarding Cal Records.
Keep optional branding outside the minimum authentication change when it is not needed. If it is needed, record the website's HTTPS and HSTS behavior, the proposed tracking owners and the provider-approved configuration. A browser test and a test-email preview are insufficient substitutes for clicking a harmless link in a controlled real marketing message.
Do not remove tracking records as a quick authentication rollback. Existing emails may still contain links that depend on them. Coordinate the recovery sequence with the provider and keep website routing intact. Record link-function acceptance separately from DNS verification and DMARC alignment so success in one area cannot conceal a failure in another.
Review DMARC alongside the generated instructions
The setup tool can present DMARC guidance, but the domain owner must reconcile it with any existing policy and reporting arrangement. Do not replace an established organization-wide policy simply because a product walkthrough shows a starter value. Record the relevant From domain, alignment mode and policy source before deciding what a passing test requires.
DMARC evaluates the relationship between the visible From and a qualifying SPF or DKIM pass. A branded return path or signing domain must still be checked under the applicable relaxed or strict comparison. Do not declare strict SPF alignment from an envelope subdomain when the From uses a different exact domain. RFC 9989, Identifier Alignment Explained and DMARC Evaluation.
Do not add an arbitrary reporting address from a screenshot. Reporting destinations should be approved and operated for the organization, with any required external authorization checked. A stronger policy is a separate rollout decision covering all legitimate senders, not a reward for completing one provider's DNS screen.
Test the marketing route after full publication
Run a controlled send using the actual marketing workflow and intended From address. Include harmless content and, if relevant, one safe tracking link. Test an automated template separately if it can supply a different sender. Retain the account or instance identifier, campaign identifier, Message-ID and UTC time.
Capture the receiver's trusted authentication results and original headers. Record the visible From, authenticated envelope domain, Return-Path and every DKIM d= and s= value. The selector and signing domain determine the key lookup; follow the published CNAME to its verification material when diagnosing a key problem. RFC 6376, The DKIM-Signature Header Field and Extract Signatures from the Message.
Record which mechanism provides the aligned pass. Provider verification, successful delivery and an apparent signed-by label are useful observations, but none alone proves the complete acceptance condition. Keep screenshots for context and raw receiver evidence for the technical conclusion.
If Smart Mail is also in scope, send a separate controlled message through the synced mailbox and identify that mail service's signer. Do not compare it against the marketing CNAME set as if it were the same route. A personal-mail success cannot close a failed campaign test, or vice versa.
Diagnose the failing layer before rotating keys
If domain ownership is verified but DKIM is not ready, inspect the issued CNAME set and its public resolution. If the expected signature is absent, check the actual From domain and sending workflow. If a signature fails, investigate the observed selector and downstream message changes before requesting a new key.
When an automation sends with an unexpected From, correct the approved template or sender choice and retest. When a link breaks but authentication passes, investigate the link-branding setup with support rather than changing authentication records. When the default domain limit blocks a desired configuration, resolve the account design rather than removing a working domain without a migration plan.
Keep support evidence minimal: instance identity, affected domain, issued public names and targets, timed DNS answers, message identifiers and relevant receiver results. Do not send mailbox passwords, account API secrets, contact lists or unrelated customer content.
Worksheet and fictional route confusion
Use the SharpSpring and Lead Gen CRM worksheet (create a separate review record with the fields described here) to separate product identity, entitlement, ownership verification, CNAME publication, optional links and receiver tests. Leave the personal-mail route as a distinct row with its own authentication owner.
Fictional written case LG-01: assume Smart Mail From alex@studio.example is sent through the connected mailbox with passing d=studio.example. The marketing campaign intends news@studio.example, but its em, s1 and s2 publication/verification is incomplete and campaign authentication results are unknown. The marketing administrator must complete the instance-issued CNAME checks and collect a separate controlled campaign. The salesperson’s result cannot close that route. No instance, mailbox, DNS record or campaign was accessed or tested.
Coordinate retirement and close only verified work
Before changing domains, decide how to pause new campaigns and preserve queued work. Keep old selectors and tracking dependencies for an agreed transition period, coordinated with provider signing behavior and existing links. Retest after a domain switch, instance migration, DNS move or mail-route change.
The documentary setup is available, but actual account entitlements, issued records, live DNS and received-message results have not been inspected for a customer. Independent technical review, visual review and human SME approval also remain pending. This unpublished draft does not certify inbox placement or a completed production authentication deployment.
Separate a passing message from enforcement readiness
RFC 9989 Section 7.4 requires valid DKIM for a domain publishing p=reject and cautions about indirect-mail interoperability. A single aligned SPF result does not by itself justify a reject-policy rollout. Review all legitimate routes and policy ownership separately from this provider setup.