KnowBe4 SPF, DKIM and DMARC setup, step by step

For KnowBe4 Security Awareness Training (KSAT), configure custom DKIM separately for training notifications and any approved SMTP phishing-test route that needs your own signing domain. Publish the TXT record generated in your account, validate it, and save the corresponding settings. For SPF, first establish which domain KnowBe4 actually uses in the envelope sender. The documented authorization is include:_spf.psm.knowbe4.com, but adding it to your domain does not change the message's return path. KnowBe4 DKIM instructions and SPF instructions.

Choose the KSAT route before changing DNS

The procedure below concerns KSAT email delivered over SMTP. Keep these cases separate:

• Training notifications: KnowBe4 already signs them using a provider identity. Custom DKIM is the relevant feature when you want a signature aligned with your organization's visible From domain.
• Approved phishing-test SMTP messages: DKIM must be enabled for this category. A custom signing domain is an additional choice, not an automatic consequence of enabling signing.
• Microsoft Defender Advanced Delivery: the current KnowBe4 instructions explicitly select Use KnowBe4's Signing Domain for phishing messages. Do not replace that with a custom domain merely to satisfy a branded-authentication checklist. Have the security owner reconcile any proposed change with the established simulation-delivery design. Advanced Delivery instructions.
• Direct Message Injection (DMI), smart hosting and filtering exceptions: these require their own delivery review. A message appearing in an allowlisted or injected mailbox does not demonstrate an ordinary external SMTP authentication path. KnowBe4's delivery-method guide distinguishes these methods.

PhishER notifications and KnowBe4 Gateway are separate products. Do not apply this KSAT click path to them. This article also does not authorize a phishing campaign, a filter bypass, a security-setting change or a test send. Implementation and any simulation require the organization's own approval and controlled recipients.

Prepare the domain, owners and existing records

Record the KSAT account and region, message category, visible From domain, intended signing domain, actual return-path domain and responsible security administrator. Ask the DNS administrator which service hosts the authoritative zone. A domain registrar, website host and DNS host can be three different organizations.

Save the current TXT, CNAME and relevant mail records before editing. Inventory employee mail and other applications sharing the domain. Decide who can authorize the DNS change, who can update KSAT, and who will inspect a received message. Do not remove another service's selector or change inbound MX routing to make an authentication warning disappear.

A custom signing domain must be available in the account's allowed-domain list. In Account Settings → Account Information → Organization Information → Allowed Domains, use + New Allowed Domain. Enter lowercase domain names. The subdomain option uses Submit; an additional root domain requires the account-issued verification TXT token and Verify Now, or Verify Later followed by verification when DNS is ready. The token is specific to the console and can be used for additional roots in that console. A pending root is not verified. Allowed-domain prerequisites and procedure.

Use only domains your organization controls. The allowed-domain feature is not permission to send simulations to public-domain users or outside organizations. Keep domain verification separate from DKIM: ownership verification does not prove that any delivered email carries your signature.

Generate and activate the correct DKIM TXT record

Open Account Settings and choose the branch that matches the message category:

1. For training, open Training Settings and enable Enable Custom DKIM Signature.
2. For an approved custom-signing phishing route, enable DKIM under Phishing Settings, then select Use Your Own Signing Domain. Do not use this branch for an Advanced Delivery design that requires KnowBe4's signing identity.
3. Select the allowed domain. Use Create a DKIM Selector for This Domain and copy the complete generated hostname and TXT value.
4. Have the DNS owner publish that exact TXT record. Use the selector-validation control in KSAT to check publication.
5. Confirm with OK in the selector-details window and Save Changes in account settings. Repeat only for the other category if its custom signing is also required.

The current custom DKIM procedure supplies the public record. It does not ask you to generate a private key on an unrelated website or upload one to a guessed KnowBe4 server.

For a long public key, a DNS host may split the TXT value into quoted character-strings. Those strings must remain within one TXT resource record, with the original value preserved when concatenated. Do not create multiple independent DKIM TXT records at the same selector. DKIM key-record rules.

Keep a worksheet containing the exact signing domain, selector, full owner name, TXT value, category and activation state. This makes it possible to distinguish “DNS exists” from “training is using this selector.”

Configure SPF for the actual return path

SPF normally authenticates the SMTP MAIL FROM domain, often visible in the received message's Return-Path. It does not directly authenticate the address displayed in the From field. A root-domain SPF edit will not repair a message whose SPF identity is a different domain. SPF identity rules.

KnowBe4 documents this mechanism:

include:_spf.psm.knowbe4.com

That is an authorization mechanism to incorporate into an approved policy, not a complete TXT record to publish by itself. Merge it into the existing SPF policy at the domain actually used for the envelope sender. Preserve legitimate authorizations, ordering and the existing final policy. Publish only one v=spf1 record at that owner, and evaluate nested DNS-querying terms against SPF's ten-term limit. If the policy is already over budget, do not add another record or delete another team's sender blindly. SPF setup and safe SPF consolidation.

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.

The official SPF procedure requires Overwrite Fixed Return-path Address with Sender Address for its customer-domain envelope route. The control is separate under the phishing and training email-header settings. The training settings documentation also requires the delivery allowlisting work to be in place before enabling it. Coordinate these prerequisites with the security owner; do not toggle the option globally as an unreviewed DNS fix. Return-path controls and training settings.

KnowBe4’s delivery-method guide separately tells Google Workspace users to disable the return-path header on phishing tests, whereas its customer-domain SPF procedure requires the overwrite control. Do not resolve these route-specific instructions by toggling a setting speculatively. Have the security owner and KnowBe4 confirm the supported combination for the actual SMTP or injection design before changing it. Current delivery-method guidance.

For a route intentionally using a provider-owned envelope, check that provider identity instead. Your own SPF record does not control its evaluation. Review account-region guidance rather than copying a static US IP list into every region.

Publish at the authoritative DNS owner and verify the answer

A selector such as SELECTOR._domainkey.example.com is illustrative. Replace it with the generated full owner. If your DNS editor automatically appends example.com, the name field usually needs only SELECTOR._domainkey; a fully qualified-name field needs the whole name. Confirm the final public hostname so the domain is not appended twice.

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.

The generated key is a TXT record, not a website URL or a CNAME target. If a CNAME already occupies that owner, stop and resolve the conflict with its owner. Preserve unrelated TXT verification records. DNS aliases cannot ordinarily coexist with other data at the same owner. DNS alias requirements.

These read-only examples use placeholders. Replace the names before running them:

dig NS example.com +short
dig @ns1.example.net TXT SELECTOR._domainkey.example.com +noall +answer
dig TXT SELECTOR._domainkey.example.com +noall +answer
dig TXT ENVELOPE-DOMAIN.example.com +noall +answer
dig TXT _dmarc.example.com +noall +answer

Use a nameserver authoritative for the actual zone, including any delegated subdomain. Expect the selector TXT answer to match the account-generated public value. Confirm exactly one selected SPF policy at the actual envelope domain. Query another recursive resolver when diagnosing stale answers. A correct authoritative answer with an older recursive answer points toward caching; a wrong authoritative answer requires a configuration correction. Repeated SERVFAIL needs DNS investigation rather than another copied record.

The commands show publication, not cryptographic signature success or SPF evaluation for a particular sending IP. Keep those acceptance checks separate.

Preserve DMARC and distinguish passing from aligned

DMARC can pass through either aligned SPF or aligned DKIM. Relaxed alignment permits the applicable organizational-domain relationship; strict alignment requires the full domain names to match. A provider-owned DKIM signature can pass cryptographically and still fail to align with your organization's From domain. Current DMARC standard.

Look up the applicable DMARC policy, including inherited policy for a subdomain. Retain existing enforcement, adkim, aspf and reporting destinations. Do not downgrade to p=none or create a second DMARC record to accommodate onboarding. If no applicable policy exists, a monitored rollout may begin with p=none, an approved aggregate-report destination and an owner responsible for reviewing legitimate traffic before enforcement. External report destinations may require authorization by the receiving domain.

Only when no direct or applicable inherited policy exists and the domain owner approves first-time monitoring, publish one TXT policy with v=DMARC1; p=none at the intended From domain’s DMARC owner. For example.com, the full owner is _dmarc.example.com, entered as _dmarc in that zone. For news.example.com, use full owner _dmarc.news.example.com: _dmarc.news relative to the parent zone, or _dmarc in the separately delegated child zone. Do not create a child monitoring exception to an existing protective policy. The minimal value requests no reports; append ; rua=mailto:APPROVED_REPORT_ADDRESS only after replacing the placeholder with a provisioned, approved destination. DMARC policy publication.

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.

In EmailAuth or your chosen reporting platform, correlate KSAT observations with the configured route and message category. Separate raw SPF/DKIM outcomes from DMARC-aligned results, and do not label every failure as an attack. Reading aggregate reports.

Accept the configuration using received-message evidence

After implementation is approved, use an ordinary training notification to a controlled organizational mailbox for the training route. Any simulation test needs its own approved scope and recipients. Inspect the original source from the receiving system, rather than a forwarded copy or a screenshot of the inbox.

For a custom branded DKIM route, all of these checks matter:

1. The intended visible From domain appears on the message.
2. The intended custom signature is present: identify its d= signing domain and s= selector.
3. The trusted receiver reports dkim=pass for that intended signature, and its signing domain aligns with From under the actual policy. A different passing provider signature is insufficient.
4. Record the actual smtp.mailfrom, connecting IP and raw SPF result. Investigate fail, softfail, neutral, none, temperror and permerror; a DMARC pass through DKIM does not clear a broken SPF configuration.
5. Check SPF alignment separately, then require the trusted receiver's dmarc=pass for the intended visible From domain.
6. Retain the account category, timestamp and received headers, with personal content redacted where practical. Repeat after material routing or signing changes.

Use receiver-added authentication results within the receiver's trust boundary. A sender can insert a misleading header named Authentication-Results. Authentication-Results specification.

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.

For the Advanced Delivery provider-signing branch, document its intentional provider identity and security-policy acceptance separately. Do not call it “branded DKIM verified.” Likewise, an injected message or allowlist bypass is not proof of public SMTP authentication. Authentication success also does not guarantee inbox placement.

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.

Troubleshoot by symptom

• The signing domain is missing from the dropdown: confirm the correct console, lowercase allowed-domain entry and completed root-domain verification. Do not delete users or domains to work around the missing option.
• The TXT record exists but validation fails: compare the full owner and complete key, check for an auto-appended suffix, separate records created from key fragments, an old selector, and authoritative-versus-cached answers.
• Training passes but the phishing route does not: check the settings for the actual category and its chosen delivery method. One category's saved settings do not verify the other.
• SPF passes but DMARC fails: compare the SPF identity and DKIM d= with From. The authenticated domains may both belong to the provider. Use the custom MAIL FROM alignment guide to distinguish identity from alignment.
• DMARC passes but custom DKIM fails: an aligned SPF pass may be masking the defect. Keep the DKIM change open until the intended branded signature passes and aligns.
• Delivery works only through a bypass: retain that result as a delivery-policy observation. It does not settle the authentication checks above.

Documentation and verification limits

This guide is based on current official instructions and email-authentication standards. No KSAT settings, DNS records, mail-security controls or campaigns were changed, and no test email or simulation was sent. Account-specific values, current regional requirements and delivered-message results still require verification in the organization's approved implementation.