SpamTitan SPF, DKIM and DMARC setup, step by step

For SpamTitan Gateway, open the intended domain under System Setup > Mail Relay > DKIM, generate its key, publish the generated public TXT record, run Verify, then Enable signing. SPF must authorize the actual final outbound system. Complete the setup with a received-message check for branded DKIM pass and alignment plus DMARC pass. Do not mistake the documentation's separate legacy DomainKeys policy for a modern DKIM or DMARC requirement. TitanHQ Gateway DKIM procedure.

This guide is scoped to the documented Gateway workflow. It does not assume that SpamTitan Cloud, Private Cloud, Skellig or an inbound-only service exposes the same controls. Confirm your installed product and version before using it.

Confirm Gateway and the outbound path

First identify the Gateway appliance or installation, version, domain relay, administrator permissions and actual path from the source mailbox or application to an outside recipient. Record any downstream smart host, address translation, public IPv4/IPv6 egress, cluster node or failover route. The address visible inside your network may not be the address an external receiver evaluates.

TitanHQ's outbound guide describes trusted source networks, routing another mail server through SpamTitan as a smart host, and a Microsoft 365 outbound connector where applicable. Check which arrangement is already approved and working. This authentication guide is not an instruction to broaden trusted networks, change spam thresholds or create an open relay. Gateway outbound-mail configuration.

A domain listed for inbound filtering does not prove that its outbound mail traverses the Gateway. Likewise, DKIM Authentication of Inbound Mail and DMARC filtering settings evaluate incoming messages; they do not establish outbound signing for your domain. Use the Mail Relay > DKIM workflow below for this task.

Collect these prerequisites:

• Correct Gateway administrator access and the intended domain relay.
• DNS access to the authoritative zone or its legitimately delegated child zone.
• Existing SPF, active selectors, DMARC policy and a recoverable configuration snapshot.
• The intended From, envelope sender and signing domains for each sending route.
• A unique selector, key-custody owner and approved maintenance/recovery plan.
• An external test mailbox you control and representative non-confidential test content.

If your corporate sender is Microsoft 365, keep its own authentication and final-route evaluation separate. The raw DKIM versus aligned DKIM guide explains why a passing signature still needs an identity comparison. Preserve other working signatures and test whether they survive; do not treat their presence as proof that Gateway signing is enabled.

Generate and publish the Gateway DKIM key

Choose the intended domain and key settings

1. Go to System Setup > Mail Relay > DKIM.
2. Edit the intended domain relay and open DOMAIN KEY.
3. Enter a selector that does not collide with another active key.
4. Choose 2048-bit RSA where supported, rather than the shorter option, and generate the key.
5. Open OPTIONS to obtain the generated DNS TXT material.

TitanHQ lists 1024-bit and 2048-bit generation and recommends the longer key. Its optional private-key field is not a reason to place a secret in a ticket or DNS record. For a new deployment, generate the key in the approved signer; use import only as part of a deliberate key-management process. Gateway key generation. Current DKIM guidance requires rsa-sha256 and recommends at least 2048-bit RSA signing keys. RFC 8301.

Publish only the generated public value

Use the selector chosen for this domain and the full public value shown by your Gateway. The following illustrates the location, not a record to publish:

SELECTOR._domainkey.SIGNING-DOMAIN

The record type for this documented Gateway workflow is TXT. Do not copy the example public key printed in TitanHQ's documentation, invent a CNAME target, or publish a private key. Generated public-record workflow.

For a full owner such as SELECTOR._domainkey.example.com, a DNS editor managing example.com may expect just SELECTOR._domainkey. Another editor may expect the full name. Check the saved full hostname to prevent a doubled suffix. For signing domain mail.example.com, the full owner SELECTOR._domainkey.mail.example.com is SELECTOR._domainkey.mail in parent zone example.com, SELECTOR._domainkey in delegated zone mail.example.com, or SELECTOR in delegated zone _domainkey.mail.example.com. Replace the placeholder with the chosen, generated selector; do not infer a vendor-fixed key.

TitanHQ advises removing extraneous formatting from its displayed TXT material. Preserve the actual tag-value content and complete public key. DNS tools can show a long TXT record as several quoted character strings that concatenate into one logical record. That is not the same as several independent TXT records at the selector, literal formatting quotes inside the value, or spaces inserted into key bytes. DKIM TXT storage.

Do not overwrite another sender's selector. If _domainkey or a child below it is already delegated to an approved DNS service, publish through the authority for that name. Do not remove its NS delegation merely to make a parent-zone edit or verifier appear successful. No proxy or flattening change is needed for an ordinary TXT key. If an existing approved design uses a CNAME on the path, required aliases must remain DNS-only and unflattened. In Cloudflare, turn the affected record’s Flatten control off where available and ensure applicable zone-wide controls preserve the literal CNAME. Flatten-all overrides per-record settings; coordinate shared changes and do not alter unrelated website behavior. Mandatory apex or same-zone flattening may have no off switch: stop and arrange a supported design if required answers cannot be preserved. Do not remove NS delegations or change DNSSEC as a workaround. Cloudflare flattening controls and verification behavior

Separate legacy DomainKeys and testing flags

TitanHQ's Gateway page also includes a Policy Records section with a TXT record at _domainkey.example.com and values such as o=- or o=~. It explicitly describes DomainKeys, the older protocol. That is different from a modern selector public key and from a DMARC policy at _dmarc.example.com. TitanHQ policy-record section, legacy DomainKeys specification.

Do not create an o= record as a claimed modern DKIM or DMARC requirement. If your exact Gateway version or verifier demands it, pause that activation step and ask TitanHQ for version-specific guidance. Do not silently remove an existing legacy record either; first determine whether another active system still uses it. The documented selector-key, Verify and Enable controls remain distinct from that legacy question.

The Test mode option is another separate concept. TitanHQ describes it as adding t=y to the DKIM key record. It does not create a DMARC monitoring policy, prove a signature passes, or guarantee receiver acceptance. Keep any testing mode under a planned transition and verify the production state before declaring rollout complete. Gateway testing option.

On received mail, look for DKIM-Signature, not just the historical DomainKey-Signature. DMARC's signature path uses DKIM. Sharing the _domainkey DNS namespace does not make the two protocols interchangeable. DKIM signature format, DMARC authenticated identifiers.

Verify and enable signing

Once the correct TXT key is publicly available, return to the domain's OPTIONS tab and click Verify. TitanHQ describes this as retrieving the DNS value and comparing it with the configured key. After verification succeeds, click Enable to turn on DKIM signing for that domain. Verification and activation.

These are separate checkpoints:

• Generate creates key material.
• Publish makes the public key available to receivers.
• Verify checks the Gateway's view of DNS agreement.
• Enable turns on signing.
• Received-message validation proves what happened on the tested route.

Capture the active domain, selector and signing state without exposing the private key. In a cluster, check the participating nodes and failover behavior for the installed version rather than assuming one node's screen proves every path. Test after downstream disclaimers or other modifications, not only at the Gateway's input.

Configure SPF for your real egress

SPF authorizes a connecting server for an SMTP identity. Normally the evaluated domain comes from MAIL FROM, commonly reflected in the final Return-Path; it is not necessarily the visible From domain. Null-envelope messages use the HELO identity and require separate interpretation. SPF identities.

Use the actual final route to choose authorization:

TitanHQ's general authentication overview contains an example with include:_spf.titanhq.com. An example is not evidence that every customer-hosted Gateway sends from that infrastructure. Do not copy the overview's sample IP, a or mx mechanisms into your policy either. Obtain the actual egress details first. TitanHQ SPF overview and example.

Publish one SPF TXT policy per owner. Merge necessary authorization into an existing policy without erasing legitimate senders or changing its termination by accident. Any all mechanism makes redirect ignored regardless of qualifier; preserve a redirect-only policy’s intended flow rather than appending all or concatenating full policies. SPF precedence SPF permits no more than ten evaluated DNS-dependent terms across the complete dependency path, including nested includes, redirects, a, mx, ptr and exists. An ip4, ip6 or all term does not consume that DNS-dependent-term budget. A static manual copy of provider IPs is not a safe maintenance strategy. SPF DNS limits.

Preserve DMARC policy and alignment

Under current RFC 9989, DMARC passes when at least one SPF or DKIM result both passes and aligns with the visible From domain. Relaxed alignment compares Organizational Domains; strict alignment requires an exact match. For hypothetical visible From person@example.com, a passing intended d=mail.example.com signature aligns in relaxed mode (same Organizational Domain), but not strict mode; a passing d=example.com aligns in both. These are examples, not measured Gateway results. A valid signature for an unrelated relay domain does not align with your brand. DMARC specification.

Keep existing policy and reporting destinations. Inspect _dmarc at the exact From domain and applicable parent policy before creating a subdomain override. Do not weaken p=reject or p=quarantine because one gateway has a signing error. Only if no direct or applicable inherited policy exists at all, including p=none, obtain domain-owner approval of the monitoring plan before creating a first policy. It is not a replacement for an existing record.

The owner mapping matters:

For that genuinely new approved first policy, use one TXT record at the mapped owner, not @, with this complete minimal value:

v=DMARC1; p=none

This value alone does not request aggregate reports. Set rua only to a reporting destination the organization approves and monitors. When the report destination has a different Organizational Domain from the policy domain, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain is excepted; a different hostname alone does not trigger it. Obtain the reporting service’s issued authorization instead of guessing. Protocol authorization does not replace the owner’s data-sharing approval: review recipient, privacy, access and retention. Do not copy sample recipient addresses or enable potentially sensitive failure reporting with ruf without a privacy review. Aggregate-report authorization, failure-reporting safeguards.

TitanHQ's overview still shows an older percentage-based DMARC example. RFC 9989 removes pct; use the current standard rather than building a new rollout around that old example. Preserve working policy while reviewing any legacy tags with the domain's owner.

Run DNS and delivered-message acceptance tests

Public DNS checks

Replace all uppercase placeholders with actual values. These are read-only examples for the reader, not tests performed for this guide:

dig +short NS DNS-ZONE
dig @AUTHORITATIVE-NS +short TXT SELECTOR._domainkey.SIGNING-DOMAIN
dig +short TXT SELECTOR._domainkey.SIGNING-DOMAIN
dig @AUTHORITATIVE-NS +short TXT ENVELOPE-DOMAIN
dig +short TXT _dmarc.FROM-DOMAIN

Expect one complete intended public key at the selected owner, matching the Gateway-generated value, and one valid SPF policy at the actual envelope domain. Check the applicable DMARC policy, including parent inheritance when no exact-domain record exists. If DNS is delegated, query that authority. Compare authoritative answers with an independent recursive resolver.

Correct authoritative data with a stale recursive answer can be a caching issue, including negative caching. An incorrect authoritative name, truncated key or conflicting record must be corrected; waiting a fixed 72 hours is not a diagnosis.

Real-message checks

Send a harmless message from each actual source through the intended Gateway and final relay to an external mailbox you control. Keep the send time, source, Gateway log correlation, route/node and raw received headers. Repeat for materially different application, failover or content-processing paths.

Use recipient-controlled diagnostics or headers whose provenance is established by the receiving administrator's trust boundary, including documented or administrator-confirmed removal or isolation of externally supplied authentication headers, or obtain an authenticated receiver trace. A familiar authserv-id or header position alone is not proof of trust. If provenance is unclear, leave acceptance pending and obtain a provenance-established receiving-service diagnostic result rather than treating an arbitrary Authentication-Results line as evidence. RFC 8601 security guidance.

For this Gateway signing task, DMARC pass via aligned SPF alone does not complete DKIM setup. Require the intended branded DKIM pass and alignment plus trusted DMARC pass. A rewritten provider From is not successful authentication of the intended brand. Record each signature separately. Forwarding may break SPF while aligned DKIM still satisfies DMARC, but investigate real SPF errors on a direct route rather than hiding them behind DKIM success. These checks do not guarantee inbox placement or establish that a message's business content is trustworthy.

Troubleshooting, rotation and recovery

Plan rotation around real DNS caching and queued mail, not just a calendar reminder. Use a new unused selector where the supported workflow allows, publish and verify before switching, and retain the previous public key while legitimate delayed messages can still need it. Check cluster behavior for your version.

Keep a protected configuration backup and a record of the previous public DNS and signing state. If deployment fails, pause the new route or restore the last known-good key, public record and routing together through the responsible administrator. An old public key cannot validate signatures made with a different new private key. Do not delete unrelated selectors, weaken inbound filtering or relax domain-wide DMARC as a substitute for fixing the failed change.

Fictional diagnosis and handoff worksheet

Alder Instruments is a fictional engineering firm. It publishes a new selector key and obtains a successful Verify result, but leaves signing disabled until an approved maintenance window. Marking DKIM complete at this point confuses DNS agreement with active signing. The correction is to record the separate approval and Enable state, then obtain trusted received-message evidence. Neither a copied example key nor a legacy policy record substitutes for activation. This scenario describes no actual customer or executed test.

Use these blank fields for an authorized handoff. Keep passwords, private keys and message contents out of the worksheet:

• Gateway product/version, actual outbound route and domain relay:
• Selector owner, existing dependencies and generated public owner/value reference:
• Approved DNS change and private-key custody owner, without secret material:
• Legacy DomainKeys policy applicability decision for this version:
• Verify result/time and separate Enable approval/state:
• Rotation overlap, previous-selector retention and rollback owner:
• Trusted received-message signature, alignment and DMARC evidence:
• Remaining route exceptions, reviewer and release owner:

This is planning guidance, not an executed acceptance record. Current-account applicability, production-route acceptance, visual accessibility and owner release remain open.