Provider documentation checked on 8 November 2026. Account-generated values, entitlements and current support remain deployment prerequisites.
Scope and provider-specific configuration
References: RFC 7208 §3.2, RFC 7208 §4.6.4.
Stackmail authentication is documented by 20i. The SPF article identifies Stackmail explicitly and says newly provisioned hosting packages receive its SPF record automatically unless the account preference opts out. Inventory the existing zone before making a manual addition: an automatic policy and a new manual policy must not become two candidate SPF records.
For a 20i-registered domain, open Manage Domains and its DNS management. For a domain assigned to a hosting package, use Manage Hosting, select the package, and open Manage DNS. In the documented manual SPF form, leave Name blank, choose TXT and supply the reviewed policy. 20i publishes the baseline v=spf1 include:spf.stackmail.com a mx -all. This is a baseline for its service, not a safe replacement for every mixed-sender domain. The a and mx mechanisms authorize addresses derived from those names; retain them only when the intended sending inventory justifies them. Merge other legitimate services into one policy and check the SPF lookup budget before enforcement.
For DKIM, open Manage Hosting, manage the package, then select DomainKeys. Select the correct domain, add a selector and choose Add Signature. 20i says that when nameservers are with 20i it automatically creates the TXT record in Manage DNS. It also says signatures are added immediately to mail sent from mailboxes under the selected domain, so DNS availability matters during activation. If DNS is external, obtain the exact generated public record and publish at that host rather than assuming the automatic step reached it.
The documented key size is 2048 bits. Do not invent a shared public key, copy another customer's key, or treat a newly created selector as evidence that every application uses Stackmail. Website scripts and third-party campaign tools may take separate outbound routes. Test a mailbox submission and every materially different application route separately.
The decision that matters
The critical Stackmail distinction is automatic 20i DNS creation versus externally hosted DNS and separately routed applications. Illustrative diagnosis: a mailbox starts signing immediately, but its public key is still absent at external authoritative DNS. Adding another SPF include cannot fix that DKIM lookup defect. Coordinate public-key availability and signing activation before relying on the new route.
Verify the published records and the real sending path
References: RFC 7208 §3.3, RFC 9989 §4.4, RFC 6376 §6.
Record the change owner, sending product, domain, approved maintenance window and prior DNS answers before editing. Obtain the current record values from the named account or documented provider workflow. Separate values supplied by the provider from choices your organization controls, such as DMARC policy and reporting recipients. Existing mailbox MX, unrelated verification TXT records and active DKIM selectors are not cleanup candidates merely because a new service is being added.
Query the authoritative name servers for each exact owner and record type after publication. Record the query time, responding server and complete answer. Compare TXT strings as one logical value where the DNS response splits them into character strings. Check CNAME targets as well as the starting alias. Then compare a recursive-resolver answer to identify caching differences. A successful provider validation is useful evidence of configuration, but it does not establish what an actual recipient received.
Send only an authorized test to a controlled recipient using the intended product route. Retain the raw message and the trusted receiving system's Authentication-Results. Record the visible From domain, SMTP MAIL FROM or observed Return-Path domain, every DKIM d= and s= value, SPF and DKIM outcomes, and the receiver's DMARC result. A passing SPF or DKIM check supports DMARC only when its authenticated domain aligns with the visible From domain under the applicable policy. Reply-To and a branded display name are not alignment identities. RFC 7208, RFC 6376 and RFC 9989 provide the protocol basis for these distinctions.
Acceptance worksheet, recovery and evidence limits
This is an original acceptance worksheet, not a report of live testing. Mark each gate pending until evidence exists: account scope confirmed; previous DNS captured; exact new owner/type/value published; provider verification complete; intended route exercised; received identities recorded; aligned authentication confirmed; other senders unaffected. Assign a person and evidence file to every gate. A red gate blocks rollout even when the provider dashboard is green.
If a test fails, first distinguish missing publication, stale cached data, inactive provider configuration, wrong outbound route and nonaligned authentication. Correct the smallest demonstrated defect and test again. Do not weaken DMARC or delete other senders' records simply to make one test pass. If a change harms existing mail, use the approved recovery plan and the captured pre-change configuration, coordinating any provider-side sender change as well as DNS. Retain old keys while queued messages or an approved overlap still require them.
No customer tenant, authoritative before/after change or real received message was available for this manuscript. The retained sources support the documentary workflow; they do not satisfy the commissioned live-evidence gate. Independent checker review and human SME approval remain pending. Do not describe this guide as field-validated or publish it as having passed those gates.