Web.com SPF, DKIM and DMARC setup, step by step

For Cloud Mail purchased from Web.com before June 13, 2025, current Network Solutions documentation lists v=spf1 include:spf.cloudus.oxcs.net ~all. Its hosting/contact-form variant adds include:spf.registeredsite.com. Merge the applicable authorization into one existing SPF policy rather than overwriting other senders. Current Cloud Mail guidance says DKIM is included in the platform and does not require account-level setup. That statement does not prove that a particular message uses your domain for an aligned DKIM signature: verify the actual signing identity and receiver result. Cloud Mail DNS settings, Cloud Mail DKIM guidance.

No customer account, DNS change or message-delivery test was performed for this guide.

On this page

• Confirm that you have Web.com Cloud Mail
• Configure the applicable SPF policy
• Verify platform-managed DKIM
• Configure DMARC without weakening existing protection
• Validate DNS and a received message
• Troubleshooting and recovery
• Frequently asked questions

Confirm that you have Web.com Cloud Mail

This guide covers the legacy Web.com Cloud Mail sending service, not every mailbox, hosting product or domain registered with Web.com. Google Workspace, Microsoft 365, Standard Email, Professional Email and older webmail packages have separate instructions. A domain's registrar and DNS publisher may also be different from its outbound sender.

Web.com is becoming Network Solutions. The official transition FAQ says existing accounts and services transfer to Network Solutions, while email addresses remain unchanged unless the provider advises otherwise. It explicitly says the consolidation requires no DNS changes. Separately, the current Cloud Mail DNS page names Cloud Mail purchased from Web.com before June 13, 2025, establishing a product-specific link to the older Web.com service. This is why current Network Solutions Cloud Mail documentation is relevant here; the brand transition alone would not establish it. Official transition FAQ, legacy Web.com Cloud Mail section.

Before changing anything:

1. Confirm the email product in your account or with support. Network Solutions also provides a platform-identification guide that compares the logged-in webmail interface with its Cloud Email screenshot.
2. Identify the authoritative DNS host from the current nameserver delegation. Registering the domain with Network Solutions does not prove its DNS editor controls the active zone.
3. List the real message sources: staff mailboxes, website contact forms, transactional applications and third-party senders.
4. Preserve existing SPF, DKIM and DMARC records, their owner names and TTLs. Record the intended visible From domain and current envelope and signing identities when available.
5. Assign an authorized change owner and a record-specific recovery plan.

If the account is not Cloud Mail, stop using this procedure and use that product's documented settings. Do not switch its MX records or nameservers to make it resemble a Cloud Mail example. If a website submits through another SMTP or API service, follow that sender's authentication instructions. The WordPress sending-route guide explains how to separate website hosting from message delivery.

Configure the applicable SPF policy

Choose the correct authorization

The official Cloud Mail page gives these values for the legacy Web.com product:

The second row is not a universal prescription for every form on the internet. Confirm that the form actually uses the provider's documented hosting route. A third-party form service requires that service's own evidence. Cloud Mail SPF records and contact-form note.

The provider's page describes SPF as optional within its broader mailbox DNS setup. That does not mean a delivered message can pass SPF without suitable authorization, or that SPF can be ignored when you rely on it for DMARC alignment. Separate incoming-mail routing from outgoing-message authentication.

Preserve the complete sender inventory

SPF authorizes the connecting sender for the SMTP MAIL FROM domain, not directly for the visible From address. When MAIL FROM is empty, SPF uses HELO. Query the exact evaluated identity; an SPF record at example.com does not automatically cover bounce.example.com. RFC 7208.

If you already publish SPF, edit the single policy at that owner. Add only the necessary Cloud Mail authorization, preserve other active senders and keep one final all mechanism. Do not add a second v=spf1 TXT record. Other TXT records, such as domain-verification records, are unrelated and should remain. A single TXT record may contain several quoted character strings; quote count is not SPF-record count.

If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.

Review both the before-and-after policy and its nested dependencies. SPF limits evaluation to ten DNS-querying terms, including recursive include and redirect processing; a, mx, ptr and exists also count. ip4, ip6 and all do not count toward that term limit. Additional per-mechanism limits apply, and the standard recommends a limit of two void lookups. Counting only top-level includes misses these costs. RFC 7208 section 4.6.4.

An existing -all policy should not be weakened to ~all simply to match the example. Conversely, changing to -all without checking all senders can create failures. Treat the qualifier as an intentional policy decision.

Publish only the authentication change you intend

For an apex SPF record in the example.com zone, the final owner is example.com. The provider's Cloud Mail table shows @ (None) for this location. Use the DNS editor's actual apex convention and verify that it has not appended the domain twice.

If Network Solutions is the authoritative DNS host, its current procedure is:

1. Sign in to Account Manager and open Domains.
2. Select the domain and choose Manage, then the DNS tab.
3. Find the existing SPF TXT record, open its menu and choose Edit. Use +Add Record only if no SPF policy exists at the intended owner.
4. Enter the complete reviewed TXT value and TTL; confirm the correct host.
5. Save using Edit or Add, as applicable, and verify the published answer.

Its classic interface uses Advanced Tools → Manage beside Advanced DNS Records, then Classic View → Text (TXT Records) → EDIT TXT RECORDS, followed by Continue and Save Changes. If DNS is elsewhere, use that host's editor instead. Network Solutions TXT-record procedure.

Do not copy the whole Cloud Mail DNS table as an authentication repair. MX records control inbound delivery; the legacy Web.com and Network Solutions tables name different mail hosts even though their SPF examples match. Do not delete other MX entries, alter service-discovery records or change incoming-mail routing without a separately reviewed migration plan.

Verify platform-managed DKIM

The current official Cloud Mail section says DKIM is included in the platform and users do not need to set it up in their accounts. It points customers to the Cloud Mail DNS settings and platform-identification pages. The separate DKIM Manager → Configure with auto-generated keys procedure is for Edge Desk, ProMail and Webmail version 7.10.2, not a Cloud Mail activation step. Product-specific DKIM instructions.

Therefore, for confirmed Cloud Mail:

• Do not invent a DKIM Manager action or assume a missing button means the feature is unavailable.
• Do not create a random key pair and publish it. A key works only when the actual sender signs with its matching private key.
• Do not copy a selector, key or CNAME target from a different customer or email product.
• Verify the signature on a new delivered Cloud Mail message, including d= and s=, and the receiver's DKIM result.

The public Cloud Mail instructions reviewed do not give a universal customer selector, a self-service custom signing-domain control, or a guarantee that every Cloud Mail message signs with the customer's visible From domain. Those account-specific facts must come from your message evidence or support. “DKIM included” is not proof of branded DKIM alignment.

If support supplies domain-specific DNS instructions, retain the exact owner, type, public value and activation or validation requirement. A TXT public-key value and a CNAME hostname are not interchangeable. Never put private-key material in public DNS or routine support attachments. DKIM signing and public-key lookup, RFC 6376.

For a genuinely supported, issued custom record only, illustrative full owner SELECTOR._domainkey.news.example.com maps to SELECTOR._domainkey.news in example.com, SELECTOR._domainkey in a delegated news.example.com zone, or SELECTOR in an existing delegated _domainkey.news.example.com zone. Use the actual issued selector and preserve NS delegation and other selectors. These mappings do not establish a Cloud Mail custom-signing feature. Relative names.

If the message has only a provider-domain signature, it may authenticate successfully without aligning with your From domain. Check whether SPF provides the aligned passing path and ask support what branded signing is supported for this precise Cloud Mail account. Do not mark custom DKIM as configured solely because SPF makes DMARC pass.

Configure DMARC without weakening existing protection

DMARC compares the visible From domain with the SPF-authenticated domain and DKIM signing domain. A message passes when at least one of those authentication paths passes and aligns. Relaxed alignment permits the same organizational domain; strict alignment requires identical domains. aspf governs SPF alignment and adkim governs DKIM alignment, with relaxed as the default. RFC 9989.

For example, an SPF pass for bounce.example.com can align with From: accounts@example.com under relaxed alignment, but not strict. An unrelated provider-owned envelope domain does not align. A DKIM pass for d=example.com aligns with that From domain; a pass for an unrelated provider domain does not.

Inspect the existing policy and any applicable inherited policy before creating a record. Preserve current enforcement and reporting destinations unless an approved change requires otherwise. Do not replace p=reject with a generic p=none example or create a second DMARC record to accommodate Cloud Mail.

For a domain with no applicable policy and an appropriate monitored rollout, this is an illustrative starting point, not a record to publish unchanged:

Before publishing a first policy, establish absence of direct and applicable inherited policy and obtain the domain owner’s explicit approval of the monitoring and review plan. Preserve existing protection and use a provisioned, approved reporting destination.

Final owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Replace the address with a controlled, approved aggregate-report mailbox. In an example.com zone, Host _dmarc produces _dmarc.example.com; Host @ would be wrong for this record. For a distinct policy on news.example.com in the same zone, use _dmarc.news. In a delegated news.example.com zone, use _dmarc. Confirm the final full name and avoid duplicated suffixes.

p=none requests no DMARC-specific enforcement; it does not disable evaluation. Inventory all legitimate sources and review message and aggregate-report evidence before moving to quarantine or reject. Current RFC 9989 supersedes RFC 7489 and removes pct, so do not promise percentage-based enforcement. Receiver policy and reputation checks still affect delivery.

Reports contain operational sending information. Approve the recipient and its access controls before adding rua. If reports go to an external organization's domain, coordinate the required external-reporting authorization with that operator. Do not send reports to an address copied from a tutorial. Message-specific failure reports can expose additional information and are outside this starter setup. RFC 9990 aggregate-report authorization.

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.

Validate DNS and a received message

Public DNS acceptance

Run these example commands after replacing uppercase placeholders with actual account and message values. Use the authoritative nameserver for the particular queried owner, including any subdomain delegation.

dig NS example.com
dig @AUTH_NS TXT MAIL_FROM_DOMAIN
dig TXT MAIL_FROM_DOMAIN
dig TXT SELECTOR._domainkey.SIGNING_DOMAIN
dig @AUTH_NS TXT _dmarc.example.com
dig TXT _dmarc.example.com

For a provider-controlled envelope or signing domain, query that actual domain rather than adding records to yours to compensate. Where you control a DKIM record, also query its authoritative nameserver. If a provider-issued DKIM record is a CNAME, inspect the CNAME and follow it to the public key.

Only if Support actually issues a supported CNAME: keep it DNS-only where HTTP proxying is offered, resolve conflicting ordinary data at the same owner with its owner, and preserve the exact target and existing delegations. Keep the required literal CNAME answer: turn relevant per-record Flatten off where available and ensure applicable whole-zone settings do not suppress the alias. On Cloudflare, apex CNAMEs are flattened by default and same-zone targets are flattened regardless of that setting; flatten-all cannot be overridden per record. If mandatory behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration without breaking other services or removing NS delegation. These are DNS-host behaviors, not controls assumed in the sending provider. Cloudflare flattening controls and limits.

Expect one applicable SPF policy with the required active authorizations, the public key corresponding to the actual signature, and the intended DMARC policy. A DNS lookup proves publication, not message authentication. Inspect statuses: no data, NXDOMAIN, SERVFAIL and timeouts require different investigation. Network Solutions allows 24–48 hours for changes, but authoritative answers and resolver TTLs determine what is visible at a given time. Cloud Mail DNS guidance.

Message acceptance

Using your authorized test process, send a harmless message from the Cloud Mail mailbox to a controlled external recipient. Repeat separately for each hosted contact form and application route. Open the message's original source and use the Authentication-Results inserted by the receiver you trust. A sender-supplied header or another hop's result is not equivalent evidence. RFC 8601.

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.

Keep a private worksheet with:

For custom branded DKIM acceptance, require DKIM pass for the intended branded signing domain and alignment with From. A provider-domain DKIM pass or an SPF-only DMARC pass does not satisfy that test. If branded DKIM is not documented or observed, record that limitation rather than claiming custom-DKIM completion.

For that supported branded route, match the intended active account signature’s d= and s=, require its pass and alignment under effective adkim with the unchanged intended From, and require trusted receiver dmarc=pass. Another aligned signer or a rewritten provider From does not meet that branded requirement. Platform-managed signing remains distinct from a documented customer-signing feature.

Also diagnose genuine SPF fail, softfail, permerror and temperror separately. Aligned DKIM can make DMARC pass while an SPF problem still needs repair. Finally, review aggregate reports across representative sending activity. One passing mailbox sample does not validate all contact forms or third-party senders, and authentication never guarantees inbox placement.

Troubleshooting and recovery

If a change disrupts mail, preserve evidence and restore only the specific changed record or setting after identifying the cause. Do not roll the entire zone back over newer unrelated changes. Do not change MX records or downgrade DMARC to hide an authentication fault. Keep active DKIM selectors available while messages signed with those keys may still be in transit.