Kartra SPF, DKIM and DMARC setup, step by step

KartraMail handles SPF for its own sending infrastructure. You do not add a customer SPF include specifically for KartraMail. Authenticate each custom From domain with Kartra’s account-issued DKIM records instead. For manual setup, the current workflow supplies three CNAMEs and requires you to finish the setup in Kartra, not merely publish DNS. Kartra’s authentication explanation

This guide covers the native KartraMail delivery service. A connected Mailgun, SendGrid, Postmark or Elastic Email gateway uses that service’s authentication, not this DNS procedure. Website-domain connection is also a different task. First establish which gateway will actually deliver the message.

The acceptance target is a newly delivered message with your intended From address, a passing and aligned KartraMail DKIM signature, and a trusted receiver’s dmarc=pass. A green account status or a design-preview email is not that evidence.

1. Establish the sending route and change boundary

Kartra distinguishes one-time Emails, automated Sequence emails and event-driven Email Notifications. Identify the paths your organization actually uses. Authenticating a domain does not prove every existing message or automation selects the same sender and gateway. Choose how to send emails in Kartra

Before changing anything, record:

• The exact intended From address and domain, including any child domain.
• The delivery gateway selected for the message or automation, and the account default used by notifications.
• Who is authorized to change Kartra settings and who controls the authoritative DNS zone.
• Existing DNS records at the proposed owners, including CNAMEs, TXT records and NS delegations.
• Current direct and applicable inherited DMARC policy, alignment modes and authorized report recipients.
• An approved, isolated test route and valid recipients under your control.

Do not change gateways, nameservers, MX records or existing mailbox routing simply to follow this guide. A domain registrar and its authoritative DNS provider can be different organizations. Publish where the relevant zone is actually served, not automatically wherever the domain was purchased.

The cited instructions do not establish a named role or plan permission matrix. Use an authorized operator who can access the documented settings. If the controls are absent, establish account entitlement and permissions with the administrator or Kartra Support instead of assuming an upgrade or substituting another product.

2. Get and publish the actual DKIM packet

Current Kartra procedure

1. Open Settings > Domains > DKIM and check whether the intended domain is already authenticated. Domains bought through Kartra may already be configured.
2. For a new setup, choose + DKIM > Add DKIM record, enter the sender’s domain, and select Manual.
3. Copy all three CNAME rows, preserving each Host and Points to value. Do not use a tutorial’s sample selector or target.
4. Add those rows at the authoritative DNS provider. Use its default/automatic TTL unless your DNS change plan says otherwise.
5. Return to the DKIM details window, select the confirmation checkbox and click Finish.
6. Check the domain status: Pending validation must progress to Connected.

For supported domain providers, the same start offers Automatic, followed by Finish. That path lets Kartra create records and start validation; an unavailable option is grayed out. Review any requested DNS access and the intended changes before authorizing it. Do not grant unexpected permissions merely to avoid manual entry. Current KartraMail DKIM instructions

Translate DNS fields without changing identities

Each packet row is a separate owner-to-target mapping. A CNAME’s target is a hostname, not a URL, an IP address, or a public-key TXT value. Keep the three rows distinct. Do not generate a private key or paste one into DNS: this workflow delegates the public lookup to the provider’s issued targets.

A DNS interface may append the selected zone automatically. Its saved full owner must equal the issued full owner exactly, with no duplicated domain suffix. The following are naming illustrations, not Kartra record values:

Apply the _domainkey examples only to a packet owner that actually contains that namespace. Do not rename an arbitrary issued Host into a guessed DKIM selector. An editor accepting full names instead needs the full issued owner. Inspect the saved result rather than trusting the appearance of the input box.

Existing delegated namespaces are real authority boundaries. If an NS delegation already assigns _domainkey or a child zone elsewhere, have the owner of that authoritative zone publish the appropriate record. Do not delete a delegation or duplicate its records in the parent zone as a shortcut.

Keep required CNAME answers visible

A CNAME owner cannot also hold conflicting TXT, A, AAAA, MX or a different CNAME. If an issued owner is occupied, stop and resolve the dependency with the DNS owner and Kartra; do not overwrite another service.

For Cloudflare-hosted DNS, set these mail-authentication aliases to DNS only, not the HTTP proxy. Where a per-record Flatten setting is available, turn it off for the issued aliases. Ensure applicable zone-wide settings do not flatten away their required CNAME answers. Coordinate a shared-setting change with the zone owner rather than blindly disabling a global feature. Cloudflare can impose flattening at the apex or for same-zone targets; if that behavior prevents the required literal alias, stop and obtain a supported configuration. Do not invent a switch or move nameservers. Cloudflare proxy status and CNAME flattening controls

3. Leave unrelated SPF authorization intact

For this native route, there is no KartraMail-specific customer SPF record to invent, no shared outbound IP to copy, and no reason to replace the domain’s existing mailbox-provider SPF. Kartra documents infrastructure SPF as handled when DKIM is configured. That statement does not establish a universal branded Return-Path or guarantee aligned SPF. Kartra SPF responsibilities

SPF evaluates the SMTP envelope MAIL FROM domain, or the applicable HELO identity for a null reverse-path. It does not automatically evaluate the address visible in From. A delivered message’s Return-Path helps identify the envelope route, while the receiver’s authentication result identifies what it actually evaluated.

If a separate, legitimately used service requires an SPF change, follow its current instructions at the actual evaluated owner. Retain one v=spf1 TXT policy there, preserve existing authorized senders and qualifiers, and evaluate the complete policy before saving. The limit is ten evaluated DNS-dependent terms, including nested evaluations, not ten top-level includes. An all mechanism causes redirect to be ignored. These are protocol checks, not a reason to modify SPF during a KartraMail-only setup. SPF specification

Do not interpret a neutral or softfail result as a pass, and do not assume a qualifier dictates the recipient’s final delivery decision. Investigate fail, temperror and permerror separately even when an aligned DKIM signature supplies the DMARC pass.

4. Confirm the intended sender in KartraMail

Open Settings > Integrations, locate KartraMail, choose Edit, and review the sender name, Send-from email and Reply-to email. Kartra’s instructions then call for testing the settings and saving the changes. Use business addresses on the same domain; free personal addresses are not accepted for this configuration. KartraMail is not an inbox, so the Reply-to address needs a real, accessible mailbox.

A temporary @kartra.com placeholder may exist on a new account. It is not your authenticated brand and does not receive replies. Replace it with the approved business identity for regular sending.

KartraMail remains the default unless another configured gateway is chosen. Many individual messages can select a different gateway; account-wide Email Notifications use the current default. Do not change that default casually, since it affects other mail. Additional senders must use authenticated domains. KartraMail settings and gateway behavior

Treat the settings test as a configuration check, not proof of final-route DKIM. Confirm the intended From and gateway again in the particular message or workflow used for acceptance. Check reply delivery separately with approved, non-sensitive test content; successful replies establish a working inbox, not authentication alignment.

5. Preserve DMARC before considering a first policy

DMARC compares authenticated identities with the visible From domain. DKIM uses the signing domain, d=, rather than the CNAME target’s hostname. SPF uses the envelope domain. Under relaxed alignment, the corresponding Organizational Domains must match; strict alignment requires an exact domain match. Thus mail.example.com and example.com can align under relaxed policy but not strict policy. Do not weaken adkim or aspf to make a sample pass. Current DMARC specification

Discover the policy applicable to the actual From domain, including inherited policy, before publishing anything. Preserve existing enforcement and authorized reporting destinations. An absent record at the exact child owner is not sufficient evidence that no policy applies.

Only when no direct or applicable inherited policy exists, the domain owner approves it, and there is an appropriate monitoring plan, a first monitoring policy can be a TXT record with this value:

v=DMARC1; p=none

This illustrative policy does not request reports by itself. It is not a Kartra account-issued record and must not replace or duplicate an existing policy.

Use full owners where the DNS editor requires them. Resolve a CNAME or delegation conflict with its owner rather than adding an incompatible TXT record.

If the approved reporting plan adds rua, use the organization’s actual authorized recipient, not one copied from an example. A report destination in a different Organizational Domain from the domain where the policy was discovered requires the report-generating receiver to check DNS authorization. A destination within the same Organizational Domain is excepted; merely using a different hostname does not make it external. RFC 9990, section 4 Protocol authorization does not replace the owner’s approval to share report data or the organization’s privacy controls.

6. Verify DNS, account status and an actual native message

DNS checks

Query each issued full owner at its authoritative server and a public recursive resolver. These are read-only command templates; replace every uppercase placeholder with the actual packet or authoritative server value:

dig @AUTHORITATIVE_NS ISSUED_FULL_OWNER CNAME +noall +answer
dig ISSUED_FULL_OWNER CNAME +noall +answer
dig ISSUED_TARGET TXT +noall +answer

Repeat for each of the three rows. Confirm the correct owner and complete alias target. Follow any legitimate target chain to its eventual record; do not assume every first target returns TXT directly. For the selector actually used by a message, the lookup at s._domainkey.d must ultimately resolve the public key needed for verification. A public lookup cannot prove that the sending service used the matching private key or signed the message. DKIM specification

If caches disagree, compare authoritative answers and relevant TTLs rather than repeatedly deleting and recreating records. In Kartra, separately confirm Connected for the correct domain. Neither DNS success nor Connected alone completes acceptance.

Do not use the editor preview as the authentication test

Kartra’s Send test email is a preview that does not use the final message’s gateway. It is suitable for content and appearance, not for proving this KartraMail route.

For a controlled native one-time Email, Kartra documents creating a small test list under Contacts > Lists, adding test contacts, choosing that list in the Email settings and sending through the normal process. Sequence and Notification behavior require their respective actual paths, not just a preview. Kartra’s preview-versus-live testing distinction

Obtain approval for that real send. Use only a minimal set of valid, consented test recipients under your control and non-sensitive content. Isolate the list from customer audiences, production automations and event side effects. Do not trigger a purchase, paid booking, real membership change or customer notification merely to get a header sample. Where a safe equivalent route cannot be isolated, leave that path unverified and arrange an approved test with its owner.

Read the receiving service’s evidence

Obtain the complete received message and the receiving service’s own authentication diagnostics. Identify results generated inside that service’s known processing boundary, including its documented handling of externally supplied Authentication-Results. A familiar authserv-id, a header’s position, or an attacker-supplied dmarc=pass is not proof. Ignore untrusted injected results; ask the receiving-mail administrator for the authoritative evaluation when the boundary is unclear. Authentication-Results trust model

Record all of the following for each actually used path:

1. The visible From is the intended business address, not a rewritten provider or placeholder address.
2. The message went through KartraMail, rather than a preview or a different configured gateway.
3. The intended KartraMail DKIM signature passes; record its actual d= and s=.
4. That signing domain aligns with the visible From under the existing adkim setting.
5. The trusted receiver reports dmarc=pass for that From domain.
6. The actual SPF identity and result are recorded and any failure, temporary DNS problem or permanent policy error is diagnosed independently.

A DMARC pass supplied only by SPF does not prove that the newly configured DKIM route works. Likewise, a passing unaligned signature does not authenticate your From domain for DMARC. EmailAuth’s explanation of raw DKIM results versus aligned policy results helps separate those conclusions.

Keep the sanitized evidence, configuration date and tested route with the change record. One successful sample is not proof for every sender, recipient or automation, nor a guarantee of inbox placement.

7. Troubleshoot the failed layer

Kartra’s DKIM troubleshooting checks record equality, the correct domain and accidental suffix duplication, and recommends contacting the DNS provider when publication needs help. Persistent signing or route problems after correct DNS require Kartra-specific investigation. Current validation guidance

8. Roll back without breaking other mail

If acceptance fails, pause the affected unsent campaign or automated path through its normal owner-approved controls. Preserve prior settings and DNS exports before a change so the authorized operator can restore a known-good configuration.

Do not delete all three CNAMEs as the first troubleshooting step. They may still be required by active mail, queued messages or another configured sender. Confirm dependencies and an approved retirement or replacement sequence with Kartra before removing a domain or record. Restore only the exact settings this change altered, and retest the intended path after recovery.

Keep the existing DMARC policy and unrelated SPF, MX, nameservers and delegations. Do not silently switch to an external gateway or a provider-domain From address and call that recovery of branded authentication. If a different route is approved as a temporary fallback, label its changed identity and separately verify its authentication.

Sources and verification limits

These are documentary dates, not evidence that a customer’s account was changed or tested. Current procedural prose establishes the controls; no customer UI screenshot or authenticated account was inspected.

This guide also uses the current DNS-host and protocol sources linked beside the relevant safeguards. No DNS record, account setting, gateway, recipient list or message was changed or tested during preparation. Complete customer-side acceptance remains a separate, authorized implementation task.