Sage Intacct SPF, DKIM and DMARC setup, step by step

To authenticate Sage Intacct email, enroll the actual sending domain in the enhanced email delivery service, publish its generated DNS records, and complete Validate domain. Then check a harmless message from the finance workflow you use. Authenticated means the record package exists; Validated is the readiness state. Neither substitutes for a passing, aligned DKIM signature on the delivered message. Sage Intacct domain settings.

This guide is based on documentation, not access to your company, DNS zone or delivered messages. No finance transaction or test email was performed.

Choose the correct company, domain and sending workflow

This guide covers the Sage Intacct enhanced email delivery service. It does not configure Sage 50, Sage Accounting, an employee mailbox, or a separate application that happens to read Intacct data. Identify the system that actually sends the invoice, statement or notification before changing its authentication. If the message was sent directly from an employee’s Microsoft 365 mailbox, use the separate Microsoft 365 SPF, DKIM and DMARC guide. Authenticating that mailbox does not validate native Intacct notifications.

Create an inventory with the finance owner:

• Company and, where applicable, owning Console or Practice.
• Message type and the action that generates it.
• Intended visible From address, reply mailbox and sender-domain owner.
• Whether the domain is an apex such as example.com or a child such as billing.example.com.
• Current domain status, DNS administrator and approved maintenance window.

Sage requires main domains and subdomains to be authenticated individually. Do not assume enrolling example.com enrolls billing.example.com, or the reverse. Its generic field descriptions also mention subdomains; follow the explicit separate-authentication workflow, and ask Sage to resolve any conflicting tenant behavior. The documented requirements are the Administration subscription, a business user with administrator privileges, and Company info View/Edit permissions. Domain settings and prerequisites.

A Console-validated domain can be inherited by descendant companies. Check the owning Console before creating a second configuration or attempting removal. Company-level delivery logs remain separate. For a standalone company, use its own configuration. Console and Practice email-domain management.

Understand the six DNS rows before publishing

The enhanced-service record package combines different controls. They are not six interchangeable SPF or DKIM records:

Sage's validation guide identifies row 4 at the sender domain and row 5 at intacct-mail-verify beneath it, and says one of those sender-security entries is sufficient for the described check. Use the actual package; Console configurations require the Console's ESK value. Do not copy tokens or selectors from screenshots. Generated-record validation and Console settings.

The email sender key is a public verification TXT value, separate from an SPF policy. Never append an intacct-esk= string to v=spf1. Nor does a sender key enable DKIM signing by itself. Keep SMTP credentials, application secrets and private signing keys out of DNS and support screenshots.

Sage's migration guidance distinguishes the enhanced SPF CNAME from the previous service's SPF TXT. An old root-domain SPF include therefore does not demonstrate that enhanced DKIM is working. Conversely, new CNAMEs do not prove that every legacy dependency can be deleted. Sage's enhanced-service migration guidance.

Generate the records and complete activation

Have the authorized administrator follow this sequence:

1. Open Company > Setup > Company > Security. For Console or Practice administration, use My practice or Console > More > Configuration.
2. Enter edit mode and find Email sender domain settings.
3. Choose Add a domain, enter the actual sender domain, and select Authenticate domain.
4. Save the domain-specific DNS table for the DNS administrator.
5. Publish the issued records safely, then return to that domain and select Validate domain.

These are Sage's documented controls, not a claim that they were exercised here. If your interface or hierarchy differs, reconcile it with the administrator before editing. Sage's domain workflow.

Keep a before-and-after record of the configuration and the generated values. A DNS ticket should list each fully qualified owner, type, value, current value and purpose. Avoid regenerating keys repeatedly while a publication problem is being investigated: that makes it harder to know which table is current.

Do not stop at Authenticated. Require the applicable Validated state, including the inherited Console state where relevant, and retain the verification result. Then proceed to message testing. An application status proves a configuration check, not which domain a particular notification used.

Configure SPF without breaking other senders

SPF checks the SMTP MAIL FROM domain, usually shown in a received message as Return-Path and in authentication results as smtp.mailfrom. It does not directly authenticate the visible From address. A passing envelope domain unrelated to the visible From domain is an SPF pass without DMARC alignment. SPF MAIL FROM identity.

For Intacct's enhanced service, use the generated SPF CNAME at its generated owner. Do not replace the company apex with that CNAME or add a guessed universal SPF include. Check the received envelope identity before deciding whether a root-domain SPF edit can address a failure.

For any required compatibility TXT change:

• Keep exactly one TXT policy beginning v=spf1 at the evaluated owner. Multiple separate SPF policies cause an error; unrelated TXT verification records may coexist.
• Merge only the authorized mechanism into the existing policy, before its terminal all. Preserve active mail services and the reviewed terminal qualifier.
• Evaluate the complete SPF lookup chain, including nested include and redirect terms, against the ten DNS-lookup-causing-term limit.
• Do not flatten provider IP ranges into a static list or remove active senders simply to make a checker turn green. SPF selection and DNS limits.

Apex SPF does not automatically apply to a child envelope domain. Likewise, a new root include cannot force the application to change its Return-Path. Retain legacy authorization until finance, mail and DNS owners have established whether a live or infrequent workflow still uses it.

If an existing SPF policy uses redirect=, preserve its intended authorizations and final semantics through a reviewed merge. Any all mechanism causes redirect to be ignored, so appending a canned policy or an all without reviewing that dependency can change which senders are authorized. SPF redirect semantics.

Put each record at the correct DNS owner

The following names illustrate placement only. issued-selector and issued-spf-label are placeholders, not Sage values. Substitute the complete owner from your generated table.

Confirm whether the editor expects a relative label or a fully qualified name. A doubled suffix creates the wrong owner. If a child zone has been delegated to other nameservers, publish inside that child zone; a record below the delegation in the parent is not the effective answer.

If _domainkey.billing.example.com itself is delegated, the illustrated full owner issued-selector._domainkey.billing.example.com is relative issued-selector in that zone. Preserve the NS delegation and publish at its authority, not in an ineffective parent-zone copy.

A CNAME owner must not also contain ordinary TXT, MX or A records. Resolve collisions with the DNS administrator and Sage rather than overwriting an active selector. Keep authentication CNAMEs DNS-only, without web proxying, and preserve their targets exactly. Do not change employee-mail MX records for this setup. CNAME exclusivity.

For authentication records that actually use CNAME, retain a literal CNAME answer to the issued target and use DNS-only rather than HTTP proxying. Turn the relevant per-record Flatten setting off where available, and ensure applicable whole-zone settings do not suppress the alias. On Cloudflare, 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 DNS-host behaviors, not assumed controls in the sending application. If mandatory behavior or shared settings cannot preserve the required CNAME answer, stop and coordinate a supported layout without breaking other services or removing shared NS delegations. Do not blindly disable features across the whole zone. Cloudflare verification guidance, flattening controls and limits.

Preserve DMARC and establish reporting

Sage recommends DMARC and places its configuration in DNS, not inside Intacct. Treat the provider's sample as explanatory, not an instruction to overwrite an established policy. Sage DMARC configuration.

DMARC passes when either SPF passes and aligns with the visible From domain, or DKIM passes and aligns. Relaxed alignment uses the same organizational domain; strict alignment requires an exact domain match. For example, d=example.com can align with From billing.example.com under relaxed DKIM alignment, but not under strict adkim=s. DMARC alignment.

Retain existing p, subdomain policy, reporting destinations and alignment modes. Check the policy applicable to the actual From domain before adding a child-domain override. If no applicable policy exists and the domain owner approves a monitored introduction, this is a minimal example, not a production value:

Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Replace the example domain and mailbox, and provision a monitored reporting destination first. Use _dmarc in an example.com zone that appends its suffix. For a deliberate policy at _dmarc.billing.example.com, use _dmarc.billing in the parent zone or _dmarc in the delegated child zone. Do not create duplicate DMARC policies at one owner.

Aggregate reporting helps identify repeated sender and alignment failures. External reporting destinations can require authorization by the reporting service. Reports are not proof of inbox placement or proof that a customer read an invoice. Failure reports can expose message information; do not enable them casually. DMARC external-destination authorization.

Compare the Organizational Domain of the aggregate-report URI host with the Organizational Domain of the domain where the DMARC policy was found, not automatically the visible From domain. If they differ, the report-generating receiver must check the destination’s DNS authorization. A destination in the same Organizational Domain as that policy domain is excepted, even when its hostname differs. This protocol check does not replace the domain owner’s separate approval to share report data with that recipient. RFC 9990 section 4.

Do not weaken enforcement to repair one Intacct route. Review all legitimate senders and forwarding paths before increasing enforcement; a single passing invoice is not a domain-wide readiness assessment. Current DMARC guidance requires valid DKIM for a domain publishing p=reject. Sender considerations.

Verify public DNS and the finance message separately

Check every generated owner

Replace all placeholders. These commands are read-only examples, not performed tests:

dig +short NS example.com
dig +short NS billing.example.com
dig @authoritative-ns.example issued-spf-label.billing.example.com CNAME +noall +answer
dig +short TXT issued-spf-label.billing.example.com
dig +short CNAME issued-selector._domainkey.billing.example.com
dig +short TXT issued-selector._domainkey.billing.example.com
dig +short CNAME second-issued-selector._domainkey.billing.example.com
dig +short TXT second-issued-selector._domainkey.billing.example.com
dig +short TXT intacct-mail-verify.billing.example.com
dig +short TXT billing.example.com
dig +short TXT _dmarc.billing.example.com
dig +short TXT _dmarc.example.com

Use the real authoritative nameserver in the @ query. A child NS query can be empty because the child is not delegated; establish authority rather than assuming an error. Query all issued types and compare the authoritative answer with a public recursive resolver after relevant cache TTLs expire.

Each CNAME should return its exact generated destination. Follow the SPF delegation to its effective TXT policy and both DKIM aliases to their public keys. Match the chosen sender-security TXT against the issued value. Distinguish missing data, NXDOMAIN, SERVFAIL and a query for the wrong record type. A blank +short answer alone cannot identify the cause.

Sage allows up to 72 hours for DNS validation, but waiting cannot repair a wrong owner or target. Once records match, complete Intacct validation and retain its result. Sage DNS checks.

Require a passing, aligned branded DKIM signature

With the finance owner's authorization, use harmless sample content and controlled external recipients to exercise each materially different company, sender domain and workflow. Do not send a real invoice, alter a customer account or initiate a payment just to test authentication.

Save the original message privately and record:

• Workflow, company, UTC time and Message-ID.
• Visible From and Reply-To, noting that Reply-To is not the DMARC identity.
• Return-Path, receiver-evaluated smtp.mailfrom, sending IP and SPF result.
• Every DKIM signature's d= domain, s= selector and receiver result.
• DMARC result, header.from, applicable alignment modes and the passing aligned mechanism.

Use the receiving system's trusted Authentication-Results, not an arbitrary header supplied upstream. Authentication-result trust and DKIM verification identities.

Use receiver-controlled diagnostic output, or have the receiving administrator establish which fields were generated inside its known processing boundary and document how externally supplied Authentication-Results are removed or distinguished. A familiar authserv-id string or header position alone does not establish provenance. Ignore attacker-inserted or otherwise untrusted results, including a forged field naming the expected receiver. Operational receiving-boundary requirements.

Accept the branded setup only when the intended customer-domain DKIM signature passes and aligns with the visible From domain, and the receiver reports DMARC pass. DMARC can technically pass through aligned SPF alone, but that does not verify the DKIM setup you just performed. A valid signature using only a provider-owned domain is also insufficient for this branded-DKIM acceptance check.

Record SPF separately. For a direct native message, expect a valid SPF result for the actual envelope identity. A provider-owned identity can pass without alignment; document that difference rather than calling it SPF failure. Actual fail, softfail, neutral, none, temperror or permerror needs investigation even if DKIM makes DMARC pass. Keep the exception open until explained or resolved, rather than marking the whole setup complete.

Troubleshoot the failed stage

Sage's documented retry timings and delivery-history distinction appear in its domain troubleshooting guide. Escalate with the owning company/Console, domain status, affected DNS row, exact error and redacted authentication evidence. Keep customer financial details out of the example.

Authentication does not certify that payment instructions are legitimate. Maintain normal finance approval and anti-fraud controls even when SPF, DKIM and DMARC pass.