Source review dated 8 November 2026. Provider settings and acceptance exercises below are documentary guidance, not executed account, DNS or message tests.
Establish which Kayako email route you use
This guide covers the hosted Kayako email-channel workflow documented in Kayako Support. Do not apply its records automatically to Kayako Classic or another installation. Record the tenant, brand, support address, domain owner and current sending route before editing anything. A support address affects both the customer conversation and the system that delivers it, so the support lead and mail administrator should approve the same change record.
External support addresses require incoming forwarding into Kayako before the address is added as a channel. Preserve that forwarding while working on outbound authentication. Receiving a customer's ticket successfully does not establish that the reply will authenticate. Kayako external-address setup.
Inventory every support address agents can select, including addresses attached to less frequently used brands. Capture the existing SPF policy, DKIM owners and DMARC policy from authoritative DNS. Note scheduled automations and a rollback owner. Restrict the first change to one understood route rather than altering all brands and domain policy together.
Check DNS ownership before enabling signing
Kayako's documented custom-domain setup uses three CNAME owners: email, s1._domainkey and s2._domainkey beneath the customer's domain. Their respective targets are email.kayako.com, s1._domainkey.kayako.com and s2._domainkey.kayako.com. Confirm that this remains the supported setup for the tenant before publishing. If an owner already belongs to another service, Kayako directs customers to support for manual sender authentication through its SendGrid account. Do not overwrite the competing integration. Kayako authentication instructions.
Create a DNS change worksheet with full owner, record type, target, existing value and responsible service. A DNS editor may append the zone to a relative name. Check the final published owner, not merely the label typed into the editor. Keep an existing working selector until its dependent messages and services are understood. If the provider supplies a tenant-specific alternative, retain that instruction with the change approval.
Once DNS is visible, an administrator with Manage channels permission enables the DKIM option in Email > Settings and saves. The settings also control whether agent names appear in replies; changing that display name does not change the selected sending address. Kayako channel settings.
Keep SPF authorization separate from alignment
Kayako documents include:email1.kayako.com for SPF. Reconcile approved authorization into the applicable existing SPF record rather than adding a second policy or copying a whole example over other senders. Kayako SPF setup.
SPF evaluates the envelope identity used in the SMTP transaction. An include on your visible From domain cannot by itself change a provider-owned Return-Path. The retrieved Kayako instructions do not establish a configurable custom envelope domain; inspect a message and seek tenant-specific confirmation before promising that feature. Check SPF lookup cost, retained senders and the terminal policy when reviewing the complete record. SPF specification.
DKIM supplies a signing domain in d= and a selector in s=. A receiver can accept DMARC through an aligned passing DKIM signature even when SPF uses a different domain. Record authentication success and domain alignment as separate observations, using the domain's actual alignment mode. DKIM and DMARC.
Complete the original support-reply evidence table
The following acceptance design is original guidance, not an executed test. Use a harmless new conversation from a controlled external mailbox, reply as an agent using the intended address, and trigger any materially different automated notification. Create one received-message identity-table row per route and From domain. Include tenant, brand, workflow, timestamp, visible From, Return-Path, receiver SPF identity and result, every DKIM d=/s= pair and result, DMARC result, and evidence location.
Keep the original message source in a restricted location. Use authentication results added by the receiving system rather than treating any copied header as trustworthy. Add a separate business-check column for incoming ticket creation, reply delivery and the address used when the customer replies again. A passing authentication row should not conceal a broken support conversation.
Accept only the routes actually demonstrated by evidence. On a failed row, compare the observed selector with DNS, check that signing was enabled after publication, and inspect domain alignment before changing policy. Pause the affected rollout and restore only its approved changes. Do not weaken shared DMARC enforcement as a shortcut.
No Kayako tenant, live DNS record or received message was tested here. Current tenant applicability, the completed original identity table and human mail-security review remain open before production approval.