Source review dated 8 November 2026. Provider settings and acceptance exercises below are documentary guidance, not executed account, DNS or message tests.
Identify who transmits the invoice email
IRIS KashFlow documents both SPF authorization for its own sending service and an SMTP override that asks your mail server to send on your behalf. Start by determining which route the account uses. The application producing an invoice and the server transmitting its email are not necessarily the same provider. This guide concerns KashFlow accounting email, not an assumed identical setup for separate payroll or HR products. SPF guidance and SMTP configuration.
Record the business owner, selected route, visible From address, reply destination and DNS administrator. Preserve the previous settings before a change. For a business approaching an invoice run, agree who will stop or retry affected sends and how duplicate invoices will be avoided. Do not use a real customer's outstanding invoice as an unrestricted diagnostic attachment.
Apply SPF to the appropriate sending route
The current IRIS help page, retrieved with a 2 October 2026 update date, specifies include:spf.kashflow.com and says to merge it into an existing policy when one exists. Current instructions.
Confirm that the relevant workflow actually uses KashFlow's sending infrastructure before adding authorization. Publish one SPF policy at the applicable owner, preserving legitimate services already listed. Do not copy the example's ?all ending over an existing policy decision without review. Check nested DNS lookups and inspect the actual SMTP envelope domain. SPF evaluates that identity; adding a mechanism to the visible From domain does not automatically make an unrelated envelope align. SPF specification.
The retrieved first-party SPF pages do not provide a customer-domain DKIM selector or activation procedure for the default service. That gap does not establish that DKIM is unsupported. Ask IRIS to confirm current support for the exact account, including the signing domain, any customer-domain option and supported envelope customization. Do not invent a selector or turn an unanswered support question into a product limitation.
Treat SMTP override as a separate implementation
IRIS documents SMTP Configuration under Configuration settings, reached through Settings or Account Settings in the newer design. Its override option includes a sender identity, mail-provider authentication and a Test Email action. The page distinguishes Microsoft Exchange OAuth configuration and says SMTP settings cannot be edited during a trial. Confirm current provider requirements before using the published connection examples. SMTP override instructions.
For this route, establish SPF and DKIM at the actual mail provider and test the identities it uses. Do not assume the KashFlow include belongs in every custom-SMTP configuration. Connection credentials and OAuth grants also create ongoing access: have the authorized administrator approve and configure them through the approved secret-handling process. Keep passwords, client secrets and tokens out of change tickets and message evidence. A successful connection check is only the start of acceptance.
Verify an actual accounting workflow
KashFlow's invoice instructions describe an Email action, an attached invoice and a send note added to the customer record. Its troubleshooting page explains where invoice, quote and statement send records can be found. Those records help establish an application event; they are not a receiving-system DMARC verdict. Invoice email workflow and send records.
Original acceptance worksheet, not completed evidence: send a harmless, approved test document to controlled external mailboxes through the selected workflow. Avoid changing a real customer's saved address while redirecting a test. Record the route, document type, application timestamp, visible From, Return-Path, trusted SPF result and evaluated domain, every DKIM d= and s= value, and trusted DMARC result. Confirm replies and attachment readability separately.
DMARC requires an aligned passing SPF or DKIM path. A signature from an unrelated service domain or a local BCC copy is insufficient evidence that every recipient will authenticate the customer domain. DKIM and DMARC.
If authentication fails, investigate the selected transport and actual identities before resending invoices or changing organization-wide policy. No tenant, live DNS, message test or SME review was performed here. Release requires route confirmation, any missing native-service capability answers and successful recipient-side evidence.