Confirm TransIP is authoritative
This is a DNS publishing guide, not a TransIP mail-service onboarding guide. A domain can be registered at TransIP while its authoritative nameservers are elsewhere. Check the domain's public delegation and identify the authoritative zone before editing. Do not switch nameservers just to make a DNS form accessible. Obtain the sender's exact record names, types and values, together with the existing zone export and an approved change scope.
Enter names and values correctly
Select the domain in the control panel and open DNS settings. Custom editing requires the automatic TransIP settings to be off. Re-enabling those settings can overwrite custom records and nameservers. The Name field uses @ for the zone apex and relative names for subdomains. An external CNAME target needs its full name and trailing dot. These interface rules are documented in the TransIP control-panel source below.
For a TXT DKIM key, the DKIM source instructs users to omit surrounding quotation marks and unnecessary backslashes. Use the sender's public key, never a generated sample. A selector on a sending subdomain needs that subdomain in the relative owner name. Use CNAME only when the sender actually issued a CNAME delegation. Publishing a key does not make a sending service start signing.
Original record-mapping worksheet
The following is a fictional mapping exercise for the example.org zone, not a production configuration. A full DKIM owner review._domainkey.news.example.org maps to review._domainkey.news in the Name field. A DMARC owner _dmarc.news.example.org maps to _dmarc.news. The SPF owner news.example.org maps to news. Mark the expected full name on the change ticket so a reviewer can detect an accidental example.org.example.org suffix.
Keep SPF and DMARC as TXT policies at their correct owner names. Do not put a full zone-file line, including class and type, into the Value field. Multiple TXT records can coexist for unrelated purposes, but two SPF policies at one evaluated name are not valid. Long DKIM values require careful handling: the retrieved TransIP pages do not establish a universal long-string splitting procedure. If the panel rejects the provider's full value, stop and obtain current TransIP guidance rather than truncating it.
Verify the publication before testing mail
Query each authoritative server for the full SPF, DMARC and selector names. Compare complete values, including concatenated TXT strings where returned. For a delegated key, verify the CNAME target and final TXT answer. Repeat through a recursive resolver and retain TTL observations. A correct control-panel display with an absent public answer can indicate wrong authority or unsaved data, not merely slow propagation.
Only then trigger a controlled message through the sending service. DNS-side rollback should restore the changed records, not re-enable automatic settings or restore an entire old zone without comparing unrelated changes.
Prove the identity at the receiver
Use a controlled external mailbox and send through the production workflow, with harmless content and no customer data. Save the raw message, timestamp and the receiving system's Authentication-Results. Ignore authentication assertions inserted by an untrusted sender. Record the visible From domain, Return-Path or authenticated envelope identity, and every DKIM d= and s= pair. A display name or Reply-To address is not the DMARC identity.
SPF pass authorizes the connecting server for the evaluated envelope identity. DKIM pass validates a signature for its signing domain. DMARC needs a passing method whose domain aligns with the visible From: strict alignment requires the same domain; relaxed alignment permits the applicable organizational-domain relationship. A provider-owned signature can pass without authenticating your visible From. One passing aligned DKIM signature can satisfy DMARC even when another signature fails. These protocol rules come from RFC 7208, RFC 6376 and RFC 9989, listed below.
Check authoritative DNS before diagnosing caches. Ask an authoritative server for the exact name and type, then compare a recursive resolver after its cached lifetime. For DKIM, follow any CNAME to its public-key TXT response. Never publish a private key. Keep one SPF policy at each evaluated name and check the ten DNS-lookup-causing-term limit across nested includes. Do not replace a shared SPF policy with a provider example.
Recovery and acceptance
Pause the affected workflow if tests show a new regression. Compare the changed record with the saved version and undo only that change after checking other senders. Recheck DNS and resend after recovery; reverting a value does not flush every resolver immediately. Keep old DKIM verification records available while previously signed messages may still be in transit, unless a security incident requires revocation.
Accept the change only when DNS, application state and a real received message agree. Record the flow owner, evidence timestamp and next review trigger. Inbox placement alone is not proof of authentication, and successful authentication does not guarantee inbox placement. Do not tighten a shared domain's DMARC policy on the strength of one provider's test. Inventory the other legitimate sources first.
Diagnose a correct-looking entry in the wrong zone
Written case TI-01 assumes the domain is registered at TransIP, but its public delegation points to another DNS operator. A saved TransIP panel entry for review._domainkey.news does not establish publication at review._domainkey.news.example.org. The domain owner must confirm the authoritative operator and arrange the approved record there; changing nameservers or enabling automatic settings is not the corrective shortcut. Public answers, emitted d=/s= and receiver results remain unknown until separately collected. This scenario is stipulated, not an actual DNS lookup or panel action.
Preserve the enforcement boundary
RFC 9989 Section 7.4 requires valid DKIM, not SPF alone, for domains publishing p=reject, and warns about indirect-mail and mailing-list interoperability. A single successful direct-message test is not proof that every legitimate route is ready for stronger policy. Keep existing approved protection while diagnosing the actual gap; any policy change needs its own decision.