Scope: Cloud Mail is not every Web.com service
This guide retains the catalogue’s Web.com authentication topic but limits documented implementation to Cloud Mail SPF. It is not a verified DKIM configuration guide for every Web.com email package. The available provider guidance is an older Cloud Mail capture, so current account applicability must be confirmed before a change. A domain purchased from Web.com does not, by that fact alone, identify its outbound email service. Start with the subscription and sending route rather than the registrar logo.
The Cloud Mail page distinguishes its product from other email products. It lists SPF as optional within its overall DNS setup. Its normal example is v=spf1 include:spf.cloudus.oxcs.net ~all. For a hosting package or website contact form, it instead includes both spf.registeredsite.com and spf.cloudus.oxcs.net. It calls for one SPF record. These are documented examples, not values verified against a present customer account. Web.com Cloud Mail DNS settings
Establish the route before choosing a policy
Create a small inventory of message-producing applications. Distinguish a person submitting through a hosted mailbox from a website generating notifications, a marketing platform using the same visible address, and a third-party billing service. For each route, identify the team that can confirm its actual configuration. Record uncertainty explicitly. A purchase receipt for a domain or website is insufficient evidence that every application uses the same outbound infrastructure.
An SPF policy describes authorized sending infrastructure for an SMTP identity. It does not simply authenticate every message whose visible From field contains the domain. The relevant envelope identity can differ from that visible field. This matters when a website submits through another service or when an application uses a provider-controlled bounce address. A policy can be syntactically correct yet be irrelevant to the identity being evaluated. RFC 7208, HELO and MAIL FROM identities
The inventory should therefore distinguish known facts from questions awaiting account access. Mark the visible author domain, expected envelope domain, intended submission path and application owner. Leave unknown values blank rather than deriving them from a webmail address. This is a proposed evidence collection plan, not a report that any messages have already been inspected.
Preserve existing senders when preparing SPF
Before proposing a record, retain the current authoritative TXT response and its collection time through an authorized change process. Identify the single SPF policy at the relevant owner name. Other TXT records can coexist at that name, but multiple SPF policies cannot be resolved by simply choosing the newest-looking one. Multiple character strings inside one TXT resource record are also different from multiple resource records. RFC 7208, DNS resource records and multiple strings
Prepare a before-and-after comparison that preserves still-authorized senders. Do not replace a production policy with a short provider example merely because the example looks easier to understand. The final all mechanism also expresses policy intent. A sample ending in softfail does not authorize weakening an existing policy, and a stricter ending does not make an unreviewed sender inventory complete.
Review the complete evaluation path, including nested includes. The SPF limit concerns evaluated DNS-querying terms, not merely the number of visible include words in the top-level string. Caching does not make an excessive policy valid. Capture the proposed dependency review separately from the claim that a current live evaluation succeeded. No such evaluation is asserted here. RFC 7208, DNS lookup limits and include
Keep routing and authentication changes separate
An authentication change should not quietly become a mailbox migration. The owner of the change should explain why every proposed DNS edit is necessary. A mailbox destination change has different service consequences from an SPF authorization change. The rollback plan must be specific to the records actually approved, rather than a broad instruction to restore the entire zone from an old export.
This separation also protects unrelated applications. A domain may host a public website, incoming mail, service-discovery records and delegated third-party services. An authentication worksheet should identify the exact owner name, type and intended content. It should not ask an operator to copy a whole provider DNS table without understanding the consequences. DNS presentation can use relative names or absolute names depending on the editor; the operator must confirm the resulting owner name rather than assuming a universal interface rule. RFC 1035, master-file format
DKIM and DMARC remain separate acceptance questions
The documented SPF scope does not supply a verified Cloud Mail DKIM selector, public key or signing activation procedure. Those fields remain unresolved. Do not invent a default selector, borrow a key from a different hosting product, or treat the existence of an SPF include as proof that messages are signed. DKIM verification depends on the signature’s signing domain and selector and the corresponding published key. It is not established by a generic claim that hosting supports secure email. RFC 6376, DKIM-Signature and key storage
DMARC requires a passing authenticated identifier with the required relationship to the visible author domain. Passing SPF for an unrelated envelope domain is not enough. Conversely, aligned passing DKIM can provide the qualifying authentication path even when SPF does not align. The operational review should record which path supports each actual route rather than demanding an invented universal combination. Authentication does not guarantee inbox placement or prove that a message’s business request is legitimate. RFC 9989, identifier alignment and scope
Fictional diagnosis: two applications, one assumed route
Consider the fictional organization Marlin Workshop. Its administrator lists “Web.com” as the owner of both staff email and website receipts. A proposed change copies the shortest SPF example and removes an existing authorization without checking which application still uses it. This is a fictional planning error, not a reported incident or executed test.
The reviewer stops the change and separates the two application rows. The staff mailbox owner must identify the actual product. The website owner must establish how receipts are submitted. The DNS operator retains the existing policy and prepares a reviewed comparison only after those facts are available. If the routes differ, their evidence must differ too. The diagnosis is an unsupported assumption about shared infrastructure, not proof that a particular provider failed to authenticate mail.
Blank acceptance worksheet
Complete this worksheet only with authorized observations. Empty cells mean unresolved evidence, not a failed live test.
- Product and subscription evidence: ______
- Current provider confirmation and date: ______
- Application and accountable owner: ______
- Visible author domain: ______
- Actual envelope identity and evidence: ______
- Current authoritative SPF owner and value: ______
- Proposed change with retained senders: ______
- Nested dependency and lookup-limit review: ______
- DKIM capability, selector and activation evidence: ______
- Actual aligned authentication result: ______
- Change approval, rollback and observation window: ______
Release boundary
This manuscript supplies a scoped review method, not completed configuration. Current product applicability, generated account values, authoritative publication, received-message evidence, human subject-matter review, production routes, visual accessibility and owner release remain open. The catalogue’s broader implementation evidence requirement is unchanged. No DNS edits, support requests, messages or tenant tests were performed for this draft.