names.co.uk SPF, DKIM and DMARC setup, step by step

For Names.co.uk hosted email, publish one SPF TXT policy containing include:spf.hosts.co.uk, then enable DKIM in Services → Dashboard → your domain → Manage Email → DKIM → Enable. This automatic DKIM workflow requires active Authenticated SMTP and Namesco nameservers. Namesco creates the DNS records and enables signing for the domain's email users. Official SPF instructions and official DKIM procedure.

This guide covers existing Names.co.uk custom-domain mailboxes using that supported combination. It does not apply to Microsoft 365, another sending platform whose DNS happens to be hosted at Namesco, or an undocumented external-DNS DKIM setup. Publishing an SPF record does not activate DKIM, and clicking Enable does not replace checking a newly delivered message.

Confirm the email product and prerequisites

Before changing anything, establish these facts:

• The mail actually leaves through Namesco's hosted-mail service. A domain registration alone does not establish the sender.
• Authenticated SMTP is already active for the domain. Namesco describes it as a chargeable addon that is not included as standard. The DKIM article expressly requires it, even though webmail can be available without the addon.
• The domain uses Namesco authoritative nameservers. The documented nameserver set is ns0.phase8.net, ns1.phase8.net and ns2.phase8.net.
• You have authorized access to the domain's Online Control Panel, its DNS settings and an external receiving mailbox for verification.

Namesco's SMTP settings are smtp.hosts.co.uk, port 465, with SSL/TLS. Check the existing client configuration rather than changing a working route simply to match a tutorial. Authenticated SMTP explanation and activation/settings instructions.

If the account uses Microsoft 365, follow the Microsoft 365 authentication guide instead. Its tenant-issued DKIM records and activation process are different. Do not apply the Namesco mailbox SPF include merely because Namesco registered the domain.

Record the intended visible From domain, each real sending route and the current SPF, DKIM and DMARC records before making a change. Include website forms and other applications: a form using an independent relay needs that relay's authentication, not just the mailbox settings.

Check DNS authority without moving the domain

Use the current delegated nameservers to identify where DNS changes take effect. Namesco's help page shows how to inspect nameserver information through Services → Dashboard → domain → Change Nameservers → whois info. This is an inspection step, not a reason to submit a nameserver change. Nameserver-check procedure.

Save the existing records and their TTLs. Preserve MX, website records, unrelated verification TXT records, other senders' DKIM selectors and existing DMARC protection. Authentication repair should not move incoming mail, reset the zone, change DNSSEC or migrate nameservers.

An existing _domainkey NS delegation needs particular care. It may send DKIM queries to another DNS service even when Namesco hosts the parent zone. Do not delete that delegation to make the automatic setup appear to work. Identify its owner and confirm how Namesco's issued selector will be served; if the automatic workflow cannot coexist, resolve that configuration with the responsible administrators before enabling changes.

For diagnosis, an actual full lookup such as SELECTOR._domainkey.news.example.com maps to SELECTOR._domainkey.news in the parent example.com zone, SELECTOR._domainkey in a separately delegated news.example.com zone, or just SELECTOR in a delegated _domainkey.news.example.com namespace. Replace SELECTOR with the actual observed selector. This is an authority/owner mapping, not an undocumented manual Namesco issuance procedure or permission to use a new sending subdomain. Preserve the delegation and resolve conflicts with the provider before changing it. Relative DNS names.

Add or merge the Namesco SPF record

For a domain sending only through the documented Namesco mailbox service, the official example is:

v=spf1 include:spf.hosts.co.uk ~all

This is a TXT record at the mail domain's apex in the documented setup. In Namesco's DNS editor, leave Host Name blank for that apex. Do not enter @ merely because another provider uses it.

1. Sign in to the Online Control Panel.
2. Open Services → Dashboard and select the domain.
3. Scroll to the bottom of the domain page and choose DNS Settings.
4. Find the A, CNAME records etc section.
5. If a TXT policy beginning v=spf1 already exists at the required owner, edit that policy. Otherwise use an available row.
6. Set Type to TXT, use the correct Host Name, and put the complete policy in Result.
7. Choose Save, then inspect the saved record and its full DNS name.

Namesco documents these field labels and the blank apex explicitly. SPF publication steps.

For a domain with several legitimate senders, merge the necessary Namesco authorization into the existing policy before its terminal all mechanism. Preserve the other approved mechanisms and the established qualifier unless a separate policy review calls for changing them. Do not create a second SPF policy or concatenate two v=spf1 strings. Other unrelated TXT records can remain at the same owner.

Publish for the identity SPF actually checks

SPF normally evaluates the SMTP MAIL FROM domain, often visible as the Return-Path after delivery. It does not automatically evaluate the address shown in From. An SPF policy at example.com is not inherited by bounce.example.com and cannot change authorization for a provider-owned envelope domain. A null reverse path can cause SPF to use the HELO identity. SPF identity and record selection.

The reviewed Namesco instructions do not establish a configurable custom Return-Path or guarantee the envelope domain of every route. Record the actual smtp.mailfrom in trusted receiving results. Do not add more includes to the root simply because a different envelope domain is unaligned.

Keep the complete SPF evaluation within the limit of ten DNS-lookup-causing terms, including evaluated nested includes and mechanisms such as a, mx and redirect. This is not a limit of ten visible includes. Duplicate policies, invalid syntax or an excessive lookup chain can cause permerror. An all mechanism makes redirect ineffective. ~all produces softfail for unmatched senders; -all produces fail. Neither qualifier commands inbox placement or guarantees rejection. SPF processing limits.

Enable DKIM in the correct account screen

With Authenticated SMTP active and the supported DNS arrangement confirmed:

1. In the Online Control Panel, hover over Services and select Dashboard.
2. Find the correct domain and choose Manage Email.
3. Select DKIM in the left-hand menu.
4. Review the domain shown in the DKIM panel, then choose Enable.
5. Allow the automatic configuration to complete and inspect the resulting status and DNS.

The dedicated help article and its screenshots show this path. Namesco says its system updates DNS and enables DKIM for all email users on that domain. It gives an estimate of up to 48 hours for the change to take effect, including DNS propagation. Automatic DKIM setup.

There is no universal selector, manual TXT value or CNAME target to copy from that procedure. Do not manufacture a default._domainkey record, generate an unrelated key pair or copy a public key from another domain. The provider controls the signing key; the published verification data must match it. Private keys never belong in public DNS.

After enabling, use the provider's actual resulting information and the s= selector and d= signing domain on a fresh message to identify the lookup. If a selector is already occupied or the automatic operation conflicts with an existing delegation, stop rather than replacing an unknown dependency. DKIM selector and key model.

What if DNS is hosted elsewhere?

This guide's automatic workflow excludes external authoritative DNS. Namesco's current DKIM article says its nameservers are required and directs other customers to support for assistance. It does not provide an external record-export and signing-activation procedure. Do not assume copying a record from another account will enable signing, or migrate nameservers without planning the effects on the whole domain.

Preserve DMARC and choose reporting deliberately

Inspect the policy for the visible From domain and any applicable inherited policy before adding anything. Preserve existing enforcement, alignment settings and authorized reporting destinations. Do not add a child p=none policy that weakens a parent's protection or replace a working policy with a tutorial example.

Only when no direct or applicable inherited policy exists, and the domain owner approves a monitored rollout and reporting destination, a first policy can use this illustrative shape:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Replace the reporting address with an approved working destination. Publish as TXT at _dmarc.example.com; in the example.com zone the relative Host Name is _dmarc, not a blank apex field. For _dmarc.news.example.com, use _dmarc.news in the parent zone, or _dmarc in a separately delegated news.example.com zone. Check the final full owner rather than assuming an editor accepts a fully qualified name. DMARC policy specification.

When the aggregate-report destination has a different Organizational Domain from the domain where the DMARC policy was found, the report-sending receiver must verify DNS authorization for that reporting relationship at the destination. This external-authorization check is not required when both share the same Organizational Domain. Obtain the reporting provider's exact address and authorization instructions. External-destination authorization. Reports reveal sending infrastructure and authentication activity, so approve who receives them and how access and retention are handled. Do not add another organization's mailbox or enable failure reports casually. Monitoring requests reports; it does not guarantee every receiver will send them or deliver every message. Aggregate reporting and failure-reporting considerations.

Verify DNS, signing and alignment separately

The following commands are examples, not executed results. Replace example.com, actual-selector and any envelope domain with the values for the real message. Check every authoritative nameserver, not only the first:

dig +short NS example.com
dig @ns0.phase8.net TXT example.com +noall +answer
dig @ns0.phase8.net NS _domainkey.example.com +noall +answer
dig @ns0.phase8.net TXT actual-selector._domainkey.example.com +noall +answer
dig @1.1.1.1 TXT actual-selector._domainkey.example.com +noall +answer
dig @1.1.1.1 TXT _dmarc.example.com +noall +answer

Use the actual signing domain in the DKIM owner. Follow any DNS referral or selector alias to the authoritative verification data rather than treating an empty answer at the parent as proof no delegation exists. Compare authoritative results with recursive results and the old TTL. Waiting cannot repair a wrong name, failed DNS response or missing provider configuration.

Send a newly authorized message through each intended route to a controlled external mailbox whose raw source you can inspect. Check results generated by that receiving service within its trusted processing boundary. Header position or a familiar-looking authserv-id string alone does not prove an Authentication-Results field is genuine. Authentication-Results trust model.

Use the receiving service’s documented handling of externally supplied Authentication-Results, or ask its administrator to establish how those fields are removed or distinguished at that known processing boundary. Use receiver-controlled diagnostic output if provenance is unclear. Ignore attacker-inserted or otherwise untrusted results, including a forged field that names the expected receiver. Operational trust requirements.

Accept the new branded DKIM configuration only when all of these are true:

• The visible From remains the intended branded address, not a substituted provider address.
• The intended Namesco signature has the expected d= and actual s=, and the trusted receiver reports that signature as dkim=pass.
• That passing signing domain aligns with visible From under the applicable DMARC policy.
• The trusted receiver reports dmarc=pass, and you can identify the aligned passing path.

Relaxed DKIM alignment allows an organizational-domain match; strict alignment requires an exact domain match. SPF has its own relaxed or strict comparison between MAIL FROM and visible From. A child envelope domain may align in relaxed mode but fail strict alignment. A DMARC pass supplied only by SPF does not prove the intended DKIM change worked.

Inspect SPF independently. A direct-route fail or softfail calls for comparing the actual sending IP and envelope owner with authorized infrastructure. permerror calls for syntax, duplicate-policy and lookup-budget checks; temperror calls for DNS investigation. An aligned DKIM pass is not a reason to ignore these faults. Test forwarding separately, since it changes the delivery path.

Troubleshooting and safe recovery

The DKIM option is missing or Enable cannot complete. Confirm the domain, hosted-email product, active Authenticated SMTP and Namesco DNS. Do not purchase an addon or move DNS as an incidental repair; have the service owner resolve an unmet prerequisite.

The panel says enabled but no intended signature appears. Verify that the new message used the Namesco route and intended domain. Check every relevant client or application separately. Preserve the raw authentication evidence for support rather than repeatedly toggling DKIM or deleting keys.

DKIM passes but DMARC fails. Compare the passing signature's d= with visible From and the policy's alignment mode. A valid provider-domain signature does not necessarily authenticate your brand.

SPF broke after adding Namesco. Check for a second SPF TXT policy, misplaced mechanisms after all, omitted existing senders and excessive nested lookups. Restore only the faulty policy to the saved value after checking for concurrent changes.

Other mail broke during setup. Compare the saved zone with the current records. Do not reset the whole zone. Coordinate any reversal of signing or key publication so queued mail and other senders retain the verification records they need.

Documentation and testing limits

This is a documentary configuration guide. No customer account was accessed, DNS changed or email sent. Actual account controls, published records, message authentication, website rendering, indexing and inbox placement remain untested.