Keap SPF, DKIM and DMARC setup, step by step

Authenticate the sending domain in the Keap edition you actually use, publish that account's generated records, and wait for Connected before relying on the route. Ultimate and Classic expose Email Authentication under Marketing settings; Pro and Max use Domains and may present an Entri-assisted flow. Do not apply an old Infusionsoft SPF include or a generic three-record screenshot to every current account.

On this page

• Identify the edition and sending workflow
• Choose manual or assisted setup
• Publish the generated DNS records
• What to do about SPF
• Preserve DMARC without percentage assumptions
• Connect profiles and automation senders
• Verify DNS and received mail
• Troubleshoot by failure stage
• Frequently asked questions

Identify the edition and sending workflow

The Infusionsoft name appears in older DNS guidance, but current Keap help is hosted by Thryv and distinguishes editions and interfaces. This guide addresses Keap-generated email, not every Thryv service and not mail sent directly from an employee's connected mailbox provider.

Before touching DNS, record the Keap edition, application/account, visible From domains and relevant campaign or automation. Obtain access to domain-authentication settings and the authoritative DNS zone. Ask the account administrator to provide the necessary permissions if the settings are hidden. The reviewed documentation does not establish a universal role matrix or a paid add-on requirement for this task; do not infer either from a missing menu.

Export current DNS and identify the people responsible for DMARC policy and business automations. Include every sender profile, especially profiles selected dynamically as Contact Owner. A technically correct domain can still leave an automation unable to send when its selected user's address belongs to another domain.

Preserve other authorized sending services. If business mail also uses Microsoft 365, EmailAuth's Microsoft 365 authentication guide covers that separate route. Keap authentication should not replace its SPF policy or selectors.

Choose manual or assisted setup

Current official navigation distinguishes these routes:

• Ultimate / Classic: Open the hamburger menu, then Marketing → Settings → Email Authentication.
• Pro / Max: Open the profile menu, then Settings → Domains.

Connect the intended email domain. In the manual workflow, copy the account's three CNAME records, complete Finish, and check for Connected. If a generated name collides with existing DNS, the documented Conflict with your domain? control allows a custom prefix. Obtain the newly generated set rather than renaming just one DNS row yourself. Keap edition-specific authentication.

The linked current Pro/Max guide describes an Entri-assisted path and a manual alternative when the provider is unsupported. Preview the proposed record names, types and values before authorizing changes. That guide describes four records: SPF, two DKIM records and DMARC. Therefore, “Keap always needs only three CNAMEs” is not a safe universal instruction. Use the actual workflow presented to your account. Current Domains/Entri workflow.

In the Entri flow, wait until all four records show Created, select Finish, review the user-domain summary, then select Save and finish. Return to Email domains and verify the final connected state; finishing the wizard is not proof that verification has completed.

Treat assisted setup as a DNS change, not merely a sign-in convenience. Compare the proposed update with the existing zone export and stop if it would overwrite another sender or weaken policy. An authorized DNS administrator should complete any sign-in or permission grant. Never send DNS passwords to a support conversation or put them in a change ticket.

Publish the generated DNS records

For the manual three-CNAME workflow, the official example contains these owner shapes. APP_PREFIX and example.com below are placeholders; the targets cannot be supplied by a general article.

Use the built-in copy controls. Do not swap targets between rows, copy another tenant's application prefix, or turn a CNAME target into a TXT value. In the Entri/manual-alternative route, use its displayed record types instead of forcing the table above onto it.

The non-_domainkey alias and the two DKIM aliases perform different jobs. Publishing only one attractive-looking DKIM row is not a complete implementation. Keep the complete generated set together in the change record and compare it again after setup.

DNS editors differ in owner-name syntax. For the fully qualified owner APP_PREFIX1._domainkey.example.com, an editor that automatically appends example.com generally needs only APP_PREFIX1._domainkey. The target is a complete provider hostname, not a URL with https://. Inspect the saved public result to catch doubled suffixes. Keep email-authentication aliases DNS-only where a web-proxy option exists.

For an issued signing domain such as news.example.com, a full owner SELECTOR._domainkey.news.example.com is SELECTOR._domainkey.news relative to the parent example.com zone, or SELECTOR._domainkey in a separately delegated news.example.com zone. If _domainkey.news.example.com itself is delegated, the relative owner there is SELECTOR. Replace the selector placeholder with the issued value, preserve the account’s exact type and public value, and publish at the actual authority without removing the NS delegation. This example explains name placement, not automatic product eligibility for a new domain. DKIM owner construction, relative DNS names.

Also keep verification CNAMEs unflattened. DNS-only does not by itself exclude flattening: Cloudflare warns that flattening all CNAMEs can prevent third-party verification because the alias itself is not returned. Check the effective setting for the relevant records. Cloudflare CNAME flattening.

For authentication records that actually use CNAME, retain a literal CNAME answer to the issued target and use DNS-only rather than HTTP proxying. Turn the relevant per-record Flatten setting off where available, and ensure applicable whole-zone settings do not suppress the alias. 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 DNS-host behaviors, not assumed controls in the sending application. If mandatory behavior or shared settings cannot preserve the required CNAME answer, stop and coordinate a supported layout without breaking other services or removing shared NS delegations. Do not blindly disable features across the whole zone. Cloudflare verification guidance, flattening controls and limits.

A CNAME cannot share its exact owner with conflicting ordinary TXT, A or MX data. Do not delete another application's record to solve this. Use the supported conflict-prefix workflow, or have support confirm the correct route. Distinct selectors for different providers can coexist under the same domain. DNS CNAME rules.

What to do about SPF

Do not begin by adding include:infusionmail.com to the company root because an old article says so. The current official instructions establish account-generated workflows, including an SPF step in the newer assisted route. They do not establish one universal root-domain SPF recipe for every Keap edition and account.

First identify the actual envelope sender from a delivered Keap message. SPF evaluates that MAIL FROM domain. If it is provider-controlled, a root-domain SPF edit may have no effect on the evaluated policy. If the account-generated setup delegates a return-path owner or provides a particular SPF owner/value, implement that exact requirement rather than inventing an equivalent.

A successful SPF check does not necessarily align with the visible From domain. Conversely, an unaligned SPF pass does not mean SPF authentication failed. Keep those observations separate when reading a testing tool.

At a customer-controlled SPF TXT owner, maintain one v=spf1 policy, preserving existing authorized senders and the terminal policy. Assess the ten DNS-lookup-causing-term limit across nested includes before approving additions. Do not stack separate SPF TXT records or replace the root record with a Keap-only policy. SPF specification.

If an existing SPF policy uses redirect=, preserve its intended authorizations and final semantics through a reviewed merge. Any all mechanism causes redirect to be ignored, so appending a canned policy or an all without reviewing that dependency can change which senders are authorized. SPF redirect semantics.

Preserve DMARC without percentage assumptions

Read the applicable DMARC record before accepting any “create or update” option. Check both the actual From domain and any inherited parent policy. Existing quarantine or reject protection must not be silently replaced by a setup wizard's default. Preserve approved report destinations and strictness settings.

The manual Keap article illustrates p=quarantine; pct=5. Do not treat that as protection for only five percent of failing mail. RFC 9989 replaces RFC 7489 and removes pct. Do not use percentage-based enforcement as the rollout safety mechanism. Current DMARC standard.

For a genuinely new policy with no established applicable policy, the domain owner may approve monitoring first:

Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

This is an illustrative policy, not a record to paste unchanged. Use the real From domain and authorized reporting destination. Arrange external-report authorization where necessary. rua requests aggregate reports; it is not a forensic-report switch. Publish one DMARC record at the owner.

Compare the Organizational Domain of the aggregate-report URI host with the Organizational Domain of the domain where the DMARC policy was found, not automatically the visible From domain. If they differ, the report-generating receiver must check the destination’s DNS authorization. A destination in the same Organizational Domain as that policy domain is excepted, even when its hostname differs. This protocol check does not replace the domain owner’s separate approval to share report data with that recipient. RFC 9990 section 4.

For the approved first policy at From example.com, full TXT owner _dmarc.example.com maps to _dmarc in that zone. For From news.example.com, full owner _dmarc.news.example.com maps to _dmarc.news in the parent example.com zone or _dmarc in a separately delegated news.example.com zone. Publish at the actual authority and preserve any existing direct or inherited policy; this mapping does not authorize a child monitoring override.

A local subdomain monitoring policy can weaken inherited enforcement, so “no local record” is not enough to justify this example. If the wizard cannot preserve your approved policy, pause that portion and reconcile it with support rather than continuing with a weaker or premature enforcement setting.

DMARC passes when either SPF or DKIM passes and aligns. Relaxed alignment accepts the same organizational domain; strict alignment requires an exact domain match. Test all legitimate sending routes before tightening policy, including routes unrelated to Keap.

Connect profiles and automation senders

DNS publication is not the final activation gate. Confirm the domain is Connected, then make sure the sending profiles use addresses on connected domains. The current Domains flow distinguishes Pending, Unconnected and Invalid user-domain states. Pending is not a successful production acceptance result.

For Ultimate automations using Contact Owner as sender, audit every owner profile. Keap documents that these messages fail to send when the owner's domain is unauthenticated. Review the default owner, contacts without the intended owner and any reassignment plan with the business process owner. Do not bulk-reassign customers just to hide an authentication problem. Keap Ultimate automation requirements.

Create a small test matrix: one row per fixed sender, dynamic owner and distinct domain. Record which automation should fire and which mailbox should receive it. This catches identity differences that a single domain-level green check cannot reveal.

Verify DNS and received mail

Replace every placeholder below with the real generated owner or the identities found in a message:

dig CNAME GENERATED_OWNER.example.com +short
dig CNAME DKIM_SELECTOR._domainkey.example.com +short
dig TXT DKIM_SELECTOR._domainkey.SIGNING_DOMAIN +short
dig TXT ACTUAL_MAIL_FROM_DOMAIN +short
dig TXT _dmarc.ACTUAL_FROM_DOMAIN +short

Check every generated record, follow aliases to the final public DKIM key, and compare targets character-for-character. If short output is empty, inspect the full response: NXDOMAIN, SERVFAIL and timeout have different causes. Compare authoritative DNS with an independent recursive resolver and the recorded TTL.

After Connected, send representative messages through the actual Keap workflow to a directly receiving mailbox. Inspect its trusted receiver-added Authentication-Results, recording the From domain, smtp.mailfrom, DKIM signing header.d, selector s= and results. Require an aligned DKIM pass and dmarc=pass; record SPF separately and investigate genuine errors. Do not trust a header copied in by the sender. Authentication-Results and DKIM.

Use receiver-controlled diagnostic output, or have the receiving administrator establish which fields were generated inside its known processing boundary and document how externally supplied Authentication-Results are removed or distinguished. A familiar authserv-id string or header position alone does not establish provenance. Ignore attacker-inserted or otherwise untrusted results, including a forged field naming the expected receiver. Operational receiving-boundary requirements.

Diagnose SPF at the actual smtp.mailfrom independently, even when aligned DKIM supplies DMARC pass. fail or softfail calls for checking whether the connecting sender is authorized for that envelope route; temperror indicates transient evaluation trouble such as a DNS timeout; permerror calls for checking malformed syntax, duplicate policies and the evaluated DNS-term budget. A passing but unaligned SPF identity is a separate condition. SPF result meanings.

Save the date, account, automation, sender profile and redacted evidence. Repeat for dynamic owners in the test matrix. A real-message pass proves that sampled route at that time, not every future template or guaranteed inbox placement.

Troubleshoot by failure stage

The domain stays Pending: Check exact values, suffixes and authoritative DNS first. Keap documents a 24–48-hour visibility window and an edit/recheck path for previously authenticated domains. Do not regenerate DNS repeatedly while an existing valid change is propagating.

The wizard reports a collision: Preserve the existing owner and generate a supported alternate prefix. Update the entire corresponding set coherently.

Connected, but an automation sends nothing: Inspect Contact Owner and profile-domain status before changing DKIM. Confirm the workflow actually reached its sending step.

SPF passes, DMARC fails: Inspect alignment, not just the SPF verdict. Look for the expected custom-domain DKIM signature and the selected From address.

DKIM passes, but the domain is unexpected: A valid provider signature is not automatically your aligned brand signature. Compare header.d with the actual From and published alignment mode.