Source review dated 8 November 2026. This is documentary guidance; account, DNS and received-message acceptance tests below have not been executed.
Choose who will operate the sending domain
Inxmail authentication begins with a domain-design decision, not a universal SPF include. Its current help distinguishes a dedicated subdomain delegated to Inxmail, a dedicated subdomain configured through aliases, and an existing main domain or subdomain configured through aliases. Delegation gives Inxmail responsibility for the delegated domain's DNS maintenance. The alias alternatives leave work with your DNS team. Choose deliberately before onboarding: a subdomain used by other applications is not an unused namespace merely because it has no website. Scenario guidance.
This procedure covers the Sending domains workflow documented for Inxmail Platform, Newsletters & campaigns, Commerce transactional mail and Professional. Record which product and sending workflow you actually use. Assign a campaign or application owner, DNS administrator and security approver. List the proposed visible From domain, bounce domain, reply destination, existing records and scheduled sends. Preserve the working route while evaluating the replacement.
Do not delegate a populated namespace without reviewing everything it serves. Ask who will maintain DMARC, who can revoke the delegation and how records will be recovered when the service is retired. An exclusive marketing subdomain can simplify ownership, but it is not an automatic exemption from the organization's domain policy.
Register first and copy the scenario specific records
Inxmail explicitly requires creating the sending domain inside the service before publishing its DNS records. In Platform or Newsletters & campaigns, Sending domains is under Account management. Commerce uses Settings; Professional uses Global settings. The creation action is New domain or Authenticate additional domain, depending on the product. For the selected model, supply the intended sending and bounce identities rather than treating them as interchangeable labels. Domain setup.
When configuring reply forwarding, use an existing real destination mailbox outside the subdomain being authenticated. Inxmail warns that forwarding the catch-all back into that subdomain creates a forwarding loop. Confirm the destination and its owner before publishing DNS. Reply forwarding prerequisite.
Open the domain's Preview or Detail view and obtain the complete generated record set. Publish that set at the authoritative DNS provider. The record types and values vary by scenario, so this guide intentionally supplies no substitute selector, SPF include or delegation target. With no delegation, Inxmail says the customer retains ongoing DNS maintenance, including DMARC. It warns that isolated delivery problems can occur during the first 72 hours after setup. DNS publication and maintenance.
Before saving, expand every owner to its full domain name and compare it with existing records. Avoid a doubled zone suffix, duplicate SPF policies or a CNAME colliding with other data. Preserve unrelated mail services. Where the selected scenario requires customer-managed SPF, evaluate the whole policy, including nested lookups, rather than counting only the includes visible on one line. SPF specification.
Connect the authenticated identity to real mail
A validated domain must also be used in the actual From address. Inxmail describes green validation or Ready status, with differences between product interfaces. Configure the relevant list, mailing or relay source accordingly. Professional installations with multiple subdomains also need attention to each list's website and tracking-link settings. Inxmail's broader Full Domain Alignment terminology includes these links; DMARC's alignment test concerns the authenticated email domains, not the hostname of a clicked link. Using the authenticated domain and DMARC.
Original acceptance worksheet, not an executed test: send a harmless message through each intended production workflow to controlled external mailboxes. Record the product, list or application, time, visible From, Return-Path, trusted SPF result and evaluated domain, every DKIM d= and s= value, and trusted DMARC result. Also send a controlled reply and confirm it reaches the real external destination mailbox without a catch-all loop; check one representative website or tracking link.
A passing SPF result for an unrelated envelope domain does not establish alignment. Likewise, a DKIM signature's presence is not evidence of successful validation. Confirm that at least one passing authentication path aligns with the visible From under the applicable policy. Keep message sources access-controlled and remove recipient details from shared review notes.
Close the change with evidence
If the domain fails validation, compare the generated records with authoritative DNS before changing application settings. If DNS looks correct but received mail fails, investigate the actual From and signing or envelope identities. Pause the new rollout and retain the previous approved route instead of weakening a parent domain's policy.
These are documentary candidates based on first-party pages retrieved on 8 November 2026. No tenant, live DNS, message delivery or SME review was performed. Release requires account-specific records, successful workflow tests and agreement on the delegated or customer-managed maintenance responsibilities.