IRIS Cascade SPF, DKIM and DMARC setup, step by step

IRIS Cascade's Sending emails documentation, explicitly says it does not support DKIM and DMARC natively. That is a product limitation to investigate, not a reason to disable your domain's protection. It is also not proof that every Cascade message must fail DMARC: the actual sending route and aligned authentication decide the result. [1]

This guide helps a Cascade administrator identify the active route, interpret the documented SPF guidance, distinguish suppression from authentication failure, and prepare a safe decision about an alternative sender. It is not a native DKIM setup recipe or a complete Microsoft 365 OAuth migration guide. IRIS Merchant Central, IRIS CRM, KashFlow and other IRIS products are outside its scope.

First identify which Cascade route you use

IRIS's current data-protection FAQ identifies SendGrid as the default, an optional UK-pinned Amazon SES service configured by IRIS, and routing through a customer's chosen email relay. These are separate possibilities, not interchangeable DNS recipes. The presence of SendGrid in a product description does not give you ownership of its managed account or prove that generic SendGrid authentication steps apply. [2]

In Admin > Email service, an authorized administrator can inspect the selected authentication method and sending server. Capture the existing non-secret settings before proposing a change. The page includes Basic and OAuth methods, server name/URL, port and secure-connection configuration. It also exposes sender override fields. Do not change the server just to resolve a missing notification: a route change affects the application's outbound mail, not merely one DNS record. [3]

The older navigation reference in Sending emails points to System Properties. The dedicated email-authentication guidance explains that email settings have moved to Email service. Use the actual current page available in your environment and ask IRIS to clarify a mismatch rather than searching for a nonexistent toggle. [4]

Record these facts for the domain owner and IRIS support:

Exclude passwords, client secrets, access tokens and unnecessary employee data from screenshots or support evidence.

What the published SPF IP does and does not mean

The native sending page lists 192.254.125.237 as its SMTP sending IP. If IRIS confirms that this documented route still applies to your environment and that the SPF owner is yours to manage, its corresponding SPF mechanism is:

ip4:192.254.125.237

This is a mechanism, not a complete TXT record and not a universal instruction for an SES or Microsoft 365 route. Do not copy a space after ip4: from formatted prose. Confirm the actual evaluated sender before changing DNS. [1]

SPF evaluates the SMTP MAIL FROM identity; the HELO identity is relevant when the reverse-path is empty. A visible From domain alone does not identify the policy that the receiver evaluates. Adding an IP to the wrong domain can leave the actual failure unchanged. [5]

At the evaluated owner, preserve one v=spf1 TXT policy and all legitimate existing authorizations. Do not replace working Microsoft 365, Google Workspace or other sender entries. The policy owner must approve any addition and its qualifier. Do not switch a working qualifier to ~all simply because a tutorial shows it.

SPF's ten-term limit applies to evaluated DNS-dependent mechanisms and modifiers, including nested lookups, not just the number of include strings. An ip4 mechanism itself does not consume a DNS-dependent lookup, but the rest of the policy may still exceed the limit. An all mechanism causes redirect to be ignored. SPF qualifiers describe evaluation outcomes; they do not guarantee a receiver's delivery decision. [5]

A diagnostic lookup pattern, using the real evaluated domain in place of the placeholder, is:

dig <actual-mail-from-domain> TXT

Inspect its authoritative DNS state too. The example is read-only and contains no fabricated result. If the evaluated domain belongs to IRIS or its sending provider, ask that operator to investigate rather than attempting to edit an unrelated domain you own.

Native DKIM limitations: keep protection in place

The native page's limitation does not supply a customer DKIM selector, public key, CNAME target or activation workflow. Do not invent them. DNS publication cannot make a service sign messages if the signing configuration is absent.

The same source recommends disabling authentication protections or permitting spoofing exceptions in some circumstances. Do not use a blanket bypass as the solution. Keep existing direct and inherited DMARC policies, report recipients, other senders' DKIM selectors and anti-spoofing controls intact. A receiver exception can conceal a problem locally without authenticating mail sent to external recipients.

DMARC can pass through either passing, aligned SPF or passing, aligned DKIM. Therefore a documented lack of native DKIM does not establish universal DMARC impossibility. Conversely, an SPF pass with an unrelated envelope domain does not establish DMARC success. [6]

If your requirement is specifically aligned DKIM, the documented native limitation means that requirement has not been demonstrated on this route. Ask IRIS for an explicitly supported route that can meet it, with exact domain provisioning and signing instructions, before treating the work as complete.

Diagnose missing mail before changing authentication

IRIS describes suppression for invalid or bouncing recipients, spam complaints and addresses flagged by its email provider. A suppressed message may not reach the recipient at all, so changing SPF will not necessarily fix it. [1]

Use a controlled, approved record and a recipient you own to inspect one representative notification. Do not trigger payroll distributions, live employee notifications or bulk jobs merely to test delivery. Check the application's email queue and, for scheduled mail, the relevant scheduler job and intranet error log. The native email-authentication documentation identifies these as verification and support evidence. [4]

Separate the following outcomes:

• Not queued or not attempted: investigate the application workflow, intended recipient and scheduled job before DNS.
• Suppressed: check address accuracy and the reason with IRIS. Do not restore an opted-out or complaining recipient without the appropriate consent and policy review.
• Connection or authentication error: confirm the selected relay and approved credentials through its administrators. Do not disable TLS, open broad firewall access or change tenant-wide authentication settings as a shortcut.
• Rejected by a receiver: retain the exact response and sending-route evidence. A spoofing exception is not proof of correct domain authentication.
• Delivered but filtered: examine trusted authentication results separately from reputation, content and recipient filtering.

For SPF results, keep these diagnoses distinct even if another mechanism produces DMARC pass:

Sender overrides and alternative routes

Override from addresses, Show 'from email address' as, and Show 'from name' as are native Email service controls. An override changes the system sender identity. Changing a display name is not DKIM signing, and using another From address changes the alignment question. [3]

The separate September 2026 OAuth guide documents an opt-in Microsoft 365 route and recommends one authorized service mailbox for that configuration. It states that queued messages use the method configured when they are sent. A change therefore needs a queue-aware rollout plan, approval from the mail and application owners, and a controlled acceptance test. [4]

This article deliberately does not reproduce that page's application-permission and PowerShell examples as a ready-to-run migration. Such a change requires validated current Microsoft and IRIS instructions, least-privilege permissions, approved credential handling, transport policy and mailbox authorization. Nor does choosing the UK-pinned SES option itself establish its customer-domain DKIM setup; obtain the actual IRIS-managed provisioning packet for that option.

Before approving any alternative, require a clear answer to all of these:

1. Which intended From domains and message types must remain supported?
2. Who provisions the public DKIM records and activates signing for this exact route?
3. Which account-issued values and domain ownership checks apply?
4. What envelope identity will be used, and who owns its SPF policy?
5. What changes to sender identity, queued messages, data handling and access permissions are involved?
6. How will the previous approved configuration be recovered without weakening security or exposing credentials?

Do not create guessed DNS records, buy a separate sending account, or grant broader mailbox access as a substitute for those answers.

The acceptance evidence to require

Use original message headers or the recipient service's trusted diagnostic. The Authentication-Results must come from inside that receiving service's known processing boundary, with its documented handling of externally supplied result fields. An attacker can insert familiar-looking text; a matching authserv-id or header position alone is not proof. [7]

Capture the visible From domain, evaluated SPF identity, intended DKIM signing domain and selector if present, and the trusted DMARC result. Relaxed alignment compares Organizational Domains; strict alignment requires exact domain matches. Under current RFC 9989, Organizational Domain determination uses the DMARC DNS Tree Walk rather than a universal public-suffix-list or fixed two-label shortcut. [6]

For an alternative branded-DKIM route to satisfy that requirement, the intended signature must pass and align, and the receiver must report dmarc=pass for the intended visible identity. SPF-only DMARC success is not proof of DKIM. Rewriting the From address to a provider-owned domain is not successful brand authentication.

This guide does not introduce a new DMARC policy or reporting recipient. Keep approved protection and reporting unchanged while investigating. See raw DKIM results versus aligned DKIM policy results for interpretation.

What to send to IRIS support

Provide the environment, selected non-secret authentication method, affected message type, timestamp, exact queue or recipient error, intended From domain and whether the issue affects all messages or only particular recipients. Add sanitized trusted authentication evidence when a controlled message is available. Keep sensitive HR content and credentials out of the ticket unless a separately approved secure handling process requires specific data.

The useful outcome is a documented route decision and verified identities, not simply an allowlisted IP or a green queue status. Authentication does not guarantee inbox placement, and a public documentation review is not a customer implementation test.

Sources

1. IRIS Cascade: Sending emails. Native sending IP, suppression and stated authentication limitation; unsafe bypass recommendations are not adopted here.
2. IRIS Cascade: Common Questions about Data Protection. Distinguishes default SendGrid, IRIS-configured UK-pinned SES and customer relay options.
3. [IRIS Cascade: Email service](https://help-iris.co.uk/hr/cascade/hr/administration/appdata/email-settings. Native method/server and sender-override fields.
4. IRIS Cascade: Email Authentication changes. Separately scoped OAuth route, current navigation and queue evidence, not a complete migration recipe in this article.
5. RFC 7208: SPF.
6. RFC 9989: DMARC.
7. RFC 8601: Authentication-Results.

No accounts, credentials, sending routes, DNS records or receiver policies were changed; no customer message tests or publication were performed.