UK2 SPF, DKIM and DMARC setup, step by step

For UK2 StackCP hosted mailboxes using UK2’s authoritative DNS, the documented SPF template is v=spf1 include:spf.stackmail.com a mx -all. In StackCP, open DomainKeys, select the mailbox domain, choose an unused selector and click Add Signature. UK2 says it publishes the DKIM TXT automatically on its nameservers and starts signing immediately. Verify the public key and a delivered message before considering the setup complete. UK2 SPF instructions; UK2 DKIM instructions.

This guide covers an existing UK2 StackCP hosted-mailbox domain with UK2 authoritative DNS. It does not configure a VPS, another mail platform, website-generated mail using a different server, or an external-DNS DKIM deployment. Registering a domain at UK2 is not enough to establish where either its email or its DNS runs.

No customer login, DNS change or email test was performed.

Confirm the mailbox route and DNS authority first

Start with the existing, working mailbox service. In your UK2 CHI account, Shared Hosting → Manage StackCP should open the hosting environment for the intended domain. Its mailbox mail must actually leave through StackCP’s mail servers. A desktop client configured to send through another provider is a different route, even if it reads the same inbox.

Identify the authoritative DNS service and any separately delegated child zone or _domainkey namespace. UK2’s automatic DKIM publication depends on using its nameservers. Do not change nameservers to make this guide fit, and do not remove an existing delegation. If the relevant key namespace is managed elsewhere, stop before adding a signature and obtain a coordinated procedure from UK2 and that DNS owner.

The official screenshot acknowledges third-party DNS, but the reviewed instructions do not establish a complete external-DNS key-export workflow. That is a scope limit, not a claim that external DNS is unsupported.

Before changing anything, have:

• Authorized access to the correct CHI account, StackCP domain and DNS settings. The sources do not specify a universal role name or extra paid DKIM plan. Missing controls require an account-access check, not an assumed upgrade.
• An inventory of legitimate senders, including website forms, CRM systems and outbound gateways. Keep their existing authorizations until the owner approves a change.
• A saved copy of current SPF, DKIM selectors, DMARC policies, DNS owners and TTLs. Record the current sending route as well as the DNS state.
• Controlled external recipient mailboxes and a harmless message for a later test. Do not send trial messages to customers.

Keep MX, website A/AAAA records, DNSSEC and credentials unchanged. This is authentication setup for an existing route, not a mailbox migration or a security-settings reset.

Review UK2’s SPF template before publishing it

UK2 documents this TXT value:

v=spf1 include:spf.stackmail.com a mx -all

It also says new orders normally receive an SPF record by default. Check the actual authoritative zone anyway: a default at account creation does not prove that today’s record still matches today’s senders. UK2 SPF setup.

Understand what you would authorize:

• include:spf.stackmail.com uses UK2’s maintained Stackmail SPF policy rather than a manually copied list of its server addresses.
• a can authorize the domain’s resolved address records, including infrastructure serving a website rather than email.
• mx can authorize the addresses of the domain’s mail exchangers. An inbound mail server is not automatically an approved outbound sender.
• -all produces SPF fail for an otherwise unmatched source. It does not force every receiver to reject that message or guarantee delivery for matching sources.

Review the actual addresses admitted by a and mx against the approved sender inventory. Do not add them mechanically, change website or inbound-mail routing to satisfy them, or remove existing legitimate senders to fit the template. If the template and intended architecture disagree, resolve the policy with the domain owner and UK2 before saving.

SPF evaluates the SMTP MAIL FROM identity, normally reflected in the received Return-Path, rather than automatically evaluating the visible From address. Null reverse-path messages use the HELO-derived identity defined by SPF. UK2’s public setup does not establish one universal envelope-domain pattern for every message; record the actual smtp.mailfrom result during testing. A child envelope domain does not inherit the parent’s SPF policy. RFC 7208, identity selection.

At each evaluated owner, keep one TXT policy beginning v=spf1. If one exists, edit the approved policy rather than creating another. Preserve its legitimate authorizations and deliberate qualifiers. Adding an all mechanism also makes any redirect= modifier ineffective, so a redirect-based policy needs deliberate review rather than text concatenation.

Check the full evaluated SPF tree, including nested include, a, mx, exists, ptr and redirect terms as applicable. The limit is ten evaluated DNS-query-causing terms, not ten literal includes; exceeding it produces permerror. Do not “fix” the budget by replacing provider-managed includes with an unmanaged snapshot of IPs. RFC 7208 processing limits; redirect behavior.

Save SPF in the correct UK2 DNS interface

Choose one interface for the authoritative zone, not both as separate additions. These are UK2’s documented domain-apex inputs. If the account requires a record for a child domain, establish the correct zone and owner before saving; do not assume the apex instructions publish a child’s policy.

StackCP Manage DNS

1. Open CHI, select Shared Hosting, then Manage StackCP for the intended domain.
2. Under Domain Names, open Manage DNS.
3. Inspect the existing TXT records and locate the policy you reviewed. If absent, use the add-record fields near the bottom of the page.
4. For a new apex record, leave Name blank, choose TXT for Type, and enter the complete reviewed SPF value.
5. Click Update DNS. Confirm the saved owner and value, without resetting the zone or duplicating SPF.

CHI domain DNS

1. Open Domains and click Manage beside the intended domain.
2. Select Manage DNS Configuration. Confirm the nameservers and records belong to the current authoritative service.
3. In TXT Records, use Add New TXT Record only if the relevant SPF policy is absent. Otherwise update the existing policy through the available edit control.
4. For a new apex record, UK2 documents Name @, the complete SPF value, and TTL 86400, or one day.
5. Click Save and inspect the stored record.

A blank Name in the documented StackCP form and @ in the documented CHI form represent the zone apex. They are not interchangeable instructions for every DNS editor. Preserve a deliberately chosen existing TTL unless the DNS owner approves a change. A shorter TTL does not immediately remove previously cached answers. UK2’s two DNS procedures.

Enable DKIM through DomainKeys

Plan this step for a controlled change window. UK2 says signing starts immediately after Add Signature, while the newly published key still needs time to become publicly resolvable. Do not use the first enabled status as proof that receivers can already verify new mail.

Follow the documented native flow:

1. In CHI, open Shared Hosting → Manage StackCP.
2. Use StackCP’s icon search for DKIM and open DomainKeys. The screenshot labels it Domainkeys (DKIM).
3. In Add DKIM Signature, confirm the selected Domain is the actual mailbox domain.
4. Choose an unused Selector, after checking existing DNS and signing configurations. Use a simple domain-label-safe name chosen for your own change, not the screenshot’s example selector. Do not overwrite another service’s selector or a working key.
5. Click Add Signature. UK2 documents automatic TXT publication in Manage DNS when its nameservers serve the domain.
6. Inspect the domain and selector in DKIM Signatures. The official illustration shows an Enabled status. Check the corresponding generated TXT in Manage DNS, then proceed to public-DNS and message verification.

UK2 describes a 2048-bit public key. Keep the provider-generated full TXT value, including its tags and complete public-key data. Do not generate a separate key online, upload a private key or paste a screenshot key. The provider keeps the signing key; DNS contains the public verification material. UK2 DKIM workflow; DKIM key format.

The guide does not establish what every Advanced Options or Options control does. Leave unrelated settings unchanged. If the current account displays a different workflow, multiple active/default signatures, or an unexpected domain, confirm the intended signing state with UK2 rather than experimenting on production mail.

Verify the generated key at its real DNS owner

The DKIM lookup name combines the actual selector and signing domain: SELECTOR._domainkey.SIGNING-DOMAIN. Use the selected domain and generated record to establish the expected name, then reconcile it with s= and d= on a delivered signature.

For illustration only, a selector uk2check for signing domain example.com yields uk2check._domainkey.example.com. In a relative-name editor for the example.com zone, that owner is uk2check._domainkey. For signing domain mail.example.com, the relative owner is uk2check._domainkey.mail in the parent zone, or uk2check._domainkey in a separately delegated mail.example.com zone. In a separately delegated _domainkey.example.com zone, the relative owner for the first example would be uk2check.

These mappings explain the DNS name; they do not authorize moving a delegation or manually reconstructing UK2’s automatic record. A delegated namespace outside the supported automatic-publication path is a stop condition. Do not add TXT beside an existing CNAME at the same owner, remove the CNAME blindly, or alter another selector. This native procedure uses TXT, not a new proxyable CNAME, so CNAME-flattening changes are not part of it.

Use read-only lookups if appropriate. Replace every uppercase placeholder before running these examples:

dig @AUTHORITATIVE-NAMESERVER EXAMPLE-DOMAIN TXT +noall +answer
dig @AUTHORITATIVE-NAMESERVER SELECTOR._domainkey.SIGNING-DOMAIN TXT +noall +answer
dig SELECTOR._domainkey.SIGNING-DOMAIN TXT +noall +answer

Query the actual authoritative server and a recursive resolver. Expect the approved single SPF policy and the complete DKIM public TXT at the exact owner, not a duplicated domain suffix or an empty key. A long TXT may appear as adjacent quoted character strings belonging to one record; compare their concatenated value with the generated record rather than creating independent TXT records for each segment.

UK2’s DNS screenshot warns that changes can take up to 24 hours to propagate. That is guidance, not a promise that waiting alone fixes a wrong owner, delegation or key. An empty answer requires investigation. Successful DNS resolution proves publication, not live signing or alignment.

Preserve DMARC and validate the intended identities

First inspect the direct DMARC policy and any applicable inherited policy for the visible From domain. Preserve the existing policy, alignment settings and authorized report destinations. Do not downgrade a working quarantine or reject policy to make a failed UK2 test appear successful.

Only when no applicable policy exists, the domain owner approves it and someone will monitor the results, a first monitoring policy can be a single TXT value:

v=DMARC1; p=none

For visible From domain example.com, the full owner is _dmarc.example.com, normally entered as _dmarc in that zone. For mail.example.com, its direct owner is _dmarc.mail.example.com: enter _dmarc.mail in the parent example.com zone, or _dmarc in a separately delegated mail.example.com zone. Confirm the final expanded owner before saving. Do not create a duplicate record or override inherited protection casually.

This minimal example contains no report destination. Add a real, owner-approved rua destination only after its recipient and data-sharing purpose are agreed. When the Organizational Domain of the domain where the policy was discovered differs from that of the report URI’s destination host, report-generating receivers must check the DNS authorization described in RFC 9990 section 4. A destination within the same Organizational Domain is excepted; a different hostname alone is not enough to require external authorization. DNS authorization does not replace the owner’s privacy approval.

DMARC can pass through either aligned SPF or aligned DKIM. For this DKIM setup, however, acceptance requires the intended UK2 signature to pass and align with the intended, unchanged visible From, plus the trusted receiver’s dmarc=pass. A DMARC pass supplied only by SPF does not establish that DKIM works. RFC 9989 DKIM alignment.

Relaxed alignment permits the applicable Organizational Domain relationship; strict alignment requires an exact domain match. For example, a signing or envelope domain mail.example.com and From domain example.com can align under relaxed rules but not strict rules. Do not assume UK2 guarantees strict SPF alignment, a particular Return-Path, or a custom envelope setting that its setup instructions do not document. For interpretation, see raw DKIM results versus aligned DKIM policy results.

Test the actual mailbox path and troubleshoot failures

After DNS resolves correctly, send a harmless message from the intended UK2 mailbox to an authorized external test recipient. Test the actual sending clients and routes you rely on. A website form using another relay, forwarding chain or unrelated webmail service is not proof of this mailbox route.

At the receiving service, inspect its original-message view or authentication logs. Establish which results were produced inside that service’s known processing boundary and how its ingress servers handle externally supplied Authentication-Results. If that handling is unclear, use the receiver administrator’s verified logs rather than trusting a pasted header. A familiar authserv-id string or a header’s position alone can be forged. Ignore untrusted result fields. RFC 8601 security considerations.

Record the unchanged From domain, actual smtp.mailfrom, intended DKIM d= and s=, per-signature verification, alignment mode and receiver DMARC result. Keep unrelated signatures separate. Redact addresses, message content and other unnecessary personal data before sharing evidence.

• Enabled but DKIM fails: check whether the key has become resolvable, whether the selected domain and selector match the message, and whether the full generated TXT survived publication. Repeatedly adding signatures is not a repair.
• No intended signature: verify the message really used StackCP outbound servers and the correct mailbox domain. Escalate an unexplained enabled-but-unsigned route with redacted evidence.
• DKIM passes but does not align: compare d= with the original From under the actual adkim policy. A provider-rewritten From is not successful authentication of your brand.
• SPF fail: inspect the actual envelope domain and source IP against its approved policy. Do not assume the visible From’s apex record was evaluated.
• SPF temperror: investigate temporary DNS resolution problems and retry a controlled sample once resolved.
• SPF permerror: check duplicate policies, syntax, nested evaluation limits and invalid referenced policies. These remain defects even if aligned DKIM lets DMARC pass.
• Public key absent despite a DNS entry in the panel: check authority, delegation, spelling and caches. Do not change nameservers or delete NS records as a quick fix.
• Authentication passes but delivery disappoints: authentication is not an inbox-placement guarantee. Investigate the receiver’s handling and message context separately.

Keep the setup pending until the intended signature passes and aligns and the receiver reports DMARC pass. Inventory-level confidence requires checks across the relevant legitimate routes, not just one successful sample.

Roll back safely and maintain the configuration

If an SPF edit causes a regression, restore the saved, approved single policy for that exact owner. Do not reset the entire DNS zone, delete unrelated TXT records or weaken DMARC. Recheck the affected mailbox path after restoration.

Because UK2 begins signing immediately, deleting a new public key while the signer still uses it can make verification worse. Coordinate any signing rollback with UK2 and the domain owner. Preserve the key needed by messages still in transit and any other active selector; the reviewed page does not document a universal disable or rotation sequence. Do not invent one from the Options menu.

After a later provider-approved key rotation or route change, repeat the DNS, signer and delivered-message checks. Review SPF when senders or the A/MX addresses authorized by its mechanisms change. Keep the change record, redacted test results and approved rollback state together.

Sources and documentation date

No article publication or update date was displayed in the retrieved full bodies; crawl dates and a screenshot’s sample subscription expiry are not article dates. Six linked official screenshots were inspected for the account path, DomainKeys controls, enabled state and DNS forms. This was documentary review, not inspection of a customer account.

• UK2: How to add a DKIM record to your email.
• UK2: What is a SPF record and can I add one to my domain name?.
• RFC 7208: SPF, RFC 6376: DKIM, RFC 9989: DMARC, RFC 9990: aggregate reporting, and RFC 8601: Authentication-Results.