SharpSpring SPF, DKIM and DMARC setup, step by step

Authenticate SharpSpring marketing mail using the Constant Contact Lead Gen & CRM domain workflow. Verify the sending domain, retrieve its generated CNAME records, publish the authentication records and run Verify. The managed em return-path record handles SPF; two DKIM CNAMEs support branded signing. Do not substitute Constant Contact Email and Digital Marketing instructions or another account's targets. Official authentication guide

No account configuration, DNS change or sending test was performed for this guide.

Confirm the product and sending route

The SharpSpring website links its marketing platform to Constant Contact; the relevant documentation is under Lead Gen & CRM. The official authentication page explicitly distinguishes it from Email and Digital Marketing. A setup for one product is not evidence that the other is ready. SharpSpring platform

Use this guide for marketing messages transported by Lead Gen & CRM. For mail transported by a connected personal mailbox, identify that outbound service and use its authentication instructions. A connected inbox, branded website or working tracking link does not prove the marketing sender's identity.

Employee mail through Microsoft 365 is a separate sending route; retain its configuration and use the Microsoft 365 authentication guide for that service rather than treating these application records as its configuration.

Create a worksheet identifying the account instance, visible From addresses, DNS administrator, existing email services and campaign routes. Include automated messages and alternate senders. Plan tests for the identities actually used, not only the default newsletter address.

Verify ownership and prerequisites

Arrange administrator access and access to authoritative DNS. By default, only one domain per instance can be authenticated with SPF and DKIM. Ask Support about any extra-domain entitlement before planning a multi-brand rollout; do not assume every plan supports it.

Open Settings → Company Email Settings → Sending Domains & DNS → Add Domain. Enter an address you control, send the verification email and confirm through its link. Check the domain's status in the account. Existing active site tracking can verify a domain without another email. This proves ownership, not that branded DKIM is signing. Verifying domains

Save the current affected records and TTLs. Check whether em, selector names or optional branding owners already serve another application. Do not replace working records to resolve a collision; ask Support for a compatible configuration.

Retrieve records and activate authentication

Open Setup DNS for the verified domain. Some screens use DKIM & Sending Domains → Set Up DKIM → Get My CNAME Settings. Copy the generated owners and targets, publish em, s1 and s2, then return to Verify. A green DKIM status is the expected account confirmation. DNS cache changes can take up to 24 hours. Setup and activation

CNAMEs delegate public-key management and rotation to the provider. Name/Host identifies the DNS owner; Data/Value/Target identifies its destination. Some DNS hosts append the zone automatically. Inspect the final fully qualified owner so that a duplicated suffix does not send queries to the wrong place. Understanding CNAME records

For an illustrative issued owner s1._domainkey.news.example.com, a suffix-appending editor for example.com uses s1._domainkey.news; one for a separately delegated news.example.com zone uses s1._domainkey. If _domainkey.news.example.com itself is delegated, use relative s1 in that zone. A full-name field takes the complete issued owner. Replace the placeholder with the actual account selector, preserve existing NS delegations and active selectors, and publish with the actual authority rather than adding an inactive parent-zone copy. DNS zone boundaries. Apply the same owner mapping to the second issued selector, not a copied target from another instance.

Preserve these aliases. Do not flatten them into A/AAAA answers, proxy them through an HTTP service or replace them with a snapshot of a public key. Do not put another record type at the same CNAME owner. If the DNS panel rejects underscores, ask the DNS provider to support the selector name; moving all DNS is a separate change, not the first troubleshooting step.

Where the issued authentication or return-path records require literal CNAME answers, use DNS-only aliases returning the exact targets, without an HTTP proxy or flattening hiding them. Turn the relevant per-record Flatten control off when available and ensure applicable zone settings preserve those aliases. Cloudflare documents that 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 apex/same-zone behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration with the DNS owner and sender. Do not blindly change the whole zone or remove an existing delegation. CNAME verification, flattening controls and limits.

Treat link branding as a separate decision

Check HTTPS and HSTS includeSubDomains before enabling optional link branding. The provider warns that adding and later removing link/owner can break real campaign links and tracking even when test-email links work. Coordinate removal with Support. Link-security warning

A DKIM pass does not prove that tracked links open successfully. Conversely, a working branded link says nothing about the signing identity. Maintain separate authentication and link acceptance checks.

Evaluate SPF at the actual envelope owner

SPF checks the SMTP MAIL FROM identity, usually represented in the delivered Return-Path, rather than the visible From header. Inspect the generated em alias and its resolved policy. Preserve corporate authorizations at the root instead of adding a guessed SharpSpring include. Provider SPF lookup instructions

At an owner publishing SPF directly, keep one v=spf1 TXT record. Preserve legitimate authorizations and the existing terminal policy. The ten-term limit applies to DNS-triggering terms actually evaluated, including nested include, a, mx, exists, ptr and redirect, not merely ten top-level includes. Multiple SPF records and excess evaluated terms can produce permerror. Root SPF is not inherited by a subdomain. SPF specification

If the existing SPF policy uses redirect=, reconcile its authorizations and terminal behavior with the DNS owner before changing it. Any all mechanism makes redirect ignored regardless of their order. Do not append all automatically: preserve the redirected senders and approved policy semantics through a reviewed design. SPF all and redirect processing.

For a managed-target error, retain the alias chain, timestamp, MAIL FROM identity and result for Support. Do not replace the service with today's IP addresses. For a policy you control, remove only confirmed obsolete authorizations after an inventory, then retest the affected routes.

Preserve DMARC and verify alignment

DMARC requires either aligned SPF or aligned DKIM to pass. Relaxed alignment compares organizational domains; strict alignment requires an exact match. Thus em.example.com and example.com can align under relaxed SPF but not strict SPF. An aligned branded DKIM pass can independently satisfy DMARC. Current DMARC standard

Inspect the From domain's policy and applicable inherited policy before accepting a generated suggestion. Preserve existing enforcement, reporting and alignment settings. Do not add a second record or weaken protection to obtain a checkmark.

Only if no direct or applicable inherited DMARC policy exists, and the domain owner approves this first policy and a monitoring/review plan, create one TXT record at full owner _dmarc.example.com with value v=DMARC1; p=none for fictional From domain example.com. This minimal value requests no reports; add rua only after provisioning an approved reporting destination and review process. Preserve established protection and authorized reports, and review all legitimate senders before enforcement. The obsolete pct tag is not a current rollout control. DMARC policy

For a first policy at full owner _dmarc.example.com, a relative-name field in zone example.com takes _dmarc. For a deliberately approved child policy at _dmarc.news.example.com, use _dmarc.news in the parent zone or _dmarc in a separately delegated news.example.com zone. A full-name field takes the complete owner. These examples do not authorize overriding an inherited policy.

Compare the Organizational Domain of the aggregate-report URI's host with the Organizational Domain of the domain where the DMARC policy was found, 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. Obtain the reporting operator's exact authorization instructions when required. This protocol check is separate from the domain owner's approval to share report data; agree access, retention and privacy. RFC 9990 section 4.

Do not automatically request ruf reports: message-level failure reporting needs a separate privacy decision. Failure reporting

Check DNS and a received marketing message

Replace the illustrative owners below with those generated for your instance. These commands only query DNS:

dig +short CNAME em.example.com
dig +short TXT em.example.com
dig +short CNAME s1._domainkey.example.com
dig +short TXT s1._domainkey.example.com
dig +short CNAME s2._domainkey.example.com
dig +short TXT _dmarc.example.com

CNAME answers must match the generated targets. Follow aliases until the envelope SPF and both DKIM public keys resolve. Compare authoritative and public-recursive answers when results differ. Empty output alone does not distinguish a missing record from a temporary DNS failure.

Establish which results were generated inside the receiving service's known processing boundary and how it removes, ignores or distinguishes externally supplied Authentication-Results. Use receiver-controlled diagnostics or have the receiving-mail administrator confirm its documented handling. A familiar authserv-id string or header position alone is not proof. Ignore attacker-supplied or otherwise untrusted fields; obtain authenticated receiving-system evidence when provenance is uncertain. Receiver-result trust.

After account verification, send an authorized small campaign through the intended marketing route. Use the external recipient's trusted Authentication-Results (receiver trust boundaries), not a copied sender-supplied header. Record:

• Visible From, Return-Path and smtp.mailfrom with SPF result.
• Each DKIM header.d, selector header.s and result.
• DMARC result and header.from.
• Message ID, UTC time, route and complete SMTP rejection text if relevant.

For this branded DKIM setup, require the intended Constant Contact Lead Gen & CRM signature to report dkim=pass and align with the unchanged approved branded From under the effective adkim policy, together with trusted receiver dmarc=pass for that From. Record the expected and observed d= and s=. A rewritten provider From, unrelated passing signature or SPF-only DMARC pass does not complete the intended DKIM deployment. DMARC itself permits either aligned passing method; this is the commissioned signer’s acceptance gate. Also require working envelope SPF, investigating it independently as below. Repeat for automation and alternate senders. Authentication is not an inbox-placement guarantee.

SPF must be investigated independently even when aligned DKIM makes DMARC pass. For an actual fail, compare the observed sending IP and MAIL FROM policy; for permerror, inspect syntax, duplicate policies and evaluated DNS terms; for temperror, check transient DNS availability and repeat the same-route test after recovery. Preserve the receiver result and timestamp rather than weakening DMARC to mask the error. SPF result definitions

Troubleshoot the failing layer

Only administrators can re-authenticate after DKIM becomes invalid. The official overview states that administrators receive notice and have 14 days to correct invalid DKIM before sending for that domain is blocked. This is a remediation deadline, not a DNS propagation estimate. Monitor their warning emails, especially after DNS migrations. DKIM overview

Before changing or retiring a domain, agree a scoped recovery plan with the campaign owner and provider: pause affected sends only when authorized, account for queued campaigns, and restore only an approved prior sender configuration. Preserve old signing selectors, shared dependencies and already-delivered tracking links through the provider-agreed transition. Retest actual mail after domain, instance, DNS or sending-route changes; restoring DNS alone does not prove account activation or link recovery.

Review boundary

This guide is based on public documentation. Actual plan entitlement, generated DNS, activation, receiver acceptance and link behavior remain account-specific checks. No live implementation or inbox-placement result is claimed.

Treat a domain-wide enforcement change as a separate decision after reviewing all legitimate routes. RFC 9989 section 7.4 requires valid DKIM for legitimate outbound mail when publishing p=reject and calls for attention to indirect-mail interoperability, including forwarding and mailing lists. A passing marketing campaign does not establish that every sender is ready.