To authenticate email from Kit, formerly ConvertKit, configure a verified sending domain, publish the records displayed in your account, and click Validate. This is a CNAME-based authentication workflow, not an instruction to paste a universal ConvertKit include into your root SPF policy. Keep existing DMARC protection intact, then confirm that a real broadcast or automation uses the intended domain and passes receiver-side authentication.
On this page
- Choose the correct sending identity
- Set up the verified sending domain
- Understand SPF and DKIM
- Keep existing DMARC protection
- Validate DNS and real messages
- Troubleshoot the failing layer
- Frequently asked questions
Choose the correct sending identity
This guide covers Kit's own email-sending service and verified sending domain workflow. A website domain attached to a landing page is not sufficient evidence that outgoing email is authenticated. Likewise, a connected employee mailbox remains a separate sending system. Configure that route separately using EmailAuth's Google Workspace authentication guide if your organization uses Workspace.
Use a domain you control and a recognizable From address. Kit's current instructions support both a root domain and a subdomain as verified sending domains. The documentation reviewed does not state a paid-plan prerequisite for this setup; do not infer that a missing control requires an upgrade without checking your account permissions and current support guidance. Kit verified-domain instructions.
Before domain setup, confirm the intended sending email address in Settings → Email using the confirmation link delivered to that mailbox. If it remains pending, check that mailbox and its spam folder; DNS validation does not complete address confirmation. Kit pending-address guidance.
Before changing DNS, create a short inventory: account, intended From address, broadcasts, sequences and automations using it, DNS host, existing records and responsible administrator. Include other senders using the domain. Save the old DNS values and TTLs before adding anything.
Decide whether you are changing just authentication or also changing the recognizable From address. Avoid combining a new identity, a large audience expansion and an authentication migration in one send. That makes failures harder to diagnose. Kit recommends starting with engaged subscribers, reducing exposure to cold subscribers, and avoiding simultaneous major changes during a verified-domain rollout. Those are rollout recommendations, not a guarantee of reputation or a fixed recovery date. Kit's preparation guidance.
Set up the verified sending domain
Open Settings → Email → Verified Sending Domains, choose the setup or add-domain option, and enter the domain or subdomain you will use. The current interface offers automatic setup through Entri or manual publication. For the manual route, copy the displayed record types, complete owners and targets into your DNS host, then click Validate. A verified result completes the provider's DNS check, not the delivered-message test. Current Kit procedure.
Do not reconstruct records from a screenshot or use another customer's target. Record values can be changed by the provider, and the account display resolves ambiguity about which names belong to this configuration. Copy every required record, including alternate DKIM selectors, rather than only the one you happen to recognize.
If choosing automatic setup, review the requested access and proposed changes before approving. An automatic DNS assistant is convenient, but it is still changing a live zone. Preserve a before-and-after record and verify that existing sender authorizations and DMARC settings remain intact. Use manual setup when you need to coordinate a shared zone or cannot confidently review the automated changes.
For manual publication, identify the authoritative DNS provider through the domain's nameservers. It may differ from both the registrar and website host. A record entered into an inactive DNS dashboard does not become public merely because that dashboard accepts it.
A CNAME owner and target are different fields. The owner belongs under your domain; the target is the hostname supplied by Kit. Neither should include https://, a URL path, or email-address syntax. If a relative-name DNS editor already appends example.com, enter only the owner portion preceding that suffix. For a subdomain-based configuration, retain the additional subdomain label. Do not shorten a name until you know which zone the editor manages.
For an illustrative issued owner SELECTOR._domainkey.news.example.com, a suffix-appending editor for example.com uses SELECTOR._domainkey.news; one for a separately delegated news.example.com uses SELECTOR._domainkey. If _domainkey.news.example.com itself is delegated, use SELECTOR with that zone's administrator. A full-name field takes the complete owner. Use the actual account selector, not this placeholder. Preserve existing NS delegations and active selectors, and publish with the actual authority rather than adding an inactive parent-zone copy. Do not change nameservers, DNSSEC, mailbox MX or forwarding merely to publish a key. DNS zone boundaries.
Check for conflicts first. A CNAME cannot ordinarily coexist with TXT, MX or other ordinary records at the same owner. Do not delete the conflicting entry blindly; identify its purpose and coordinate a different supported name or configuration. Authentication records should not displace your website or inbound-mail routing. DNS CNAME rules.
Where literal CNAME answers are required, use DNS-only aliases returning the exact issued targets, without HTTP proxying or flattening hiding them. Turn the relevant per-record Flatten control off when available and ensure applicable zone-wide 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 sending service. Do not blindly change the whole zone or remove an existing NS delegation. Cloudflare CNAME verification, flattening controls and limits.
Understand SPF and DKIM
Kit describes its default envelope identity as a Kit address. A verified sending domain moves authentication onto your domain, including SPF and DKIM. Inspect the delivered message to determine the exact MAIL FROM and signing names used for your route. The setup is not equivalent to authorizing Kit in whichever SPF record happens to exist at your domain root. Kit's identity explanation.
SPF evaluates the envelope MAIL FROM domain, not the friendly From address people see. Follow a delegated CNAME to the policy behind that name when investigating SPF. If MAIL FROM is a subdomain, a lookup of only example.com can be irrelevant to the message being investigated. SPF standard.
Preserve root SPF authorizations for existing mailbox and application senders. Do not add a second SPF policy at the same owner, and do not “merge” a Kit CNAME into an SPF TXT string. If another service legitimately needs an SPF change, review the complete policy, including nested DNS-querying terms against the limit of ten. Avoid speculative includes and unmanaged flattened IP lists.
DKIM uses a private signing key at the sender and a public key retrievable through DNS. Kit's CNAME records delegate key lookup to the supplied targets. Do not generate a new key independently and assume Kit will use its matching private key. A public key's existence proves only that key material resolves; it does not prove any message was signed or that the signature verifies. DKIM standard.
Keep existing DMARC protection
Kit displays DMARC guidance within the verified-domain workflow and lets you validate the record. Its help page notes that an existing record may mean no new DMARC record is displayed. Check the actual published policy rather than assuming a missing suggestion is an error. Kit DMARC instructions.
Inspect the exact From domain and any applicable inherited parent policy before approving a new record. Preserve enforcement, authorized reporting destinations and alignment settings. In particular, adding p=none beneath a parent policy can weaken inherited protection. Never replace a working reject policy simply because a setup screen supplies a minimal example.
DMARC passes when at least one of SPF or DKIM both passes authentication and aligns with From. Relaxed alignment permits the same organizational domain; strict alignment requires exact domain equality. Thus a branded return-path subdomain may satisfy relaxed SPF alignment without satisfying aspf=s. Use the actual d= and MAIL FROM values to evaluate your policy, not a broad claim that verified domains always achieve strict alignment. RFC 9989, the current DMARC standard.
Only if no direct or applicable inherited policy exists, and the domain owner approves an appropriate monitoring plan, a first policy for fictional From domain example.com may be a TXT record at full owner _dmarc.example.com, relative _dmarc in zone example.com, with value v=DMARC1; p=none. Replace the domain, publish one policy, and do not use this to weaken existing protection. This minimal value requests no aggregate reports.
For an approved child-domain policy, _dmarc.news.example.com is relative _dmarc.news in zone example.com, or _dmarc in a separately delegated news.example.com zone. A full-name field uses the complete owner. These naming examples do not authorize a child override of inherited protection.
Assign someone to monitor the rollout and approve any functioning rua destination before adding it. Do not copy an unrelated reporting address. RFC 9989 supersedes RFC 7489 and removes pct; do not add that retired tag.
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 report receiver'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.
Validate DNS and real messages
First compare the public records against the account's current values. These read-only examples use placeholders; replace them with the actual full owners and authoritative server:
dig +short NS example.com
dig @ns1.example.net KIT_OWNER.example.com CNAME
dig @1.1.1.1 KIT_OWNER.example.com CNAME
dig @1.1.1.1 SELECTOR._domainkey.example.com TXT
dig @1.1.1.1 _dmarc.example.com TXT
The authoritative and public answers should show the expected CNAME destinations, with the DKIM lookup ultimately resolving to the provider's public key. Repeat for every issued owner. For SPF, query the actual MAIL FROM domain found in a received message and inspect the resolved policy. Save full error responses when troubleshooting; an empty abbreviated answer alone does not identify the cause.
After DNS is visible, run Validate in Kit. Its DMARC guidance allows for caching delays of 24–48 hours. Waiting does not fix a wrong owner, missing record or conflict. Kit validation guidance.
Next send authorized, controlled messages through the actual routes you will use: one broadcast and a representative sequence or automation. Use external recipient mailboxes where original headers are available. If a confirmation message uses a different From address, include that route too.
Capture the visible From, Return-Path, DKIM d= and s=, and receiver-generated Authentication-Results. For completion, require the intended Kit signature to pass DKIM and align with the unchanged approved branded From under the effective adkim policy, plus trusted receiver dmarc=pass for that From. A rewritten provider From, unrelated passing signature or DMARC passing through SPF alone does not prove this DKIM setup works. A provider verification badge or DNS checker is not a substitute for these observations.
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. Ignore attacker-supplied or otherwise untrusted fields; obtain receiver-controlled diagnostic evidence when provenance is uncertain. Operational receiving-result trust.
Investigate SPF independently at the observed smtp.mailfrom owner even when aligned DKIM makes DMARC pass. For fail or softfail, compare the connecting source with the applicable authorizations and actual route; for permerror, check duplicate policies, syntax and the nested DNS-querying-term limit; for temperror, investigate DNS availability and retest after recovery. A passing but unaligned provider-owned identity is different from these failures. Do not try to repair a provider-owned envelope policy by adding speculative root-domain includes. SPF results.
Store the send time, account, route, message identifier and sanitized headers. Keep baseline and post-change messages separate. Authentication does not guarantee inbox placement, and a marketing dashboard's open-rate movement is not evidence that SPF or DKIM failed.
Troubleshoot the failing layer
Validate stays pending: Recheck authoritative DNS, exact labels and target values. Look for a duplicated suffix, omitted subdomain label, TXT created instead of CNAME, or an alias hidden behind a web proxy. Preserve DNS-only resolution for authentication aliases.
SPF passes but is unaligned: Compare the envelope domain with From. Verify that the intended verified domain is actually being used. Do not add root SPF includes as a substitute for fixing route selection.
DKIM passes but DMARC fails: Check which signature passed and whether its d= matches the policy's alignment requirement. A service-domain signature alone is not evidence of your domain's aligned authentication.
DNS was changed after verification: Restore the account-issued records and retest. Kit specifically identifies changed or removed CNAME records as a possible cause of SPF and DKIM failures. Kit test-result troubleshooting.
Delivery changes after the switch: Compare headers first, then evaluate audience, volume and content separately. Do not erase a valid DMARC policy to address an unexplained engagement change.