Tricorn autobahn MTA SPF, DKIM and DMARC setup, step by step

Configure the approved SPF route, create a domain-specific DKIM selector, publish its public key, verify DNS and activate DKIM before testing autobahn MTA SMTP mail. A crucial limitation: if the submitted message already contains a DKIM-Signature header, autobahn MTA does not add its own signature. It does not validate that pre-existing signature either. [1][2]

This guide covers Tricorn autobahn MTA's SMTP relay, not autobahn for Salesforce, Kreisel or the separate message-submission API workflow. No account, SMTP connection, DNS publication or live message test was performed.

Check the route and permissions first

The SMTP manual requires prior enablement and account-issued SMTP credentials. It documents STARTTLS rather than plaintext delivery to the relay, with different production and trial hostnames. [1] Have the authorized service administrator confirm the environment and connectivity before changing sender authentication. Do not disable TLS, expose credentials in a ticket or move a production application to a trial route as a diagnostic shortcut.

The SMTP route requires a nonempty envelope sender and a valid header From. It does not relay null-reverse-path bounce messages: the documented rejection is 550 Syntax Error. A missing/invalid header From can produce 500 Valid Header From Required. Correct the authorized message construction rather than diagnosing either rejection as a DNS-authentication failure. Do not forge an envelope sender to relay a bounce. [1]

Identify the intended visible From domain, existing SPF/DMARC policies, current signing arrangements and authoritative DNS administrator. Preserve any existing selector and its key while planning a new one; queued or previously sent messages can still require old public keys.

Decide whether the upstream application already signs mail. If it does, treat the existing signature as a separate design decision. Do not remove signatures indiscriminately just to make this tutorial's route apply. Agree which system is responsible for the intended aligned signature, then test that exact design.

Understand envelope rewriting before editing SPF

SMTP MAIL FROM, the envelope identity used for bounces and SPF, is not necessarily the visible From address. The relay manual describes credential-associated matching rules that can rewrite an incoming envelope sender to a provider-controlled identity. [1] Review the actual account setting and bounce-handling requirements; do not change it simply to obtain a green SPF result.

Inspect a controlled message or the approved architecture to determine which identity is evaluated. A provider-owned envelope domain can pass SPF without aligning with your From domain. Your apex TXT record does not repair another organization's envelope domain. The branded DKIM path must therefore be verified independently rather than assumed from SPF alone. [6][7]

There is no universal Return-Path asserted in this guide. A changed bounce destination can affect delivery-failure processing and disclose data to a different system, so a route change needs explicit service-owner approval.

Configure the applicable SPF policy

The documented general authorization is _spf.autobahn.email; the service also provides an account-specific alternative on its fixed-IP settings screen for restricting authorization to allocated sending IPs. [1][5] Confirm the applicable owner and choice rather than combining both by guesswork.

Where the approved route requires the general include, the mechanism is:

include:_spf.autobahn.email

This is a mechanism, not a complete policy to paste as a separate TXT record. Merge it into the existing valid policy only at the approved evaluated owner, preserving legitimate senders and qualifiers. Do not replace an existing policy with a tutorial example or publish multiple v=spf1 policies.

Check the ten evaluated DNS-dependent-term budget, including nested evaluation. It is not a limit of ten text strings or ten includes. An existing all mechanism makes a redirect modifier ineffective; review the actual evaluation rather than appending authorizations after a terminal mechanism. [6]

The provider's SPF verification checks whether its sending addresses are authorized for the supplied domain. That check does not establish which envelope identity a received message used or prove DMARC alignment. [5] If support/account instructions and observed behavior disagree, stop and resolve that discrepancy before expanding SPF authorization.

Create the intended DKIM domain and selector

In the dashboard, use ドメイン/セレクター管理 (domain/selector management), then ドメイン/セレクター作成 (create domain/selector). Enter the approved domain and selector, select the key length, review the confirmation and submit. The provider generates the key material and exposes the public key for copying. Saved domain/selector combinations cannot be edited. [2]

Choose a new, planned selector that does not collide with an existing service. Keep the public key paired with its exact domain and selector. Only public verification material belongs in DNS; never put SMTP credentials or a private key there.

For an existing domain, creating another selector is not the same as selecting it for future signing. The API reference separately defines a default/preferred selector and notes that changes can take time to reach mail delivery. [3] Coordinate rotation rather than deleting and recreating a currently active selector.

Keep unverified API-created selectors out of production

The separate registration API has a pending parameter whose documented default permits immediate use. A deliberately staged API workflow must explicitly request pending creation, publish and verify the DNS key, then enable it. [4] Do not assume a successful registration response means DNS was checked.

This is a warning for administrators mixing dashboard and API workflows, not an instruction to run API mutations. The dashboard verification sequence below remains the primary route in this guide. Account credentials, API endpoints and defaults must be checked in the current authorized environment before any automation is implemented.

Publish the complete public DKIM record

DKIM TXT lookup uses the selector beneath _domainkey and the signing domain. [8] For illustration only, a selector studio2026 and domain mail.example.com produce:

studio2026._domainkey.mail.example.com

In the parent example.com zone, the relative owner is studio2026._domainkey.mail. In a separately delegated mail.example.com zone, it is studio2026._domainkey. In a delegated _domainkey.mail.example.com namespace, it is studio2026. These examples assume the editor appends the relevant zone suffix. Confirm that behavior and preserve any existing NS delegation.

Use the actual public key generated for your domain/selector. If the interface supplies a complete tagged DKIM TXT value, preserve that full value. If it supplies only raw public-key material, obtain the provider's expected complete TXT representation before publishing; do not paste the raw fragment alone or infer whether it already includes DKIM tags. The reviewed API examples use placeholder key text, not a deployable key. [2][4][8]

A public DKIM TXT record normally includes a valid p= public-key value and appropriate tags under the DKIM standard. Do not copy the placeholder above as a key, truncate the value or create multiple competing key records for the selector. A DNS editor may split a long TXT value into quoted character strings within one record; verify that the reconstructed record is complete.

Do not put TXT data at an owner already occupied by a CNAME. Resolve an existing alias/delegation with its administrator rather than deleting it. This documented route uses TXT verification; it is not an invitation to substitute an invented CNAME or change a web proxy setting. [9]

Verify DNS, activate DKIM and confirm the signing selector

Return to domain/selector management and use 署名検証（DNSレコード問い合わせ）, the DNS verification control for the intended pair. After SPF and DKIM validation succeed, the manual directs the administrator to DKIM有効化 (enable DKIM). [2]

Keep these stages distinct:

1. The correct public DNS record exists.
2. Provider validation succeeds for the intended domain/selector.
3. That selector is enabled and selected for the intended signing route.
4. A delivered message proves that the intended signature was added, passed and aligned.

The dedicated enable operation checks the selected domain/selector's TXT record and activates only when it is correct. The preferred-selector operation is separate. [10][3] The SMTP route uses the default selector rather than a per-message selector choice. [1] For an existing domain with multiple selectors, have the authorized administrator confirm the actual preferred selector after activation; do not assume the newly added one became preferred.

The preferred-selector reference also says that, if no preferred selector is explicitly designated for a domain, the newest registered selector is used. Creating a selector can therefore affect that fallback: plan rotation before registration, not only afterward. Selecting a selector that is already preferred returns an error; check the existing state rather than repeatedly submitting the same change. [3]

Do not repeatedly create keys or change defaults while waiting for propagation. Record the current state, investigate validation failures, and retain the previous working key until a safe rotation is complete.

The existing-signature trap

Before testing, inspect the message as it leaves the upstream application. An existing DKIM signature suppresses autobahn MTA signing, even if that signature is invalid. [1] Consequently, finding some DKIM-Signature header at the destination is not proof that the newly configured autobahn selector was used.

For a test of autobahn-generated signing, use an approved message path designed to let autobahn sign. If the architecture intentionally retains upstream signing, validate that intended upstream signature instead and do not count the test as proof of autobahn-generated DKIM. Removing a signature or changing the application route requires its own approved plan.

Verify received SPF, DKIM and DMARC results

Use a controlled recipient and the actual approved SMTP route, without sending to a customer list. Record message identifier, timestamp, environment and visible From. Avoid publishing raw headers or personal data.

Trust only receiver results established within known receiving infrastructure, with documented handling of externally supplied Authentication-Results headers. Stripping or segregating untrusted input is part of that boundary; header position and a familiar authserv-id string alone do not establish trust. [11]

Check the actual SMTP MAIL FROM domain and SPF result. For each relevant DKIM signature, keep its d= domain, s= selector and verification result together. Require the intended autobahn signature to pass and align with the intended visible From, plus a trusted receiver dmarc=pass, when validating the autobahn-branded DKIM route.

Relaxed alignment uses the same Organizational Domain; strict alignment requires an exact domain match under the applicable aspf or adkim mode. A passing but unrelated signature is not aligned. An SPF-only DMARC pass does not establish that the intended DKIM route works. [7] See raw DKIM results versus aligned DKIM policy results.

Preserve existing direct and inherited DMARC enforcement. Do not downgrade policy, add a new reporting recipient or alter inbound routing as a workaround. This guide does not change DMARC reporting destinations. Successful authentication is neither guaranteed inbox placement nor proof of safe content.

Troubleshooting

Continue diagnosing SPF defects even when aligned DKIM supplies a DMARC pass. For provider-owned identities, escalate to the provider rather than trying to repair them in your company's DNS.

Sources

1. autobahn MTA: SMTP relay email sending. Relevant full operative body reviewed in Japanese.
2. autobahn MTA: Domain/selector management.
3. autobahn MTA: Preferred signing selector.
4. autobahn MTA: Register DKIM domain/selector.
5. autobahn MTA: SPF verification.
6. RFC 7208.
7. RFC 9989.
8. RFC 6376.
9. RFC 1034, section 3.6.2.
10. autobahn MTA: Enable DKIM selector.
11. RFC 8601.

English explanations of provider controls are translations of the cited Japanese documentation, not claims about a localized English interface. No placeholder key or API sample was executed.