On this page: SPF · DKIM · DMARC · Verification · FAQs
To authenticate a domain sending through 20i mailboxes, review its single SPF TXT record, enable signing in My20i’s DomainKeys screen, and publish the generated public key at the authoritative DNS provider. Then test a delivered message for an aligned SPF or DKIM pass. A website hosted at 20i does not establish that its email follows the same route.
This guide covers 20i-hosted mailbox sending, including Stackmail SMTP. It is not a recipe for every VPS, third-party newsletter platform or domain that merely uses 20i DNS. No customer account, DNS change or email delivery test was performed.
Before changing records: identify the sender and DNS owner
Collect the domain used in the visible From address, a recent message’s Return-Path, its receiving system’s authentication results, and the application’s outgoing server. Record which hosting package contains the mailbox and who can edit its authoritative DNS zone. Export the existing zone and save the current SPF, DKIM and DMARC values before making changes.
20i lists smtp.stackmail.com for outgoing mailbox access. Its IMAP, POP and MX hosts serve different purposes: incoming-mail settings alone do not tell you where a website sends. A Gmail interface can also be a client of Stackmail rather than the final Google sending service. Inspect the configured SMTP route and delivered evidence instead of deciding from the app’s logo. 20i mail server names
Prepare a small route inventory: staff mail, website notifications, billing, marketing and support. For each, record the sending platform and domain identities. Changing the mailbox service does not authorize deleting records used by any of the others. If an application bypasses Stackmail, stop applying this mailbox procedure to that application and obtain its own authentication instructions.
Configure 20i SPF without replacing other senders
20i’s documented complete example is:
v=spf1 include:spf.stackmail.com a mx -all
This is a provider example, not a safe replacement for an existing mixed-sender policy. Newly provisioned packages receive Stackmail SPF automatically unless the account opts out. Check the actual zone first. For manual management, use Manage Domains, or Manage Hosting → select package → Manage DNS. In 20i’s root-domain form the Name field is blank and the type is TXT. An external DNS host may instead expect @ or a full domain name. 20i SPF instructions
SPF normally evaluates the SMTP MAIL FROM domain, not the visible From address; an empty reverse path uses the HELO identity. Publish at that exact owner name. A parent SPF policy does not automatically cover a subdomain. Keep one v=spf1 TXT policy per owner and preserve unrelated TXT records. If a policy exists, review and merge the required authorization rather than adding a second SPF record. Retain the existing terminal policy unless a separately approved sender review justifies changing it. SPF specification
The example’s a and mx authorize address and mail-exchanger hosts as senders too. Check whether that breadth is intended for your domain. Neither mechanism is automatically required simply because a website or incoming mailbox exists. Do not weaken a current policy to make a checker green, and do not copy third-party sender names from someone else’s example.
SPF has a limit of 10 evaluated DNS-query-causing terms, including nested include and redirect evaluation and mechanisms such as a, mx, exists and ptr. It is not a count of TXT records or visible includes alone. Evaluate the resulting policy before publishing; remove only authorizations confirmed obsolete. Do not freeze a managed service’s current IP list as a permanent substitute. RFC 7208 processing limits
Enable DKIM for the correct mailbox domain
In My20i, manage the hosting package, open DomainKeys, select the domain, choose an unused selector and add the signature. 20i generates a 2048-bit public key as a TXT record. With 20i nameservers it adds the record automatically; otherwise copy the generated public DNS record into the authoritative zone. Signing starts immediately for mailboxes under the selected domain, so allow for a period when signing is active but receivers cannot yet retrieve the key. 20i DKIM instructions
Treat the account-generated owner and value as a pair. Do not use a key from a screenshot or generate an unrelated key elsewhere: the public key must match the private key held by the signing service. Keep private keys and mailbox passwords out of DNS, tickets and public examples. If a TXT owner already exists, establish which service owns it before replacing anything.
Advanced DomainKeys options can restrict signing to a particular mailbox through Granularity/Identity. Leave unfamiliar options unchanged. If only one mailbox signs, inspect whether such a restriction was deliberately configured. The UI’s canonicalization and expiry choices concern signature handling; they do not change DMARC identifier alignment. 20i DomainKeys advanced settings
A DKIM lookup uses the selector and signing domain in the message, forming selector._domainkey.signing-domain. DNS suffix handling matters: a host that appends the zone automatically can turn a pasted full owner into a doubled domain. Check the published name, not merely the value displayed in an editor. DKIM key discovery
Keep DMARC policy separate from the setup wizard
My20i exposes DMARC Wizard under the hosting package’s Email tools. The documented workflow selects a domain, policy and optional advanced settings before adding a _dmarc TXT record. Inspect any existing record before using it; the wizard is not permission to overwrite a current policy. Its documentation still mentions policy percentage. 20i DMARC Wizard
Current DMARC is defined by RFC 9989, which supersedes RFC 7489. The old pct tag is obsolete, so do not build a rollout around percentage enforcement. DMARC passes when SPF passes with an aligned MAIL FROM domain, or DKIM passes with an aligned d= signing domain. Under relaxed alignment the domains share an organizational domain; strict alignment requires exact equality. An unrelated provider domain passing authentication is insufficient. Current DMARC standard
Preserve an established quarantine or reject policy and its alignment settings. For a domain without an applicable established policy, a monitored p=none rollout may be appropriate after checking parent-domain policy and all legitimate senders. Use an approved aggregate-report address; external destinations can require authorization. Failure reports may expose message details and should not be enabled casually. Aggregate reporting, failure-report privacy
First-time monitoring record: illustrative template
Only when no applicable established DMARC policy exists, a first monitoring record can look like this. Replace the example report mailbox with an address you control or a reporting service has authorized; do not publish the placeholder unchanged.
Type: TXT
Full owner: _dmarc.example.com
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
Use one DMARC TXT policy at that owner, with semicolons separating tags. In a DNS editor that appends example.com, the relative host is _dmarc. For the visible From domain news.example.com, the exact owner is _dmarc.news.example.com, or _dmarc.news within the example.com zone. Do not create a child p=none policy that overrides inherited parent enforcement. External rua destinations need the report receiver's authorization where required. RFC 9990 external reporting authorization
If news.example.com is a separately delegated authoritative zone, that same full DMARC owner is entered as _dmarc relative to the child zone, not _dmarc.news. Publish at the actual authority and preserve its NS delegation. These mappings apply only to an owner-approved first-policy rollout with no direct or inherited policy to preserve; do not create an unnecessary child override. DMARC policy publication, relative DNS names.
Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4.
Verify public DNS and a real delivered message
The following are read-only query patterns, not results from this review. Replace every example name with the exact identity recorded for your route:
dig +short NS example.com
dig +short TXT example.com
dig +short TXT selector._domainkey.example.com
dig +short TXT _dmarc.example.com
Use the actual MAIL FROM domain for the SPF query and actual selector/signing domain for DKIM. Compare the authoritative answer with a public recursive resolver. Expect one SPF policy, the matching public key and the intended DMARC record. A missing answer can indicate wrong delegation or an incorrect owner; waiting alone will not fix either. Respect previous TTLs when interpreting cached answers.
Send a new message from a real 20i mailbox to an external mailbox you control. Test desktop SMTP and each website application separately. Save the raw source and inspect the receiving service’s trusted Authentication-Results, not a sender-supplied header. Authentication-Results trust boundary
Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.
Record these acceptance criteria:
For this branded-DKIM setup, require the intended 20i/Stackmail signature to have trusted dkim=pass and its actual d= to align with the intended visible From under the applicable adkim mode, together with trusted receiver dmarc=pass. An unrelated signature or an SPF-only DMARC pass does not complete this DKIM check. Diagnose SPF fail, softfail, temperror and permerror separately even when DKIM supplies DMARC: inspect the actual envelope domain, connecting IP, full SPF policy and delivery path. Do not accept an unexpected From rewrite as brand authentication. DMARC identifier alignment, SPF results.
spf=passfor the expectedsmtp.mailfromidentity, where SPF is intended to authenticate that route.dkim=passfor the expectedheader.ddomain, with the intended selector visible inDKIM-Signature.dmarc=passfor the visible From domain, supported by at least one aligned passing method.- No unexpected fallback relay or From-domain substitution compared with the route inventory.
Repeat after changes and key rotation. A passing mailbox test is evidence for that message, not for every application or future message. Inbox placement also depends on reputation, content and recipient filtering.
Troubleshooting 20i authentication
No DKIM signature on a website message: compare its outgoing route with the mailbox test. A hosting package’s DomainKeys setting is not proof that a different sending platform uses that key.
Signature exists but the key is missing: inspect DNS delegation and the exact selector owner. Automatic zone changes are useful only if that is the zone receivers actually query.
SPF PermError after adding 20i: check for a duplicate SPF policy at the evaluated owner, then examine the evaluated lookup-term count. Preserve the prior record in your change log so the bad edit can be reversed without losing legitimate senders.
DKIM passes but DMARC fails: compare d= with the visible From domain and the policy’s alignment mode. If the only passing signature belongs to another domain, adding more SPF at the wrong owner will not repair that mismatch.
Messages fail only after forwarding: retain both original and forwarded headers. Forwarding changes the connecting server and may modify signed content. Diagnose the failing hop before altering the original sender’s policy.
For unresolved cases, prepare the package and domain, timestamp, Message-ID, selector, DNS answers and sanitized receiver results. Never send passwords or private keys as diagnostic evidence.
For a site-generated message that takes a different path, use EmailAuth’s WordPress SMTP and API route guide to identify the sending service before applying its DNS instructions.
What this review verifies
No customer account configuration, DNS publication or received-message test was performed. Follow the checks above against your own service before treating it as authenticated.