Kayako SPF, DKIM and DMARC setup, step by step

For hosted Kayako support email using your own domain, add include:email1.kayako.com to the existing SPF policy, publish Kayako's three documented CNAMEs, and wait for them to resolve before enabling Use DKIM to authenticate in Email > Settings. If any CNAME owner already serves another application, ask Kayako Support for manual sender authentication rather than replacing that record. Verify the result on a real support reply, not just in DNS. Kayako authentication instructions.

This guide covers the hosted Kayako email-channel workflow documented at help.kayako.com. It is not a Kayako Classic or self-hosted SMTP configuration guide.

Employee mail through Microsoft 365 is a separate sending route; retain its configuration and use the Microsoft 365 authentication guide for that service rather than treating these application records as its configuration.

Choose the correct Kayako address and route

Incoming forwarding and outgoing authentication are separate. For a custom address, configure forwarding at the mail host into your default Kayako address. Do not replace a working MX configuration with Kayako's DKIM records. The external-address guide specifically calls for server-side forwarding rather than a desktop email-client rule. External-domain setup.

Before enabling server-side forwarding, have the receiving-mail owner separately approve the exact destination Kayako address and which incoming aliases or messages will be forwarded. Compare the saved destination and affected scope with that plan; account instructions alone are not approval to disclose incoming support mail. Use a controlled incoming message to verify routing, without changing unrelated mailbox MX or forwarding.

An administrator with Manage channels permission can use Administration > Channels > Email > New Address, enter the address, select its brand and save. An external address receives a verification link that must be completed to activate the channel. Verify that the address can receive that email before troubleshooting outbound DKIM. Adding and verifying an email address.

Record each brand, enabled support address and notification type. Existing conversations normally reply through the channel in which they began, while the default address affects new conversations. Changing an agent's displayed name does not change the sending email address. Kayako channel behavior.

Prepare DNS without disrupting other senders

Before editing, collect the current SPF and DMARC policies, MX records and all records at email, s1._domainkey and s2._domainkey beneath the intended domain. Assign a DNS owner and save a rollback copy. A company may already use these common selector names for another email service.

Identify the authoritative zone, including any delegated child. A support sender such as agent@support.example.com uses the complete domain support.example.com, not automatically example.com. Account for that domain in every DNS owner.

Do not change nameservers, delete corporate mail records or create a second SPF policy to add Kayako. Keep the inbound forwarding and channel-verification process intact throughout the change.

Add the Kayako SPF include

Kayako documents include:email1.kayako.com for the hosted route. Merge it into the existing SPF TXT policy at the appropriate sending-domain owner, before its terminal all. Preserve other authorized senders and the approved ~all or -all policy. Official SPF procedure.

If the existing SPF policy uses redirect=, reconcile its authorizations and terminal behavior with the DNS owner before changing it. Any all mechanism makes redirect ignored regardless of their order. Do not append all automatically: preserve the redirected senders and approved policy semantics through a reviewed design. SPF all and redirect processing.

If no policy exists and Kayako is the only legitimate outbound service for this owner, this minimal illustration authorizes Kayako:

v=spf1 include:email1.kayako.com ~all

Kayako's own example also includes mx. Do not add mx or a literal mail-server IP just because an example contains it: include them only when those systems genuinely send for the evaluated identity. Likewise, do not replace a shared policy with the one-line illustration above.

The mx mechanism authorizes the applicable A/AAAA addresses of the resolved mail exchangers. Compare those addresses with your approved outbound-sender inventory before retaining or adding it; merely receiving mail does not establish permission to send. SPF mx processing.

SPF checks the SMTP MAIL FROM domain, often shown as Return-Path and trusted smtp.mailfrom, rather than the visible From address. A provider-owned envelope domain can pass SPF without aligning with your brand. The reviewed hosted Kayako pages do not document a self-service custom Return-Path control. Do not promise SPF alignment from adding this include alone. SPF identity and processing rules.

Keep one SPF policy per exact owner and evaluate its entire include chain within SPF's ten lookup-causing-term limit. SPF is not inherited from a parent domain: a policy at example.com does not automatically authorize support.example.com. Duplicate policies, malformed includes and excessive lookup terms can produce permerror. Other non-SPF TXT records can remain. SPF record selection, lookup limits.

Publish the three CNAMEs, then enable DKIM

For a custom sender domain represented here by example.com, Kayako's standard published configuration is:

example.com is a fictional placeholder; the Kayako targets are the documented service hostnames. Publish all three required aliases. The s1 and s2 owners are DKIM selector lookups; do not describe the email alias as a third DKIM selector or assume it proves a custom Return-Path. Use any alternative record set issued specifically by Kayako Support instead of mixing the standard and alternative configurations. Kayako CNAMEs and collision procedure.

Resolve selector conflicts before changing records

If email, s1._domainkey or s2._domainkey is already occupied, stop that record change. Kayako explicitly directs customers to request manual sender authentication through its SendGrid account. This does not mean you should create a separate SendGrid account or invent new selectors. Obtain the exact replacement owners and targets through the Kayako support process.

A CNAME owner cannot share its name with an ordinary TXT record, MX record or another conflicting CNAME. Do not overwrite a working selector or web hostname. Use DNS-only handling if the DNS host offers a web proxy, and enter each target as a hostname rather than a URL.

Where the issued authentication or return-path records require literal CNAME answers, use DNS-only aliases returning the exact targets, without an HTTP proxy or flattening hiding them. Turn the relevant per-record Flatten control off when available and ensure applicable zone settings preserve those aliases. Cloudflare documents that flatten-all cannot be overridden per record, apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are conditional DNS-host behaviors, not assumed controls in every panel. If mandatory apex/same-zone behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration with the DNS owner and sender. Do not blindly change the whole zone or remove an existing delegation. CNAME verification, flattening controls and limits.

Enter names correctly for child and delegated domains

For a sender at support.example.com, the corresponding standard owners are email.support.example.com, s1._domainkey.support.example.com and s2._domainkey.support.example.com. Confirm applicability with Kayako for the selected channel.

These are relative-name examples. If the editor expects a full name, supply the full owner. Check its preview for duplicated suffixes and publish in the authoritative delegated zone when applicable. The CNAME destinations remain the exact service-issued targets, not names with your zone appended.

If _domainkey.support.example.com is separately delegated, full s1._domainkey.support.example.com uses relative s1 there, and s2._domainkey.support.example.com uses s2. Preserve that NS delegation and publish with its operator; substitute any alternative Support-issued selectors. DNS zone boundaries.

Activate signing only after DNS resolves

Kayako recommends waiting 24 hours for the CNAME changes and warns that enabling DKIM too early can affect sending. Check actual public DNS visibility as well as elapsed time. Then open the administration area's Email > Settings, check Use DKIM to authenticate and save. An administrator needs Manage channels permission. For the default Kayako-domain address, the documentation says to use the checkbox without adding custom-domain DNS records. DKIM activation, settings permissions.

Keep DMARC aligned with the support address

DKIM uses the signing domain d= and selector s= in the delivered signature. DMARC requires a passing SPF identity or a passing DKIM signature aligned with the visible From domain. Relaxed alignment allows the applicable organizational-domain relationship; strict alignment requires the exact domain. A generic dkim=pass for an unrelated service domain does not authenticate support@example.com for DMARC. DKIM signature fields, DMARC specification.

Inspect the effective policy at the actual From domain and its applicable parent discovery. Preserve existing enforcement, reporting recipients and alignment settings. Never add a second DMARC record or lower an established policy just to accommodate an unauthenticated support route.

If no effective policy exists, a monitoring-first rollout approved by the domain owner may use this illustrative TXT value at _dmarc.example.com:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Replace the report address with an authorized monitored mailbox or the exact approved destination issued by your reporting service. Review aggregate data for Kayako and all other legitimate senders before considering enforcement, including forwarding and other indirect mail paths.

For a first policy at full owner _dmarc.example.com, a relative-name field in zone example.com takes _dmarc. For a deliberately approved child policy at _dmarc.support.example.com, use _dmarc.support in the parent zone or _dmarc in a separately delegated support.example.com zone. A full-name field takes the complete owner. These examples do not authorize overriding an inherited policy.

Compare the Organizational Domain of the aggregate-report URI's host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as the policy domain is excepted; a different hostname alone does not make it external. Obtain the reporting operator's exact authorization instructions when required. This protocol check is separate from the domain owner's approval to share report data; agree access, retention and privacy. RFC 9990 section 4.

Verify DNS and the complete support conversation

Replace the example domain and authoritative server below. For a child sender, query its complete owner rather than the parent domain:

dig +short NS example.com
dig @AUTHORITATIVE-NAMESERVER TXT example.com
dig @AUTHORITATIVE-NAMESERVER CNAME email.example.com
dig @AUTHORITATIVE-NAMESERVER CNAME s1._domainkey.example.com
dig @AUTHORITATIVE-NAMESERVER CNAME s2._domainkey.example.com
dig @1.1.1.1 TXT s1._domainkey.example.com
dig @1.1.1.1 TXT s2._domainkey.example.com
dig @1.1.1.1 TXT _dmarc.example.com

Expect the exact required aliases and, for both selectors, a reachable nonempty public DKIM key after following each CNAME. Query the destination TXT explicitly if the resolver does not display the final key. Compare authoritative DNS with a public resolver after cache expiry. Check response status before interpreting a blank result; timeouts and SERVFAIL need DNS investigation, not blind record replacement.

For an authorized acceptance test, open a harmless new conversation from a controlled external mailbox, confirm it reaches Kayako, then reply using the intended support address. Repeat for different brands and automated notifications that use other From domains. Verify that a customer's reply returns to the right conversation. Incoming success alone does not establish outbound authentication.

Use the receiving mailbox's original source and trusted Authentication-Results. Record:

Establish which results were generated inside the receiving service's known processing boundary and how it removes, ignores or distinguishes externally supplied Authentication-Results. Use receiver-controlled diagnostics or have the receiving-mail administrator confirm its documented handling. A familiar authserv-id string or header position alone is not proof. Ignore attacker-supplied or otherwise untrusted fields; obtain authenticated receiving-system evidence when provenance is uncertain. Receiver-result trust.

• The brand, channel, workflow, timestamp and visible From domain.
• The envelope identity, SPF result and whether that identity aligns under aspf.
• Every DKIM d= and s=, and which signature the receiver accepted.
• The DMARC result and evaluated From domain.

For this branded DKIM setup, require the intended Kayako signature to report dkim=pass and align with the unchanged approved branded From under the effective adkim policy, together with trusted receiver dmarc=pass for that From. Record the expected and observed d= and s=. A rewritten provider From, unrelated passing signature or SPF-only DMARC pass does not complete the intended DKIM deployment. DMARC itself permits either aligned passing method; this is the commissioned signer’s acceptance gate.

A direct-route SPF pass that is unaligned can be an expected limitation if aligned DKIM carries DMARC. An SPF failure or error is a separate issue: diagnose fail, softfail, neutral, none, temperror and permerror rather than treating them as equivalent to unaligned success. Repair a customer-owned policy; for provider-owned identities, send the relevant identity and receiver error to Kayako Support. Forwarding-induced SPF failure needs separate path evidence. Do not add Kayako repeatedly to the organizational SPF record to fix an identity it does not control.

Diagnose SPF at the actual envelope owner independently even when aligned DKIM supplies DMARC. For fail or softfail, compare the observed connecting source and MAIL FROM identity with the approved authorization and sending route. For permerror, check duplicate SPF policies, malformed syntax and the full nested DNS-dependent term budget. For temperror, investigate temporary DNS resolution or availability failures and retest after recovery. A provider-owned SPF pass without alignment is different from these failures; escalate errors for provider-owned identities to that sender rather than editing unrelated apex DNS. SPF result definitions.

Troubleshoot Kayako-specific failures

Kayako's bounce indicator exposes details when you hover over its X symbol. Invalid recipients, full mailboxes, recipient-server problems and filtering are different failures. Kayako directs users to support for a blocklisted Kayako sending IP. Authentication cannot guarantee delivery or inbox placement. Kayako bounce diagnosis.

For a regression, pause the affected change and restore only the approved records after checking other services. Retest the support conversation and authentication. Do not remove another application's key or weaken shared DMARC as an emergency substitute for a route-specific repair.