Source review dated 8 November 2026. This is documentary guidance; account, DNS and received-message acceptance tests below have not been executed.
Separate system notifications from calendar invitations
Kallidus's System requirements document, dated 6 March 2026, specifies customer-domain SPF and DKIM for system-originated email. It describes a kallidus-suite.com sender when those actions are incomplete. Separately, its Learn calendar integration uses a configured Exchange or Microsoft 365 mailbox for invitations. These are distinct routes to inventory, not interchangeable proof of authentication. System requirements, printed pages 5–7.
Identify the exact product, tenant and business workflow before changing DNS. This guide follows the system-mail design in that document; it does not establish identical behavior for every product carrying the Kallidus brand. Ask the service owner which messages use the customer domain and which use an integrated mailbox. Include representative reminders and other enabled notifications in the review, without assuming that one message type covers the rest.
Assign an application owner, mail administrator and change approver. Preserve the previous sender configuration, current DNS values and a recovery contact. If staff depend on time-sensitive learning messages, choose a change window that leaves room to investigate failed delivery before the next deadline. A successful application action is not proof that its email reached the intended recipient.
Publish both selectors without disturbing other senders
The document specifies two CNAMEs for key rotation: kal1._domainkey beneath your sending domain points to dkim1.kallidus-suite.com, and kal2._domainkey points to dkim2.kallidus-suite.com. It identifies include:kallidus-suite.com for SPF, with a:mailrelay.kallidus-suite.com as a documented alternative when lookup limits are a problem. Confirm the intended approach with the service owner before publication. DKIM and SPF instructions, printed page 7.
Replace the documentation's domain placeholder with the approved sending domain. Write down each complete DNS owner and target before entering it into the DNS interface. Some hosts append the zone automatically. Check for existing records at both selector owners; a CNAME must not be combined casually with an existing TXT key. Preserve selectors belonging to other services and avoid replacing an entire DNS zone with a vendor example.
Keep one SPF policy at each applicable owner. Merge only the authorized mechanism, preserve other legitimate senders and evaluate the whole policy's DNS lookup cost. The documented a mechanism still performs a lookup; it is not a general exemption from SPF's processing limit. Do not convert a published hostname into a permanent list of observed IP addresses without an operational plan for changes. SPF specification.
The source is not a complete tenant-activation runbook. Obtain confirmation of any service-side enablement, the exact From identity and when the new configuration should take effect. Record that answer in the change ticket. Do not invent an Enable DKIM button or assume a successful DNS save has switched the application to the customer domain.
Collect evidence from the recipient side
Original acceptance worksheet, not an executed test: send harmless examples through each enabled route to controlled recipients. For every copy, record the product and workflow, timestamp, visible From, Return-Path, trusted SPF result and evaluated domain, every DKIM signing domain and selector, and trusted DMARC result. Keep calendar invitations in their own row rather than pooling them with system notifications.
A signature passing for an unrelated domain cannot satisfy customer-domain alignment. SPF also evaluates the SMTP envelope identity, not simply the address shown in the mail client's From field. Compare the real domains using the applicable alignment mode. DKIM's cryptographic validation and DMARC's domain relationship both matter. DKIM and DMARC.
Use content without employee records or training details. Restrict access to raw message sources and redact personal information in evidence shared with reviewers. Check replies and the intended notification action separately. Allowlisting may affect local filtering, but it neither proves authentication nor controls delivery at external recipients.
Recover and approve the actual route
If the customer-domain identity does not appear, ask whether application activation is complete before changing DNS again. If a key is unavailable, inspect the selector owner and CNAME resolution. If authentication passes but alignment fails, investigate the envelope and signing domains. Pause the affected change while retaining a known, approved notification route; do not lower domain-wide DMARC enforcement as a first response.
This documentary candidate includes no live tenant access, DNS lookup, delivered-message test or SME sign-off. Release requires confirmed product scope, activation instructions, both selector checks and receiving-system evidence for each relevant route.