Provider documentation checked on 8 November 2026. Account-generated values and current product support must still be verified for a real deployment.
For 20i-hosted mailboxes, enabling a DomainKeys signature and publishing its DNS record are related but separate actions. The first controls outgoing signatures; the second lets recipients verify them. This guide covers the documented 20i hosting-package route. A website using a different SMTP service must be tested as a separate sender even if its web hosting is with 20i.
Prepare the mailbox and DNS boundary
Choose the hosting package and exact domain whose mailboxes should sign. Confirm where DNS is authoritative and save its current SPF and DKIM records. Identify a test mailbox under that domain and an external mailbox you control. Keep the account administrator and DNS operator available during the change, particularly when DNS is hosted elsewhere.
20i's DKIM instructions describe 2048-bit keys and automatic TXT publication when the nameservers are with 20i. They also say signing starts immediately after adding the signature. Schedule the operation so external DNS publication does not become an unattended gap between signing and verification.
Create the signature in the correct package
References: RFC 6376 §3.4.
Open Manage Hosting, manage the intended package, then select DomainKeys. Confirm the selected domain, choose an unused selector and select Add Signature. Record the generated public DNS value and owner. When 20i serves the nameservers, inspect the record in Manage DNS rather than assuming the automatic action succeeded. With external authoritative DNS, obtain the generated public record from the account workflow or support and publish it there before declaring success. Never publish a private signing key.
Keep advanced signature restrictions deliberate. A mailbox-specific configuration needs a test from that mailbox and another from any mailbox expected to remain covered. Do not change canonicalization merely to hide a failing downstream modification; relaxed canonicalization permits defined formatting differences, not arbitrary edits to a signed message.
Reconcile Stackmail SPF with other senders
References: RFC 7208 §4.5, RFC 7208 §4.6.4.
The SPF guide says new hosting packages receive Stackmail SPF by default unless account preferences opt out. Its manual workflow uses Manage Domains or Manage Hosting, the package, then Manage DNS. It documents a blank Name, TXT type and v=spf1 include:spf.stackmail.com a mx -all for its baseline configuration. This is the provider's example, not a replacement for a multi-service policy.
Inspect the existing authoritative TXT answer first. If other services legitimately use the same envelope domain, merge the required authorization into one policy. Evaluate whether a and mx are intended permissions in your environment. Check evaluated include, a, mx, ptr, exists and redirect terms across nested SPF processing against the ten-term limit, and retain the approved terminal policy. An SPF pass for an unrelated envelope domain does not make the visible From aligned.
Test mailbox coverage and alignment
References: RFC 9989 §4.4.
Query the new selector owner directly at the authoritative nameserver, for example dig @AUTH_SERVER TXT SELECTOR._domainkey.example.com. Replace every placeholder with the account's actual values. Compare the returned key to the generated public value, then check a recursive resolver after publication. A missing answer at authority is a publication issue; an old recursive answer is a different problem.
Send a plain message from the selected mailbox using the real client or submission route. Inspect the recipient's trusted results for DKIM pass and record d= and s=. Confirm the visible From aligns with a passing path under the domain's DMARC alignment mode. Test webmail, desktop submission and website-generated mail separately when they use different routes. An unsigned website message does not prove mailbox signing is broken.
Maintain and recover the configuration
Illustrative acceptance case: staff@example.com signs with d=example.com and the newly selected selector, while a website sends through another provider. Accept the mailbox change only; keep the website route open for separate remediation. Do not lower the entire domain's enforcement policy to mask that separate sender.
If the new selector fails, pause expansion, retain the captured message and compare DNS against DomainKeys. Restore the prior working configuration if available and approved; do not delete active selectors without considering in-flight mail. Review signatures after package moves, nameserver changes, mailbox restrictions or key rotation. No tenant login, DNS change or test send was performed for this guide.