KickoffLabs SPF, DKIM and DMARC setup, step by step

KickoffLabs currently documents a support-assisted sender-domain setup. Open Account → Email settings → Sender domains → Start sender-domain setup and request the records and provider steps for your account. Publish the approved packet at the authoritative DNS host, wait for verification, then configure the campaign’s sender and compliance details and test a native campaign message.

There is no universal KickoffLabs SPF include, DKIM selector or public key established by these instructions. The campaign controls documented today are From name and Reply-to email, not a self-service From-address field. Coordinate the actual branded sending identity with KickoffLabs and verify it in the received message. Current sender-domain instructions.

This guide covers current native KickoffLabs campaign email. It does not configure a landing-page domain, external CRM, standalone SendGrid account, Amazon SES account or custom SMTP connection. Existing direct-provider configurations require a separate support-coordinated decision, not an automatic migration.

1. Confirm the route and collect the information you need

Before changing anything, identify the campaign, the domain you control and the exact From address the business wants recipients to see. Confirm who owns the reply mailbox and who can approve campaign sending and DNS changes. The public instructions do not establish a universal plan entitlement or named administrator role for sender-domain setup. If the controls are missing, ask the account owner and KickoffLabs to establish availability rather than buying an upgrade or changing roles speculatively.

Prepare:

• The campaign URL and intended sending domain.
• The desired visible From address and a monitored, authorized Reply-To mailbox.
• The authoritative DNS host for the domain or subdomain, which may differ from its registrar or landing-page host.
• An inventory of existing SPF, DKIM, DMARC and relevant routing records, including delegated subdomains and _domainkey namespaces.
• A safe test recipient and an approved way to test without enrolling real leads or activating live campaign messages.

Record the current campaign sender/compliance settings and DNS values before editing. Keep that record private, without credentials or unnecessary lead data. A landing page working on a custom domain does not mean email authentication has been configured for it.

Keep the identities separate

A provider-owned fallback From can have passing authentication without satisfying your intended branded-From requirement. Treat that as a different outcome. Raw DKIM results versus aligned DKIM results explains why a valid signature alone is not enough.

2. Start the supported sender-domain request

1. Open the account menu, then Email settings → Sender domains.
2. Select Start sender-domain setup. The documented action opens a support request, not a completed DNS wizard.
3. Provide the approved sending domain and campaign URL. Request the exact DNS records and any account-specific provider steps.
4. Agree how verification and the move to the branded domain will be confirmed before sending.

KickoffLabs explicitly says its team coordinates DNS, deliverability verification and provider setup before mail moves to a branded domain. Its custom-domain verification page retains a SendGrid-related URL, but the current body describes this support-assisted flow, not the archived SendGrid screenshots.

Ask for a complete packet containing the record type, full owner name, exact public value or target and any priority or TTL requirement. Also establish the intended From domain, DKIM signing identity, envelope behavior, applicable campaigns and any separate activation steps. These are details to obtain for your account, not values this guide can safely derive.

Only public DKIM records belong in DNS. Do not request or email private signing keys, API keys or passwords. If a provider step requires credentials, the authorized operator should use the approved secure account flow, not paste them into a support email or public checking tool.

Already using SendGrid or another custom provider? Preserve the existing configuration while Support confirms whether it should remain or migrate. Current documentation warns that the old Setup → Messaging → Custom Email Provider form and its SMTP, SendGrid or SES credential instructions are not the current dashboard flow. Do not disconnect a working integration to follow old screenshots.

3. Publish only the approved account records

Use the DNS service that is authoritative for each supplied owner. A registrar’s editor has no effect if that zone is hosted elsewhere. Confirm whether the domain, a child zone or its _domainkey namespace is delegated before deciding where to publish.

Do not add a record merely because its shape looks familiar. The packet determines whether the account uses TXT, CNAME or another supported arrangement. A borrowed SendGrid selector or a KickoffLabs-looking include is not a substitute for issuance.

Map full owners to the correct zone

The following names demonstrate DNS-editor input only. SELECTOR is a placeholder, not a KickoffLabs-issued selector. Replace every example with the full owner supplied for your account.

An editor that accepts full names may need the entire owner instead. Check its convention so the zone suffix is not appended twice. Preserve existing NS delegations and selectors; do not delete a delegation to make a TXT record fit.

For an issued DKIM TXT record, copy the complete tagged public value, including its full p= key. Never shorten it to match a screenshot. Follow the DNS host’s rules for long TXT values: multiple quoted strings within one TXT record can represent one logical value, but separate TXT records are not a substitute for splitting that value correctly. Keep private keys out of DNS.

If the packet authorizes SPF

SPF evaluates the SMTP MAIL FROM domain, not the display name or Reply-To. Ask Support which owner its instructions apply to. Do not add an apex include simply because the campaign replies to an address there.

At the evaluated owner, keep one v=spf1 TXT policy and preserve the legitimate senders and qualifiers already in it. If an additional mechanism is actually required, have the DNS/mail administrator merge it into that policy rather than adding a second SPF record or replacing everything. A parent SPF policy does not automatically apply to a child envelope domain.

The limit is ten evaluated DNS-dependent terms, including nested mechanisms and modifiers, not ten includes. An all mechanism makes redirect ineffective. Preserve the intended policy rather than casually changing -all, ~all or ?all; none guarantees a particular receiving system’s delivery decision. If Support says SPF is managed on a provider-controlled envelope domain, do not create an unrelated customer-domain policy. SPF specification.

If the packet contains CNAMEs

A CNAME owner cannot also host TXT, A, AAAA, MX or a different CNAME. Stop on conflicts, including a delegated owner, and coordinate a supported alternative. Do not erase another service’s record or delegation.

Email-authentication aliases should be DNS-only rather than HTTP-proxied. If verification requires the literal CNAME answer, its public response must retain that alias. In Cloudflare, turn the record’s Flatten control off where available and ensure applicable zone-wide settings do not flatten the issued alias. Coordinate any shared-setting change; do not globally disable a feature without reviewing other records.

Cloudflare also documents automatic apex flattening and same-zone-target behavior that ignores the usual setting. If those conditions prevent the required answer, stop and obtain a supported configuration rather than inventing a switch or changing nameservers. Other DNS hosts have their own behavior. Cloudflare proxy status and CNAME flattening setup explain the named controls.

Stop before unapproved routing changes

A packet that includes A, MX, NS delegation or forwarding has consequences beyond copying text. Compare the exact destination, priority and affected scope with the owner-approved routing plan. Do not move inbound mail, delegate a shared namespace, change parent nameservers or disable DNSSEC merely to pass a sender check. Resolve unexpected routing or security requirements with the responsible administrator and Support first.

4. Preserve DMARC while checking the intended From domain

Keep existing direct and applicable inherited DMARC protection and authorized reporting destinations. Do not publish a child p=none policy to bypass an inherited enforcement policy, duplicate a record, loosen strict alignment or introduce obsolete pct settings to make a test pass.

If there is no direct or applicable inherited policy, the owner approves the change and a suitable monitoring plan exists, an initial TXT policy can be:

v=DMARC1; p=none

This is a conditional first-policy example, not a KickoffLabs-issued record, a replacement policy or a promise of delivery. It does not request aggregate reports by itself.

Use your actual domain and confirm the DNS editor’s suffix behavior. A policy inherited from a parent can already apply even when the direct owner has no TXT record. Account-specific requirements for a direct record need coordination that preserves the effective protection, including a different inherited sp policy, rather than a blind copy of the parent’s p value. Current DMARC specification.

If you add rua, use only an approved real reporting destination. For a report destination in a different Organizational Domain from the domain where the policy was found, the report-generating receiver must check DNS authorization; destinations within the same Organizational Domain are excepted. Compare those domains, not merely different hostnames or the visible From subdomain. This protocol check does not replace the owner’s approval to share report data. RFC 9990, section 4.

5. Complete provider verification and campaign compliance

After publication, compare the authoritative DNS answers with the exact packet and check a public recursive resolver. For a CNAME, inspect the alias itself as well as resolution of its target. For TXT, compare the complete logical value. A DNS checker finding a key does not prove that KickoffLabs is using the matching private key or signing your campaign.

Keep the support request open until the team confirms the account-specific verification and provider setup required for the branded route. The public instructions do not establish a universal green status, activation button or propagation SLA. Do not invent one or treat an elapsed waiting period as approval to send.

Once verified, open the campaign’s Emails → Sender & compliance and save:

• The approved From name.
• The authorized Reply-to email on a domain you control.
• The legitimate postal address.
• The required unsubscribe footer.

The current documentation says sending stays off until the postal address is saved. That compliance gate is not a DNS or DKIM pass. Do not bypass it with a fake address or remove unsubscribe information. Confirm the actual branded From address with Support: the documented campaign controls do not establish a separate editable From-address field. Current sender and compliance guidance.

Check the reply mailbox exists, is monitored and is authorized to receive lead correspondence. A change to a shared campaign mailbox can expose replies or move operational responsibility, so obtain approval for the destination and affected scope.

6. Test the native campaign route and inspect trusted results

KickoffLabs instructs you to send a test from a campaign message and inspect its From address, links and delivery. Use that native path, not a standalone SendGrid test, a preview alone or an email sent from your mailbox.

Use an approved controlled address and harmless synthetic content. Confirm the test’s actual recipient list and that it will not enroll real leads, trigger reward/referral activity or activate ongoing campaign messages. If reaching the intended route requires turning on a message, coordinate an isolated authorized test; do not enable a live campaign merely to obtain headers. A test mode may differ from final automation, so record which path was checked and keep any untested intended route pending.

At the receiving service, obtain the original message and results generated inside its known processing boundary. Check its documented treatment of externally supplied Authentication-Results or ask the mail administrator for a trace. A familiar authserv-id or header position alone is not trustworthy; ignore attacker-supplied external results. Authentication-Results security considerations.

For branded DKIM acceptance, confirm all of the following:

1. The actual visible From is the intended approved branded address, not a provider-domain rewrite.
2. The intended provider signature is present; record its actual d= and s= and a trusted dkim=pass.
3. That passing signature aligns with the visible From under the applicable adkim mode, and the trusted receiver reports dmarc=pass.
4. The actual MAIL FROM and SPF result are understood. A separate SPF failure or error remains actionable even when DKIM supplies the DMARC pass.
5. Reply-To, campaign links and compliance information are correct, with no unintended recipients or route changes.

Relaxed alignment compares Organizational Domains; strict alignment requires exact domain equality. A child envelope domain can align with its parent under relaxed SPF alignment but not necessarily under strict aspf. Do not promise strict alignment from an unknown envelope identity.

DMARC can pass through aligned SPF or aligned DKIM. A pass through SPF alone does not prove the intended DKIM configuration works, and an unrelated passing signature is not a substitute. Save redacted evidence for this particular route without claiming every campaign or receiving provider was tested. Authentication success does not guarantee inbox placement or message safety.

Troubleshooting and safe rollback

Pause the affected message or coordinate a safe sending pause before a corrective change. Do not delete a newly published key while mail still uses it, or remove an older selector, SPF authorization or shared delegation until the replacement route has been accepted and dependent senders are accounted for. Restore a previous sender configuration only with the owner’s and Support’s agreement, then repeat the same-route checks.

For Support, provide the approved campaign URL, the step attempted, time, exact non-secret DNS owner/type and redacted result. Do not upload lead exports, full private messages, API keys or passwords. An unresolved issue should remain a setup hold, not an excuse to weaken DMARC or switch providers silently.