Restrict the instructions to SpamTitan Gateway signing
TitanHQ publishes a specific Configuring DKIM in SpamTitan Gateway procedure. This article follows that product boundary. It does not assume that SpamTitan Cloud, Skellig, an inbound-only deployment or every managed-service edition exposes the same controls. Confirm the installed version, licensed capabilities and actual outbound route before approving a signing change. A domain listed for receiving mail is not, by itself, evidence that outgoing messages traverse the gateway or receive a customer-domain signature.
The Gateway procedure contains both DKIM signing steps and a separate legacy DomainKeys policy-record discussion. That mixture is an important implementation boundary. The modern signature-key workflow can be explained from the source, but the legacy policy step requires present-product confirmation. Do not silently convert old DomainKeys terminology into a DMARC requirement or claim that publishing an o= policy establishes modern domain protection.
Identify the domain relay and key ownership
The documented navigation is System Setup, Mail Relay, DKIM. The page lists domain relays. Edit the intended domain and open the DOMAIN KEY tab. The procedure asks for a selector name that distinguishes this key from other domain keys. Choose a label through the organization's approved naming process and check existing use before publishing it. A predictable label is not a secret, but reusing an occupied selector can overwrite a dependency that another sender still needs.
The source describes generating a new key pair and also offers an existing-private-key field. This guide does not request, collect or recommend copying a private key into a ticket or shared document. Key generation or import is a separate authorized administrative action. The guide lists 1024-bit and 2048-bit options and recommends the longer choice. Confirm the supported configuration and current cryptographic requirements for the deployed product; do not downgrade merely because a DNS editor displays a long public value inconveniently.
Publish the generated public key without copying the example
After Generate, the source directs the administrator to the OPTIONS tab and the DNS TXT material. Publish the actual public key at the name formed from the selected selector, _domainkey and the signing domain. The large public key printed in the documentation is an illustration, not a reusable record. Record the chosen owner and a controlled reference to the issued public value in the change request. No private material belongs in public DNS.
TitanHQ discusses removing extraneous formatting from the copied display. Interpret this as handling the editor's presentation, not arbitrary editing of key bytes. RFC 6376, section 3.6.2.2 specifies TXT resource records for key storage. A DNS tool may display multiple quoted strings within a single TXT record; that is different from multiple competing records or literal quotation marks inserted into the value. Have the DNS administrator verify the actual logical record and complete owner name rather than accepting a screenshot of an input box as final evidence.
Keep legacy policy and test mode separate from DMARC
The provider procedure also describes a TXT record at _domainkey followed by the domain, with o=- or o=~ values, under Policy Records. It explicitly calls this DomainKeys policy. This is not the DMARC policy location and is not a replacement for a DKIM selector public key. Because the procedure combines these historical elements, confirm whether that policy step is applicable to the exact current Gateway version before adding it. Preserve the unresolved question in the release record rather than inventing a modern requirement.
The guide separately describes a DKIM testing flag, t=y, in the key record. Do not confuse that with an instruction to place a DMARC deployment into testing mode or with proof that recipients will accept all mail. DKIM, DMARC and local receiver handling have distinct semantics. RFC 9989, section 4.4 explains the alignment required between a passing authentication identity and the author domain. A legacy policy statement that mail is signed does not establish that a particular signature validates or aligns.
Verify before enabling and plan rotation deliberately
TitanHQ's OPTIONS workflow uses Verify to retrieve the DNS TXT record and compare it with the gateway's configured information. Once verification succeeds, Enable activates DKIM signing for the domain. Treat these as separate checkpoints. A published key does not prove signing is enabled, while a selected signing option cannot make a missing or mismatched public record validate. Preserve the verification result and its time without describing it as a receiver acceptance test.
The documentation recommends periodic key rotation. A practical rotation plan needs more than a calendar interval: identify active selectors, generated keys, queued messages, DNS caching, authorized operators and rollback conditions. Do not delete the previous public record simply because a replacement key was generated. Determine what overlap the actual mail path needs, and retain the evidence supporting that decision. This manuscript has not measured queue lifetimes or tested the installed product's transition behavior, so those implementation details remain open.
Check the final outbound message rather than the filtering label
A separately authorized acceptance exercise should distinguish gateway transit, signing, validation and alignment. Review the signature's d= and s= fields, the visible author domain and trusted receiver authentication results. RFC 6376, section 3.5 defines the signature fields. Check message classes that may take different paths, such as ordinary mailbox mail, application notifications and forwarded traffic. The fact that an incoming message was scanned by SpamTitan says nothing conclusive about how an outgoing application message was signed.
SPF is a separate review. RFC 7208, sections 2.4 and 4.6.4 describe its MAIL FROM identity and DNS-dependent evaluation limits. This source does not provide a universal outbound SPF include for every SpamTitan deployment, so none is invented here. Obtain the actual authorized sending infrastructure and review one complete policy for that identity. Authentication success remains distinct from inbox placement, content safety or recipient approval of a payment request.
Fictional diagnosis and blank acceptance worksheet
A fictional engineering firm, Alder Instruments, publishes a new selector key but leaves signing disabled while waiting for a maintenance window. Its internal checklist marks DKIM complete because Verify succeeded. A later review finds that the checklist conflated DNS agreement with active signing. The proposed correction is to separate the approval to enable, the observed configuration state and the future receiver evidence. It is not to publish the documentation's example key or add a legacy policy record as a substitute. No actual system, message or DNS lookup underlies this scenario.
- Gateway product, version, outbound route and domain relay: ______
- Selector ownership and existing dependencies: ______
- Generated public owner/value reference and approved DNS change: ______
- Private-key custody decision, without secret material: ______
- Legacy DomainKeys policy applicability decision: ______
- Verify result and subsequent Enable approval/state: ______
- Rotation overlap, rollback and previous-selector retention: ______
- Trusted received-message signature and alignment evidence: ______
- Remaining exceptions, reviewer and release owner: ______
Original implementation evidence, current source applicability, human subject-matter review, production-route acceptance, visual accessibility and owner release remain open. No key was generated, setting changed, DNS record published or message sent. The catalogue's broader implementation requirement cannot be marked complete from this documentary workflow alone.