Source review dated 8 November 2026. This is documentary guidance; account, DNS and received-message acceptance tests below have not been executed.
Establish the product and approved exercise
KnowBe4 authentication settings differ between Security Awareness Training workflows and PhishER notifications. Within the training platform, phishing simulations and training notifications also have separate controls. Record the tenant, region, product, workflow, approved From address and owner before changing anything. Training messages contain a provider DKIM signature by default; phishing messages require DKIM to be enabled. KnowBe4 DKIM setup.
For a simulation, define the authorized audience, test window and sender identity. Authentication configuration is not permission to impersonate an unrelated organization or broaden an exercise. Keep a record of current settings and coordinate with the mail-security team. Delivery exemptions and authentication answer different questions, so do not add blanket allowlisting rules to make a failed authentication test appear successful.
Configure customer-domain DKIM for the correct workflow
In Account Settings > Phishing Settings, enable the DKIM signature option and choose the own-signing-domain control when customer-domain signing is required. Select an allowed domain, generate its selector, publish the displayed hostname and TXT value, validate the DNS record and save the settings. Training custom DKIM is configured separately under Training Settings. Phishing and training DKIM instructions.
An allowed-domain verification TXT record establishes domain ownership for the account. It does not replace the DKIM public-key record. Retrieve both from the current tenant where needed and label them by purpose in the change worksheet. Keep full owner names and values distinct, check automatic DNS suffix handling and preserve any previous selector during a planned transition. Domain verification TXT records.
For PhishER, use its own Settings > Email Server controls. The documented process enables DKIM, adds a custom signing domain, supplies a TXT record for publication and validation, and saves the selected domains. The PhishER toggle initially displays the signing domains and selectors configured in KSAT Account Settings, but enabling, saving and testing the PhishER route remain separate steps. Do not assume a successful training-console change covers PhishER notifications. PhishER DKIM instructions.
Decide whether the envelope identity also changes
KnowBe4's SPF instructions name include:_spf.psm.knowbe4.com and require enabling Overwrite Fixed Return-path Address with Sender Address before following that setup. Its separate Return-Path guide documents controls for phishing and training messages. Scope that choice to an approved sender domain and verify the effect in a received message. KnowBe4 SPF instructions and Return-Path settings.
Merge an authorized mechanism into the existing SPF policy rather than creating a second SPF record. Inventory other legitimate senders and calculate recursive DNS-lookup cost before changing the record. Do not copy example regional IP addresses into a permanent policy without confirming their current applicability and maintenance owner. A static address list creates a dependency that must be reviewed when the provider changes infrastructure.
SPF success is evaluated for the actual envelope domain. Customer-domain DKIM can provide an aligned path when its signature passes and its d= domain has the required relationship to From. DMARC needs an aligned passing SPF or DKIM path; a successful provider-domain signature need not align with the organization's address. SPF, DKIM and DMARC.
Test authentication without hiding the result
Original acceptance worksheet, not an executed test: send a harmless message to controlled recipients through every workflow in scope. Create separate rows for a training notification, authorized simulation and PhishER notification when each is used. Record the tenant, region, template, send time, original message identifier and any special delivery route. Preserve the original message source rather than only a screenshot saying delivered.
The received-message identity table must contain the actual From domain, Return-Path, receiver SPF identity and result, all DKIM d= and s= values, and the receiving system's DMARC result. Document any connector, injection mechanism or security exception that changes how the receiver treats the message. Delivery through an exception does not prove normal internet authentication. Keep the security team's delivery assessment alongside, rather than inside, the authentication acceptance decision.
Check that each expected customer-domain signature is present and passes, that the intended aligned path exists, and that no unrelated training template changed identity. If a failure appears, compare the generated selector, published TXT answer, selected domain and saved workflow settings. Stop the affected rollout and restore its documented settings if needed. Do not weaken the organization's DMARC policy or disable security checks as a general recovery step.
No live KnowBe4 tenant, DNS record, simulation, training message or PhishER notification was tested here. The original evidence gate remains open: current tenant instructions, authoritative records and an original received-message identity table for the exact product and delivery route are required. Independent technical and human SME review must precede publication or production approval.