Blacknight Solutions SPF, DKIM and DMARC setup, step by step

For an existing Blacknight Titan mailbox domain, Titan documents the SPF TXT policy v=spf1 include:spf.titan.email ~all. Obtain your unique DKIM TXT record through Blacknight’s Titan subscription, publish it at the domain’s authoritative DNS provider, and run the account’s verification. Titan says outgoing messages are signed automatically after the record is verified. A DNS record or dashboard status alone does not prove branded DMARC alignment. Blacknight DKIM instructions; Titan SPF instructions.

This guide covers Blacknight Titan custom-domain mailboxes already configured and approved to receive mail through Titan. It supports Blacknight-hosted or external authoritative DNS. It does not migrate mailboxes, move inbound mail, configure legacy mail.blacknight.com service, or treat Titan as an outbound relay for a domain whose inboxes remain elsewhere.

No account configuration, DNS change or live email test was performed.

Confirm that this is the Blacknight Titan route

Use Blacknight’s current control panel at cp.blacknighthosting.com, not the older cp.blacknight.com interface. Identify the actual Titan subscription and domain. Blacknight’s migration article distinguishes its old qmail, Minimus, Medius, Maximus and email-only/OX services from Titan. A hosting-plan name or an old mailbox login does not establish that the current route is Titan. Blacknight platform and migration distinctions.

Titan’s MX and SPF prerequisites matter. Blacknight says a domain without the required Titan MX and SPF configuration cannot send through Titan. If the domain’s MX points to another mail provider, stop and resolve the intended architecture with the mailbox owner and Blacknight. Do not replace working MX records just to complete an outbound-authentication tutorial. Inbound migration, mailbox retention and user cutover need a separate approved plan.

For a migrated account, confirm completion and the current mailbox settings. Blacknight identifies app.titan.email as its Titan webmail destination; use the account’s assigned settings for an email client. Do not keep testing through a legacy server because it temporarily still accepts a connection.

Before proceeding, have authorized access to:

• The Blacknight account and the correct Titan subscription’s administration interface.
• The DNS editor that actually serves the domain and any delegated DKIM namespace.
• The existing sender inventory, SPF policy, DKIM selectors and direct or inherited DMARC policy.
• Controlled external recipient mailboxes for a later harmless test.

The reviewed instructions do not specify a universal administrator role name or a paid-plan prerequisite for this DKIM procedure. If the subscription interface is absent, confirm access and eligibility rather than granting broader permissions or buying an upgrade by assumption.

Blacknight also offers Microsoft 365. If that is the actual sender, use the separate Microsoft 365 SPF and DKIM guide, not Titan’s record values. Other Titan resellers have different account workflows and may supply different record types; their instructions do not replace Blacknight’s.

Review the current SPF policy and the actual envelope domain

Titan’s documented template is:

v=spf1 include:spf.titan.email ~all

Its setup page specifies a TXT record, a domain-apex host represented as @ or blank depending on the editor, and a 3,600-second TTL. These are documented starting values, not a direction to overwrite an existing policy. Titan SPF setup.

SPF evaluates the SMTP MAIL FROM domain, normally represented in the received Return-Path, not automatically the visible From address. HELO handling applies for a null reverse-path. Check the receiving system’s actual smtp.mailfrom identity. The public instructions do not guarantee one envelope-domain pattern for every Blacknight Titan message. SPF identity selection.

At the evaluated owner:

• Keep one TXT policy beginning v=spf1. A second independent SPF policy can cause permerror.
• If other legitimate services send using that owner, merge the required Titan mechanism into the approved existing policy. Do not publish the entire template as an additional record.
• Preserve deliberate qualifiers. ~all means softfail for an unmatched source; it does not guarantee acceptance, rejection or inbox delivery. Do not change a working -all or another approved ending merely to match the template.
• Check redirect= before editing. Adding an all mechanism makes that redirect ineffective.
• If the existing policy includes a or mx, inspect the addresses it authorizes and confirm they are intended senders. The Titan template does not require adding those mechanisms. Do not change website addresses or inbound MX records to manipulate SPF authorization.

SPF has a limit of ten evaluated DNS-query-causing terms, including nested processing. This is not “ten includes.” Audit the full tree, including a, mx, include and redirect as applicable, before adding another service. A child envelope domain needs its own applicable policy; SPF does not inherit the apex policy automatically. SPF processing limits; redirect behavior.

Blacknight’s generic SPF article still mentions its older panel and does not give the current Titan mechanism. Use the Titan-specific source above for this route, while preserving the domain’s real sending inventory.

Obtain DKIM from the correct Titan subscription

Blacknight documents this path:

1. Sign in to cp.blacknighthosting.com.
2. Open Services → My Services.
3. Select the correct Titan email subscription. Use the subscription search if necessary.
4. On Product Details, locate the Titan administration interface.
5. Open Email reputation.
6. Select Add in the DKIM entry. The expanded instructions expose a unique record generated for your account.

Blacknight notes that the embedded administration interface may require a mobile browser’s desktop-site view. Its linked Titan documentation also specifically identifies manage-euc1.titan.email as the Blacknight control-panel destination. Use the intended account, not a different region or reseller’s dashboard. Blacknight issuance procedure; linked Titan DKIM procedure.

Copy both DNS Host Name and TXT Record Value from the selected domain’s current output. Preserve the complete tagged value, including v=DKIM1, k=rsa and the entire p= public key. The screenshot’s titan1._domainkey is an illustration, not permission to assume that selector or reuse its key for your account.

Titan keeps the private signing key. You need only the public DNS record. Do not upload a private key to a checker, send it to a DNS administrator, or generate your own replacement outside Titan’s documented workflow.

The interface includes Generate New Key. That is not a routine “refresh” button. Keep a working key and selector; coordinate any actual replacement with the provider and all dependent sending paths before touching it.

Publish at the authoritative DNS provider

Check which nameservers and delegated zones answer for the record, not just where the domain was purchased. Blacknight’s DKIM instructions explicitly support publication at another DNS provider. A correct record saved in a non-authoritative panel has no public effect.

For Blacknight’s current DNS service using ns1–4.blacknightdns.com, the documented path is Domains → Manage DNS → Edit Zone (pencil icon), then the record’s Edit Record control. The current panel uses @ for a record on the domain itself. Use its TXT record fields for the approved SPF change and the exact issued DKIM owner/value. Check the saved full owner. Blacknight DNS editor and platform distinctions.

For external DNS, use that provider’s TXT editor and owner-name convention. This guide does not require moving nameservers to Blacknight. Do not follow the legacy panel’s Remove Hosting suggestions to unlock a DNS control: Blacknight warns that these can remove files, databases, email accounts or their contents. Escalate an access mismatch instead.

Map the owner without duplicating the domain

Use the selector actually issued by Titan. In these mapping examples, SELECTOR is a placeholder, not a value to publish:

• For signing domain example.com, the full owner is SELECTOR._domainkey.example.com. A relative-name editor in the parent zone uses SELECTOR._domainkey.
• For an actually configured signing domain news.example.com, the full owner is SELECTOR._domainkey.news.example.com. Its relative owner is SELECTOR._domainkey.news in the example.com zone, or SELECTOR._domainkey in a separately delegated news.example.com zone.
• In an existing delegated _domainkey.example.com zone, the relative selector owner is just SELECTOR. The same rule applies inside _domainkey.news.example.com for that signing domain. Preserve the delegation and publish through its actual authority; do not delete NS records or put an ineffective copy in the parent.
• An SPF policy for example.com is at its apex. For an actual envelope domain news.example.com, it is at news in the parent zone, or the child zone’s apex. Confirm whether the editor wants a full name, blank or @.

Keep other services’ selectors and ordinary verification TXT records. If the exact selector owner already belongs to another service, or contains a CNAME, stop and reconcile it before adding TXT. Multiple independent DKIM public-key records at one selector are not a safe way to share that name. DKIM key lookup.

This Blacknight Titan procedure uses a TXT public key. It does not require DKIM CNAMEs, HTTP proxy settings or CNAME-flattening changes. Do not substitute a two-CNAME recipe from a different Titan reseller.

Verify the record in Titan and confirm signing

After authoritative DNS contains the correct public key, return to Email reputation. Blacknight documents Check Again to verify the record. The current linked Titan walkthrough also shows I’ve added TXT records in my DNS control panel → Verify changes, followed by a Verified result. Follow the controls presented by your actual embedded interface; these are documented interface variants, not a requirement to invent an extra verification step. Blacknight verification; Titan verification and automatic signing.

Titan states that outgoing mail is signed automatically once the record is verified. There is no separate signing toggle documented in this procedure. If verification fails, compare the issued host and full value with the authoritative answer before generating anything new.

Allow for the prior TTL and cached answers. Titan’s current prose mentions up to six hours in some cases, while its screenshot mentions up to 24 hours. Neither is evidence that your record is correct or a guaranteed completion time. Check DNS and account status rather than repeatedly replacing a correct record while caches expire.

Use read-only queries such as these, replacing all fictional names and SELECTOR with the actual values:

dig NS example.com
dig @ns1.example.net TXT example.com
dig @ns1.example.net TXT SELECTOR._domainkey.example.com
dig TXT example.com
dig TXT SELECTOR._domainkey.example.com
dig TXT _dmarc.example.com

Query the authority serving each owner, including a delegated namespace where relevant, then compare a recursive resolver. Expect one applicable SPF policy and the exact issued public DKIM record. Several quoted character strings can form one TXT resource record; they are concatenated for interpretation. They are not automatically duplicate keys or separate SPF policies. These are inspection examples, not live results.

Require a trusted branded message result

After verification, send a new message through each actually used in-scope Titan mailbox route, such as webmail and the configured email client. Use harmless synthetic content and controlled, valid external recipient mailboxes. Do not test on customers, real campaigns or another person’s inbox without authorization. Do not rely solely on an internal message.

At the receiving service, inspect the original raw message. Establish which Authentication-Results fields were generated inside that service’s known processing boundary, and how it handles externally supplied result fields. Use the receiver’s documentation or administrator if uncertain. An attacker can insert a familiar authserv-id; its spelling or a header’s position alone is not proof. Ignore untrusted external results. Authentication-Results security requirements.

Record:

• The unchanged approved branded From domain.
• The connecting IP, actual smtp.mailfrom identity and SPF result.
• The intended Titan signature’s d= signing domain and s= selector, matched to the account output.
• The receiver’s result for that signature and its DMARC result for the visible From.

Acceptance requires the intended signature to pass DKIM and align with the intended branded From, plus a trusted dmarc=pass. A passing unrelated signature, a rewritten provider From or DMARC passing through SPF alone does not validate this custom-DKIM setup.

Relaxed alignment permits a shared Organizational Domain; strict alignment requires identical domains for the mechanism being evaluated. DKIM uses d= under adkim, while SPF uses its authenticated envelope identity under aspf. Do not infer strict alignment from a child domain or assume a universal Titan Return-Path. An unrelated provider-owned envelope cannot be made aligned by adding more mechanisms to the brand’s apex SPF. Current DMARC alignment rules.

Assess SPF independently even when aligned DKIM passes DMARC. Preserve evidence for each route rather than treating one successful webmail message as proof that every client or application works.

Preserve DMARC and choose report recipients deliberately

Inspect the exact From domain’s DMARC policy and any applicable inherited policy before publishing a new record. Preserve existing settings, including an existing p=none, alignment modes and authorized report destinations. Do not replace an inherited policy with a weaker child override to satisfy a setup example.

Only if no applicable direct or inherited policy exists, and the domain owner approves a first monitoring policy with an assigned review plan, a minimal initial TXT value is:

v=DMARC1; p=none

For example.com, the full owner is _dmarc.example.com, relative _dmarc in that zone. For news.example.com, use _dmarc.news.example.com, relative _dmarc.news in the parent zone or _dmarc in a separately delegated child zone. Publish one policy. This value requests neither enforcement nor aggregate reports; configure and approve a real rua destination before adding one. DMARC policy discovery.

If the report destination is in a different Organizational Domain from the domain where the policy was found, the report-generating receiver must check DNS authorization for that destination. A destination within the same Organizational Domain as the policy domain is excepted. A different hostname alone does not make it external. Have the report receiver establish the required authorization. Reporting authorization, RFC 9990 section 4.

That protocol check is separate from the owner’s permission to share reports. Approve recipients, access and retention because aggregate reports disclose sending activity. Do not copy a third party’s report address or add forensic reporting casually.

Domain-wide enforcement needs a separate all-route review, including forwarding and mailing lists. RFC 9989 requires domains publishing p=reject not to rely solely on SPF and to apply valid DKIM signatures, while warning about indirect-mail interoperability. One verified Titan domain is not sufficient evidence to tighten the entire organization’s policy. Interoperability requirements.

Troubleshoot and recover without replacing working dependencies

Titan refuses to send: confirm the actual Titan subscription, current client route, and its required existing MX/SPF setup. If the domain belongs to another inbound provider, escalate the architecture decision. Do not migrate the inbox by editing MX as a quick fix.

DKIM is Unverified or the public key is missing: check the authoritative nameservers, full owner, auto-appended suffix, delegation and complete TXT value. Titan specifically documents missing-key, invalid-key-format and multiple-TXT-at-one-selector errors. Restore the exact issued public record, then run verification again. Titan DKIM errors.

Verified but DKIM fails in a message: confirm the message actually used the intended Titan route and signature. Check whether a gateway changed signed content. Compare d= and s= with the published key. Do not assume a green DNS status proves the message was signed correctly.

SPF fail or softfail: inspect the actual connecting source, envelope owner and sender authorization. None or neutral: inspect the evaluated owner and policy; these are not SPF passes. Permerror: check duplicates, syntax and the nested evaluated-term budget. Temperror: investigate DNS availability/resolution and retest before changing a correct policy. Keep these diagnoses separate from DKIM and DMARC.

Authentication passes but DMARC fails: compare the authenticated identities with the unchanged From under the effective alignment modes. Resolve the route or signing identity with Blacknight rather than weakening policy.

Before rollout, agree with the mailbox and DNS owners who may pause affected sending, restore exact approved prior records, or coordinate account-side recovery. Preserve concurrent changes, other services’ selectors, shared dependencies and keys still needed by queued messages. Do not regenerate a key or retire an old one without an agreed transition.

Save the issued record, original and final DNS, verification state, TTL/change timestamps and controlled message evidence. Retest after restoration, plan or account changes, migration, route changes and key rotation. No troubleshooting step here authorizes changes to MX, nameservers, DNSSEC, credentials or unrelated services.

Sources and verification limits

The primary Blacknight sources are Adding DKIM records for Titan Email; its legacy-to-Titan migration distinctions; and its current versus legacy DNS editor guide. The linked Titan DKIM and SPF procedures were also read; their current bodies did not establish publication or update dates. Six actual setup and verification images were inspected.

This is documentary guidance, not a tested customer deployment. Actual eligibility, records, account status, received headers and production behavior remain checks for the authorized operator.