Use the enhanced service workflow for the actual sender domain
Sage Intacct's enhanced email delivery service has a domain workflow that includes account-generated DNS records and a separate validation step. Start with the finance communication the organization needs to send, such as a controlled invoice or payment-notification test, then identify its intended sender domain. Do not assume an old SPF authorization or email sender key proves the enhanced route is ready. This guide covers domain enrollment, record review and message-level acceptance, with live account verification still pending.
The current domain settings guide explicitly says that main domains and subdomains need separate authentication. It also distinguishes Authenticated from Validated: the former still requires validation before authenticated sending is ready. Use those workflow statements rather than interpreting a familiar domain name or a successful earlier email as completion. The same page’s generic field descriptions also mention sending from subdomains; because that wording differs from its explicit separate-authentication instructions, resolve any tenant-specific ambiguity with Sage rather than assuming inherited subdomain authentication.
Inventory the sender addresses used by each relevant company and workflow. Record which administrator owns the configuration, which person can change DNS, and who can approve a harmless finance-system test. Avoid sending real invoices or payment instructions solely to test authentication. A test should exercise the real application route while using controlled recipients and non-sensitive sample content.
Establish company and console ownership before editing
Open Company, Setup, Company, then the Security tab and Email sender domain settings, as described in the provider's guide. Check which company or Console owns the domain configuration. Current documentation describes Console-managed inheritance, so a domain shown in a company may be managed higher in the hierarchy. Do not create duplicate company-level configuration or remove records before identifying that owner.
Record the exact displayed state and the date. If the account differs from the public instructions, stop at the mismatch and ask the authorized administrator or Sage support for the current workflow. A product article cannot establish the permissions or hierarchy of the organization's tenant. Keep inherited settings, standalone company settings and older records distinguishable in the change request.
Plan rollback with the finance owner. Pausing a test is different from interrupting an invoice run, and changing a sender can affect customer recognition or reply handling. Preserve the prior approved configuration and choose a window that avoids critical billing activity. Authentication cleanup should not silently change who appears to have sent a financial notice.
Generate and preserve the domain specific record table
For an approved new domain, use the documented add-and-authenticate workflow and save the DNS table generated for that domain. The public guide describes a table with an SPF CNAME, two DKIM CNAMEs, sender-security TXT entries and a legacy SPF entry for compatibility. Copy the actual account's owners, record types and values. No sample selector, long token or screenshot value in this article is a reusable configuration.
Keep the generated table with the change ticket and annotate which purpose each row serves. Distinguish the enhanced service's delegated SPF owner from the older SPF policy at the main domain. Treat the company verification TXT value as its own record rather than folding it into an SPF string. Different controls can share the DNS zone without sharing a syntax or operational purpose.
The DNS validation guide explains checking the sender-security alternatives and notes that one of those entries is sufficient for the described check. Confirm the appropriate choice against the generated table, especially for Console-managed configuration. Preserve uncertainty if the actual account requires a different arrangement; do not use an example to override its current instructions.
Publish records while preserving existing mail services
Export the affected DNS records first. Compare every issued owner with existing records and delegations. A CNAME conflict needs an administrator's supported resolution, not a second record of another type at the same owner. Check whether the DNS editor expects a relative label or fully qualified name and verify the resulting public name after saving. The final DNS answer is the evidence that matters.
Where the backward-compatibility SPF entry requires a change to an existing policy, review the complete policy under RFC 7208. Keep one SPF policy at the evaluated owner, preserve other active senders and account for nested DNS-querying terms. Do not paste an additional SPF record beside the existing one. Do not remove legacy authorization simply because the enhanced records are present; first establish whether any live workflow still depends on it.
Keep public records separate from credentials and application secrets. The DNS table is suitable for the authorized DNS administrator, but an evidence package does not need unrestricted tenant exports or customer data. Redact unnecessary transaction details while preserving enough context to associate a test with its workflow and company.
Check the issued owners and complete validation
Check each CNAME's exact owner and target, then verify that the delegated lookup resolves as expected. Check DKIM using the actual selectors shown in the generated table. The provider's validation guide contains illustrative selector formats; copying those examples into a different tenant is not a valid test. Record lookup time, resolver and returned value so a later reviewer can distinguish stale data from a transcription error.
Return to the selected domain in Email sender domain settings and use Validate domain. Preserve the resulting state or error. DNS caches and provider checks can delay recognition, so avoid repeatedly regenerating configuration while records are still settling. If validation fails, compare the published names, types and values first, then investigate the precise row that is unresolved.
A Validated state is useful enrollment evidence, but it does not prove that the intended invoice or notification used that identity. Keep the next message-level test as a separate gate. An administrator should be able to show both the domain's readiness and the receiver's result for a representative message from the business workflow.
Verify finance messages at a controlled external receiver
Trigger an authorized test from each materially different company or sending workflow. Save Message-ID, UTC time, intended sender and the application action that produced the message. Also record where the reply goes. A reply address can be operationally important without being the domain that SPF evaluates or DKIM signs.
Inspect the receiving system's trusted authentication results. Record the visible From, Return-Path and every DKIM d= signing domain and s= selector. RFC 6376 defines the relationship between those DKIM fields and the DNS verification key. A successful DNS check for a configured selector does not establish that the message used it; the actual signature resolves that question.
Under RFC 9989, DMARC requires a passing SPF or DKIM result with the appropriate relationship to the From domain. Apply the domain's configured alignment mode and record which mechanism supplies the aligned pass. A payment notification landing in an inbox does not prove alignment, and authentication does not prove the accuracy or legitimacy of a financial instruction. Those are separate business controls.
Investigate failures using both the application and message evidence
If no test message arrives, establish whether the application attempted to send it before changing DNS. Preserve the relevant delivery-history entry or error. The domain guide identifies different history views depending on the domain's validation state; use the view appropriate to that state rather than interpreting an empty view as proof that nothing happened.
If the message arrives with an unexpected From, reconcile the workflow's sender selection with the authenticated domain inventory. If DKIM is absent or fails, compare the actual selector and public answer, and check whether a downstream gateway modified the message. If SPF passes but DMARC fails, examine alignment. An additional root authorization will not repair every envelope-domain mismatch.
Escalate with the company or Console identifier, domain state, affected DNS rows, test time and redacted authentication evidence. Keep real customer financial details out of the support example. Preserve the existing DMARC policy unless its owner approves a broader change covering all legitimate senders.
Sage Intacct domain worksheet
- Company or Console owner and responsible administrators: ____.
- Business workflow, intended sender and reply mailbox: ____.
- Main domain or separately enrolled subdomain: ____.
- Generated DNS table reference and instruction date: ____.
- Enhanced SPF delegation and both DKIM record checks: ____.
- Sender-security choice and legacy SPF dependency review: ____.
- Displayed domain state before and after validation: ____.
- Test Message-ID, UTC time and delivery-history reference: ____.
- Observed From, Return-Path, DKIM identities and aligned result: ____.
- Exceptions, approved recovery and reviewer: ____.
Fictional example of stopping at the wrong status
Fictional written case only: SI-01 assumes the parent example.org domain is Validated at the owning Console, but the invoice workflow intends From invoices@billing.example.org. Enrollment for billing.example.org is unknown and no received results exist. The finance administrator must verify the separately authenticated subdomain and actual workflow before scheduling the harmless test; parent-domain status cannot establish coverage. If the displayed status is only Authenticated, complete DNS validation first. No real invoice, tenant or transaction was inspected.
Retain the remaining release gates
Current tenant inspection, generated record review, live DNS and header verification, visual review and human SME approval remain pending. Resolve any discrepancy between public documentation and the actual company or Console before publication. This article is an unpublished implementation draft, not confirmation that an organization's finance messages are ready for production.
Separate a passing message from enforcement readiness
RFC 9989 Section 7.4 requires valid DKIM for a domain publishing p=reject and cautions about indirect-mail interoperability. A single aligned SPF result does not by itself justify a reject-policy rollout. Review all legitimate routes and policy ownership separately from this provider setup.