Source review dated 8 November 2026. Provider settings and acceptance exercises below are documentary guidance, not executed account, DNS or message tests.
Identify the mail service and authoritative DNS
This guide covers email sent through one.com hosted mail. Begin by identifying the mailbox service actually submitting the message and the nameservers serving its domain. A website hosted at one.com can send through another relay, and a domain registered there can use external DNS. Neither a hosting invoice nor a working website proves that one.com signs a particular message. Capture a recent message from the exact mailbox or application workflow before deciding which records need attention.
The principal branch is whether one.com also hosts the authoritative DNS. Its DKIM documentation says DKIM is automatically activated when the domain uses both its nameservers and mail servers. For external nameservers, the DNS owner must publish the domain-specific CNAME records supplied by support. These are different operational paths; a control-panel switch in an inactive zone will not repair the published answer. one.com DKIM guidance
Record the business owner, DNS administrator and mailbox administrator before editing. Ask which outbound flows share this domain, including invoicing, website forms and campaigns. Preserve their authentication dependencies. If the job concerns only outbound authentication, leave inbound MX routing, nameserver delegation and unrelated website records outside the change. The provider's external-DNS article discusses MX as well, but an MX migration is not a prerequisite to every DKIM repair.
Resolve the migration branch before requesting records
The retrieved provider documentation contains an important difference. The dedicated DKIM article distinguishes four CNAME records for non-migrated domains from two for migrated domains. Its external-nameserver troubleshooting article still instructs readers to obtain four records. Do not choose the larger set, assume a migration date, or combine both sets. Ask one.com support to confirm the domain's current platform and issue the complete applicable record set. Keep that response with the change ticket. DKIM account guidance External-nameserver guidance
The response should identify each published owner, record type and target, plus whether old selectors must remain during transition. Ask whether any activation is required after publication and which message workflow support expects you to test. A list copied from another domain is not a substitute. The article intentionally supplies no guessed selectors or targets. Until the migration branch and record set are confirmed, the customer-specific DNS prescription remains on hold.
Check the existing SPF policy before using the standard toggle
one.com's SPF instructions describe a standard record, enabled automatically for newer domains, and a control-panel route through Domains DNS settings and Standard DNS settings. A custom configuration is a separate possibility. Before enabling a standard record, inspect all TXT answers at the actual envelope domain and check whether a custom SPF policy already serves other senders. The toggle is a configuration control, not permission to overwrite the organization's sender inventory. one.com SPF instructions
For external DNS, the provider's troubleshooting page identifies its hosted-mail SPF authorization. Use the current provider instructions as an input to one approved policy rather than pasting a standalone record next to an existing policy. Preserve the established all-mechanism decision unless changing it is explicitly in scope. Evaluate recursive include and redirect dependencies under RFC 7208 §4.6.4: the limit is ten evaluated DNS-causing terms, not ten packets or ten visible include entries. Two candidate SPF records at the same evaluated owner produce an error; multiple character strings inside one TXT record are a different matter. SPF RFC 7208
SPF authenticates the SMTP envelope identity, not the visible From address by itself. Record the receiver's evaluated domain. If an application uses a different relay and envelope, adding one.com's authorization to the visible domain may have no effect on that message. Correct the route inventory before changing more DNS.
Publish without resetting the zone
For DNS hosted at one.com, its editor guide supports TXT and CNAME records and describes an empty hostname as the domain root. It also warns that conflicting personal records can disable standard settings. The Reset DNS records control removes personal settings and restores defaults. Do not use that broad reset as a troubleshooting shortcut for one failing selector. Manage DNS settings at one.com
For externally hosted DNS, use that host's current input conventions. Keep the intended fully qualified owner separate from the value typed into its Host field. This prevents a complete owner from being expanded twice. Preserve the existing record set and TTL before saving. For each provider-issued CNAME, check for a conflicting TXT record or another service's selector at the same owner. Resolve ownership before replacement. The delegated target is public information; no DKIM private key belongs in DNS. DKIM RFC 6376 DNS RFC 2181
After publication, query the authoritative servers for the exact owner and record type, then check a recursive resolver separately. Retain the raw answers and query times. Provider propagation estimates are planning guidance, not evidence of success. A record can be saved successfully in the wrong zone or under the wrong label and still never help the real message.
Verify DMARC using the message identities
Review the domain's existing DMARC policy before adding another record. Keep approved reporting destinations and alignment modes unless the policy owner authorizes a separate change. A provider's example does not justify replacing an established enforcement policy. DMARC can pass through either a passing aligned DKIM signature or a passing aligned SPF result. A valid signature belonging only to an unrelated service domain does not establish alignment with the visible From domain. DMARC RFC 9989
Send a controlled message from the actual hosted mailbox to an independently operated mailbox. Preserve its raw source and the receiving system's trusted Authentication-Results. Record the visible From, envelope identity, every DKIM d= and s= pair, authentication outcomes and DMARC result. If website-generated mail matters, test that workflow separately. A successful webmail message does not prove that a PHP form or external SMTP application follows the same route.
If authentication passes but the message enters spam, keep the authentication result intact and investigate content, reputation, recipient filtering and delivery errors separately. Do not keep adding SPF authorizations in response to every spam-folder complaint. Authentication establishes identities; it cannot promise inbox placement.
Reusable one.com route worksheet
Use one worksheet per mailbox or application route. Leave unsupported fields pending rather than filling them from a different customer's setup.
- Domain, business workflow, mailbox and service owner: ______.
- Actual submitting service and evidence from its settings: ______.
- Authoritative nameservers and DNS account owner: ______.
- one.com DNS or external DNS branch: ______.
- Migrated or non-migrated status confirmed by support, with date: ______.
- Support-issued DKIM owners, record types, targets and retention instructions: ______.
- Existing SPF policy, evaluated envelope owner and approved merged change: ______.
- Existing DMARC owner, policy and approved reporting destinations: ______.
- Before and after authoritative answers, TTLs and query times: ______.
- Received-message reference, From, envelope, DKIM identities and trusted outcomes: ______.
- Rollback owner, preserved record set and workflow retest: ______.
- Current account walkthrough, visual inspection and human approval: pending.
Fictional diagnosis of a migrated mailbox
This example is fictional and is not a test result. A retailer moves its website DNS to another host while keeping one.com mail. A technician finds an older four-record checklist and adds four guessed selectors. Webmail still sends, but the independent receiver reports a DKIM lookup failure. The retailer also adds a second SPF policy, creating a separate problem.
The correct diagnosis begins with authoritative answers and the message's actual selector, not with the number of records entered. Support confirms the fictional domain is on the migrated platform and supplies its applicable two-record set. The administrator restores one valid SPF policy, resolves selector conflicts and publishes only the confirmed CNAMEs at the active DNS host. The proposed acceptance test is a new received message with a passing aligned authentication path. No part of that recovery has been performed for a real domain in this article.
Close the change only with independent evidence
If the new records do not produce the expected result, pause affected application sends when practical and compare the support prescription with authoritative DNS. Escalate the migration discrepancy with the exact owner and selector. Do not reset the zone or remove old selectors without checking whether queued mail or another route still uses them. Restore only the affected records from the approved baseline when rollback is required.
Documentation supports the process above, but customer-specific support confirmation, a current tenant walkthrough, live DNS capture, received-message evidence, visual review and human SME approval remain pending. A completed worksheet can support those decisions; blank fields and a green control-panel status cannot close them.