Distinguish hosting, DNS and outbound mail
This guide covers a domain whose mail is actually sent through xneelo's hosted-mail service. A website or domain hosted there may instead send through an external mailbox, accounting system or marketing service. Record the mailbox and SMTP route, the xneelo package and control panel, the authoritative nameservers, and the intended From domain. Save existing DNS and a baseline original message before editing anything.
The xneelo Control Panel DKIM article states that new hosting packages include DKIM by default, while externally hosted DNS needs its relevant record added or amended at the DNS provider. This does not establish the state of an older account, a self-managed server or an unrelated SMTP service. Obtain the current package-specific record and signing state rather than extending the default claim to all xneelo products. xneelo DKIM.
Review the existing SPF policy
xneelo's SPF article gives an example using a, mx and include:spf.host-h.net, ending with a soft-fail qualifier. It instructs customers with external DNS to amend the policy at that provider, and warns against multiple SPF records. Treat the full example as a configuration to assess, not a command to overwrite every existing policy. xneelo SPF.
Identify the actual envelope domain used by a direct test message. Inventory other systems authorized at that domain before merging anything. Preserve each necessary permission and review whether broad a or mx mechanisms belong in your own policy. Confirm syntax and the complete lookup budget. A policy can be syntactically present yet produce neutral, softfail, fail or permerror rather than pass; do not equate existence with success. SPF protocol.
Keep inbound MX routing stable during an authentication-only change. Do not add unrelated provider includes just because a third-party article lists them for a similar hosting brand. Names and historical branding do not establish which current service submits your message.
Confirm the actual DKIM record and signer
Get the public key and selector for the package and domain from its current configuration or support. At external DNS, verify the exact owner name and record type, taking care not to append the domain twice. Do not create a guessed default selector or copy another customer's key. Confirm the resulting authoritative answer before testing the sending workflow.
A correct DNS key is necessary for verification but does not demonstrate that the outgoing service uses the matching private key. Send a controlled message through the normal client and inspect the actual DKIM-Signature. Query the selector under its d= domain, then compare the trusted receiver's validation result. DKIM.
Compare direct mail, website mail and forwarding
Use separate evidence rows for paths that can behave differently. The following is a synthetic test plan, not a set of observed xneelo deliveries.
- Path: Hosted mailbox direct send; Evidence: SMTP target, original headers and receiver results; Decision: Establish the hosted-mail baseline
- Path: Website notification; Evidence: Application transport and observed identities; Decision: Determine whether xneelo mail or another service sends it
- Path: Forwarded message; Evidence: Post-forward results and preserved signatures; Decision: Diagnose forwarding separately from original sending
For each sample, record visible From, envelope domain, every d= and s= value and the receiver's SPF, DKIM and DMARC results. For a synthetic From of user@example.com, a passing d=example.com signature is an exact alignment case. A provider-owned signing domain does not become aligned merely because xneelo hosts the website. Apply the effective alignment policy to the actual identities. DMARC.
Repair with a package-specific plan
If records are visible only in a non-authoritative panel, publish them through the actual DNS owner. If DKIM is missing, confirm whether this package and route have signing enabled instead of assuming a new-package default covers them. If SPF fails, inspect the evaluated domain and service before editing the visible From domain. If only forwarding fails, retain the passing direct-send baseline and investigate the relay separately.
Restore the previous known-good DNS value if a merge disrupts other senders, and repeat the direct-send and affected-service tests. Coordinate key changes with the provider rather than deleting a selector needed by queued messages. Preserve DNS snapshots, package identity, test timestamps and received originals. Recheck after a package migration, DNS move or SMTP change. This manuscript used documentation only and makes no claim of live tenant or delivery verification.
Confirm the provider boundary
The SPF article’s 2019 neutral-policy history does not prove any current domain’s policy or pass result. Its simplified delivery descriptions are not receiver guarantees. The public DKIM page establishes a new-package default but supplies no universal selector or activation procedure; obtain the package-specific details and retain that boundary instead of inventing panel steps.
Work through a fictional diagnostic case
Fictional written case only: XN-01 assumes direct hosted-mail From help@shop.example has passing d=shop.example, while a website notification from the same visible address uses an external SMTP service. Its envelope and signatures are unknown. The mail owner keeps the passing direct baseline and assigns the website owner to verify the external service. A xneelo DNS key or new-package default cannot establish that external route’s signing state. No account, DNS, CRM, invoice, campaign or delivery was tested for this case.
Separate a passing message from enforcement readiness
RFC 9989 Section 7.4 requires valid DKIM for a domain publishing p=reject and cautions about indirect-mail interoperability. A single aligned SPF result does not by itself justify a reject-policy rollout. Review all legitimate routes and policy ownership separately from this provider setup.