Teneo Enterprise SMTP Relay SPF, DKIM and DMARC setup, step by step

For an existing, approved Teneo SMTP relay domain, open that domain in the console and select Rotate key. Teneo creates a new 2048-bit key and emails its public DKIM TXT record. Publish that exact record without changing the old selector. Once Teneo’s hourly check finds the matching public key, it automatically switches signing and sends a confirmation email. Keep the old public record available for mail signed before the switch.

Publishing the new TXT record authorizes an automatic signing transition, not merely a DNS preview. Approve that transition before publication. This guide preserves your existing SMTP, SPF, envelope-sender and visible From configuration; it is not first-time relay setup. Teneo’s rotation procedure documents the issuance, hourly check and notification sequence.

Confirm the scope and prepare the change

Use this procedure only when your application already sends through the authenticated Teneo SMTP relay, the correct domain already exists in its console, and the owner has approved that route and sender identity. It covers the Belgian Teneo relay service, not an unrelated business with the same name.

It does not configure a new account, SMTP credentials, the Submission API, a different relay, a different From domain or a new return-path arrangement. Do not change the application’s server, port, encryption, credentials or mail class to perform a key rotation. Teneo’s current service page distinguishes its SMTP and API interfaces; a successful API or mailbox-webmail test would not prove the application’s existing SMTP path.

Before starting, arrange:

• Authorized access to the existing Teneo domain and its rotation notification mailbox. The public procedure establishes the domain’s Rotate key control, but not a universal role name or plan-specific permission matrix. If it is missing, confirm access and applicability with Teneo rather than changing plans or inventing a menu path.
• The DNS administrator for the authoritative zone containing the new key owner. The registrar or website host is not necessarily that administrator.
• A change record containing the old selector, full public TXT value, current DNS owners, TTLs, current signing domain and an authorized baseline message’s authentication results. Store only the evidence you are permitted to retain.
• Approval for the automatic switch after publication, a controlled acceptance method, and an owner responsible for assessing old-key retention.

Check the application’s existing route and authentication first. If its intended DKIM signature is already failing, the signing domain is unclear, or the current envelope route is unauthorized, treat that as an existing incident. Rotation is not a substitute for establishing a working configuration.

Understand what Teneo issues and what stays unchanged

Teneo generates and holds the new signing key. You receive the public TXT record by email. This workflow does not require a private key generator, private-key upload, password disclosure or an external website to generate keys.

The provider describes a fresh dated selector beginning with teneo, but that is not permission to invent the date or selector. Its homepage’s illustrative selector and abbreviated public key are not usable DNS instructions. If the rotation email is incomplete or appears to refer to a different domain or request, stop and resolve it through your established Teneo contact channel.

Start the rotation and read the first email

1. Open the existing approved domain in the Teneo console.
2. Select Rotate key once for the intended change.
3. Retrieve the notification containing the new public DKIM TXT record. Confirm the domain, new selector and complete value against this rotation.
4. Preserve the old DNS record. At this stage, Teneo says the old key continues signing; creation of a new key alone does not activate it.
5. Confirm that the DNS change is approved to trigger the subsequent automatic switch, then give the DNS administrator the complete public record.

The provider’s native procedure says the new key is 2048 bits and the emailed record is split into strings where needed. It does not establish a separate manual Activate button. Do not click Rotate repeatedly to force progress or combine record details from separate requests.

If the first email never arrives, resolve the notification or issuance problem before editing DNS. Do not reconstruct the key from a demonstration, generate your own replacement or assume the old selector should be overwritten.

Publish the new TXT record in the correct zone

Save the existing DNS configuration first. Add the new record at the authoritative DNS host for its exact owner, leaving the old selector and unrelated records intact. Rotation does not require an MX, nameserver, DNSSEC or inbound-mail change.

The following names are mapping examples, not publishable Teneo records. Replace ISSUED_SELECTOR with the actual selector and use the actual signing domain from the approved issuance.

If the editor expects the full name, use the full owner instead. Inspect the saved result to prevent an accidentally doubled suffix such as .example.com.example.com. Preserve existing _domainkey NS delegations: publish in the delegated zone through its authorized administrator, not in an ignored parent-zone copy.

If the new owner already contains a CNAME or another service’s data, stop and reconcile ownership with the DNS administrator and Teneo. Do not delete it or add conflicting TXT alongside a CNAME. This is a native TXT workflow; HTTP proxy and CNAME-flattening changes are not substitutes for the required TXT record.

Keep a long key in one logical TXT record

A 2048-bit public key can require multiple DNS character strings. Follow your DNS editor’s supported long-TXT entry format while preserving the complete logical value from the email. Do not create a separate TXT record for each chunk, add spaces inside the key, paste an ellipsis, or include display quotation marks as literal key data.

A DNS lookup may show several quoted strings in one TXT record. They must concatenate without intervening whitespace to the exact issued value. Multiple DKIM TXT records at the same selector are not the same thing. RFC 6376 sections 3.6.2.1–3.6.2.2 define the namespace, concatenation and unique-record requirement.

After saving, compare the returned complete tagged record and, specifically, its p= key with the issuance. An empty p= revokes a key; it is not a successful publication or a harmless placeholder.

Separate DNS visibility from the automatic signing switch

Teneo checks the new record every hour and compares its returned p= value with the key it created. Only an exact match triggers the documented switch. It then reads back the signing configuration and sends a second email confirming the new selector and a date seven days out for retirement of the old relay key.

The source’s example of one rotation taking 69 minutes is an observation, not a service-level promise. Authoritative DNS publication, recursive caches and the next hourly check are separate events. A resolver may also retain an earlier negative answer.

Use read-only DNS inspection to diagnose visibility. These are placeholders for an administrator with dig; they neither change DNS nor send mail:

dig @AUTHORITATIVE_NS ISSUED_SELECTOR._domainkey.SIGNING_DOMAIN TXT
dig @APPROVED_RECURSIVE_RESOLVER ISSUED_SELECTOR._domainkey.SIGNING_DOMAIN TXT

Replace the server and owner placeholders with approved real values. Compare authoritative answers and your approved recursive resolver’s answer with the complete issued record. An empty answer, timeout, old cached result or different key is not success. Avoid uploading full message headers or account information to a public checker merely to investigate DNS.

If DNS is correct but the switch notice is missing, check the actual issuance and elapsed checker interval, then coordinate with Teneo. Do not remove the working old record, change SPF or weaken DMARC to make the rotation appear complete.

Keep SPF and DMARC stable during rotation

A DKIM key rotation changes the key used for a signature, not automatically the visible From, SMTP envelope or SPF owner. Determine SPF’s evaluated identity from the actual SMTP MAIL FROM used on this route, ordinarily recorded in a delivered message’s Return-Path; HELO applies in the relevant cases, including a null reverse-path. Do not infer it solely from visible From.

Teneo’s homepage publishes an SPF example containing include:servers.belgium.teneo.be. That is useful service context, not an instruction to paste a new apex policy during rotation. This guide assumes the existing approved SPF configuration. If it needs repair, review the actual evaluated owner and authorized senders separately.

At that owner, retain one v=spf1 TXT policy, existing legitimate authorizations and their qualifiers. The limit concerns 10 evaluated DNS-dependent terms, including nested evaluation, not simply ten written includes. An all mechanism causes redirect to be ignored. Do not change the final qualifier merely to match a homepage example, and do not promise delivery or rejection solely from that qualifier. RFC 7208 governs these SPF rules.

Preserve the effective direct or inherited DMARC policy, strict-alignment settings and approved report destinations. Do not add a second policy, weaken enforcement to p=none, or introduce a child override as a rotation workaround. First-time DMARC deployment and new report sharing are outside this existing-route procedure; if the authentication baseline is missing, resolve that separately before claiming completion.

For DKIM alignment, compare the actual signing d= domain with the visible From domain. Relaxed alignment uses the same Organizational Domain; strict alignment requires an exact domain match. SPF alignment compares its authenticated envelope identity with From under its own alignment setting. A child envelope domain does not automatically satisfy strict alignment. These are current DMARC rules in RFC 9989, not a reason to change the route during rotation.

Verify an actual message from the unchanged SMTP route

After the switch confirmation, use a fresh, authorized message from the intended application through its existing authenticated Teneo SMTP path. Use an approved synthetic test workflow with all recipients controlled by the organization, or inspect an authorized recent message generated after the switch. Do not create real orders, invoices, password resets, customer notifications or business events solely to test DKIM. Check hidden recipients, forwarding and downstream automations before a synthetic send.

If no safe native test exists, coordinate acceptance with the application owner and Teneo. A DNS lookup, a local sample header, a console notice or a message sent through a different interface cannot substitute for that evidence.

For the received message:

1. Confirm the intended visible From address and actual application/relay route. A rewritten provider From is not proof of your intended branded authentication.
2. Ask the receiving administrator to identify results produced within that service’s known processing boundary, using its documented treatment of externally supplied Authentication-Results and, where available, receiver-side trace evidence. A familiar authserv-id string or header position alone is not trustworthy. Ignore injected or otherwise untrusted result fields. RFC 8601 explains this trust boundary.
3. Locate the intended Teneo signature and keep its d=, s= and verification result together. Require the new issued selector, the intended signing domain and a receiver-generated dkim=pass for that signature.
4. Require that signature to align with the intended visible From under the current policy, and require trusted dmarc=pass. DMARC passing through SPF alone does not prove the rotated DKIM signature works.
5. Record the actual MAIL FROM/SPF identity and SPF result separately. Investigate fail, temperror and permerror even when aligned DKIM permits DMARC to pass.

An old message may legitimately carry the old selector because it was signed or queued before the switch. Test a newly generated message and keep both public keys available during the overlap. With multiple signatures, do not mistake a different provider’s passing signature for the new Teneo one. EmailAuth’s guide to raw DKIM results versus aligned DKIM policy results explains that distinction.

Keep the minimum approved evidence: message time, route, intended From, new selector/signing domain, receiver results and the corresponding Teneo switch notice. Do not publish message contents or private account data in a troubleshooting ticket unnecessarily.

Retire the old relay key without breaking delayed mail

Teneo’s second email gives a date seven days out; its third email reports that the old key has been removed from the relay. Those notifications do not prove that every message signed with that key has finished travelling or being verified.

Keep the old public DNS record unchanged through the stated overlap and until the mail owner has assessed delayed queues, deferred validation and any shared use. The source’s generic rotation discussion recommends revocation, while its native-relay section says the old DNS record may remain. Neither should be read as permission to blank p= or delete the record automatically on day seven.

RFC 6376 sections 3.1 and 5.2 explain concurrent selectors and retention for a reasonable validation interval. Revoking or removing the old public key prevents later validation against it; retaining a public key does not itself let anyone sign without the private key. Decide eventual retirement separately with the owner, retaining evidence of the last relevant signing and delivery activity. Do not reuse the old selector for a different key.

A suspected private-key compromise is a different incident with competing risks. Escalate through the approved security process rather than following a routine overlap schedule or exposing key material here.

Troubleshoot and recover safely

Before publication, leaving the new record unpublished leaves the documented old signer in use. If you need to cancel a pending rotation, contact Teneo through the approved process; the public source does not establish a Cancel control.

After publication, do not assume you can prevent the switch by deleting the new record. The hourly match may already have occurred. If the new path fails, pause affected sending through the application owner’s approved operational process and coordinate recovery with Teneo. Preserve both public records and the notices. Do not rotate again, force a selector rollback, revoke keys, change credentials or weaken policy as an improvised recovery method.

Sources and verification limits

Protocol references above govern TXT handling, key retention, SPF, alignment and receiver-result trust where generalized source advice is incomplete.

This is a documentary guide. No customer account was opened, DNS or relay setting changed, message sent, or live authentication result certified during its preparation. Actual completion requires your approved implementation, Teneo’s switch confirmation and controlled native-message acceptance.