TransIP SPF, DKIM and DMARC setup, step by step

To publish email-authentication records in TransIP, first confirm that its nameservers are authoritative for your domain. Open the domain’s DNS settings, merge SPF into the existing policy, and add the exact DKIM records issued by the service that sends your mail. Preserve your DMARC policy. Then check both public DNS and a message received through the intended sending route.

This guide covers TransIP as a DNS host, including records for external email providers. A separate section identifies the documented TransIP hosted-email and VPS Mailservice records. Registering a domain or hosting a website at TransIP does not identify its outbound mail service. No customer account, DNS change or delivery test was performed.

On this page:

• Overview
• Identify the DNS host and the mail sender
• Open the editor without resetting the domain
• Translate record names and values correctly
• Publish SPF for the actual envelope domain
• Publish and activate the sending service DKIM records
• Use TransIP mail records only for the matching service
• Preserve DMARC and arrange useful reporting
• Verify authoritative DNS and delivered messages
• Troubleshooting and safe rollback
• Frequently asked questions
• Does TransIP DNS require a TransIP SPF include
• Should I change MX records to enable DKIM
• Can I copy another domain public DKIM key
• How long should I wait before troubleshooting
• Is a DNS checker enough to call setup complete

Identify the DNS host and the mail sender

TransIP’s DNS editor affects public DNS only when the domain uses its authoritative nameservers. If the domain is delegated elsewhere, publish at that provider, even if TransIP is the registrar. A delegated subdomain may also have its own authoritative zone. TransIP nameserver guidance

Before editing, make a small change worksheet:

Ask the sending-service administrator to finish any domain enrollment or key-generation step first. TransIP cannot generate the matching private signing key for an unrelated email platform merely by hosting its public DNS record. For website mail, use the WordPress sending-route guide before deciding which provider’s records to request.

Open the editor without resetting the domain

In the control panel, choose Domain, select the domain itself rather than its checkbox, and find DNS settings. Manual records appear when TransIP settings are off. Review and preserve the existing zone before changing this mode. Do not turn TransIP settings on as a troubleshooting shortcut: TransIP warns that enabling them replaces previously configured DNS records and nameservers. Bulk copy and restore actions likewise affect more than one authentication record. TransIP control-panel instructions

Plan a narrow change. Do not alter website A/AAAA records, mailbox MX records, verification tokens or other senders’ DKIM selectors just to add SPF or DKIM. Authentication setup is not a nameserver migration or an inbound-mail migration.

Record the before and after values, save the intended edits, and reopen the zone to confirm what was stored. Use the original TTL when estimating how long cached answers can persist. Lowering a TTL after a bad answer was cached does not instantly expire that cached answer.

Translate record names and values correctly

TransIP adds the zone name to the Name field. In the example.com zone, use these mappings. The names are illustrations, not records supplied for your account.

For an external CNAME Value, enter its full target and the terminating dot, such as account-key.sender.example.. Without that dot, TransIP can append your own domain to the target. Do not put a trailing dot in Name. A CNAME is for a subdomain, not the zone apex. TransIP CNAME rules

For TXT values, do not copy the quotation marks used to display a DNS response. Preserve the actual SPF or public-key text. TransIP’s DKIM article also says not to insert backslash escaping into its TXT input. A workaround documented for another DNS host is not transferable to TransIP. TransIP DKIM input format

If the DNS editor rejects a long public-key value, stop and obtain the currently supported input method from TransIP. Do not truncate the key or guess a host-specific splitting format. Verify that the complete published TXT value matches the sender’s issued public key. TransIP DKIM input guidance.

Check existing data at every proposed CNAME owner. If another sender already uses that selector or bounce hostname, stop and obtain an alternative name from the sender where supported. Do not put TXT alongside a CNAME at the same owner or remove the existing service’s record without a coordinated transition.

Where the actual authoritative DNS host offers these controls, use DNS-only aliases, not HTTP proxying or redirects, and keep a literal CNAME answer to each required target. Turn the relevant per-record Flatten option off when available, and ensure applicable zone-wide settings do not conceal the issued aliases. For Cloudflare specifically, flatten-all cannot be overridden per record; apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are Cloudflare behaviors, not assumed controls in another provider’s panel. If mandatory behavior or shared settings prevent the required CNAME answer, stop and coordinate a supported configuration without breaking dependent records. Do not blindly change the whole zone or remove an NS delegation; publish at the delegated authority when appropriate. Cloudflare CNAME verification, flattening controls.

Publish SPF for the actual envelope domain

SPF authenticates the sending IP against the SMTP MAIL FROM domain, with a HELO-based identity for a null reverse path. It does not directly authenticate the visible From address. An SPF policy at example.com does not automatically apply to bounce.example.com. SPF specification

For an external sender, use that service’s current instructions. Some services request an addition to your apex TXT policy; others delegate an account-specific return-path subdomain by CNAME or publish SPF at a separate owner. Do not add a TransIP include merely because TransIP hosts your DNS.

If the sender requires a TXT policy at an owner you control:

1. Read all TXT answers at that exact owner and identify the record beginning v=spf1.
2. If it exists, edit that policy rather than adding another SPF record.
3. Preserve still-needed authorizations, insert only the verified new mechanisms, and retain one version tag and the intended final all qualifier.
4. Keep unrelated TXT records. Retire an authorization only after its sending route has been decommissioned.
5. Check the full evaluated SPF path, including nested includes and redirects, against the limit of 10 DNS-query-causing terms. a, mx, exists and ptr also consume that budget; ip4 and ip6 do not. SPF evaluation limits

~all produces softfail for unmatched senders; it does not guarantee acceptance. -all produces fail; it does not control every receiving system’s final decision. Neither is an inbox guarantee. Preserve the established qualifier during this configuration change unless the domain owner has separately reviewed a policy change.

If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.

Publish and activate the sending service DKIM records

Obtain the selector, signing domain and complete public TXT value or CNAME target from the actual sender. For a service using a TXT public key, publish only the public material. Never place a private DKIM key, SMTP password or API credential in DNS.

A DKIM verifier builds the lookup name from the message’s s= selector and d= signing domain. A signature with s=mail2026 and d=news.example.com uses mail2026._domainkey.news.example.com, not the apex. Multiple quoted chunks can represent one TXT record, but two separate competing key records at one selector are not a safe substitute. DKIM key lookup and TXT representation

For an issued signing domain such as news.example.com, the illustrative full owner is ISSUED-SELECTOR._domainkey.news.example.com. In an editor relative to the parent example.com zone use ISSUED-SELECTOR._domainkey.news; in a separately delegated news.example.com zone use ISSUED-SELECTOR._domainkey; in a delegated _domainkey.news.example.com zone use only ISSUED-SELECTOR. Replace the placeholder with the issued selector and preserve the exact account type and value. These mappings do not establish product eligibility for a new domain. Publish at the actual authority, preserve NS delegation and check the resulting full owner. DKIM owner construction, relative DNS names.

After publishing, return to the sender’s verification page. Complete its verification and any separate enable signing action. Record which domain and selector the sender intends to use. A DNS answer alone cannot enable a service that has not been configured to sign.

If the platform is SendGrid, the SendGrid domain-authentication guide covers the sending-side workflow. This TransIP procedure supplies the DNS-publication half, not a replacement for sender enrollment.

Use TransIP mail records only for the matching service

For the documented TransIP Web Hosting, Email Only and Forwarding services, the official hosted-service DNS page lists this SPF policy. Treat it as the provider’s standalone example, not a replacement for an existing multi-sender policy:

v=spf1 include:_spf.transip.email ~all

Its DKIM delegation uses all three CNAMEs below. These are documented TransIP service records, not tenant-specific external-provider examples.

The three selectors support key rotation. Confirm the subscription’s supplied DNS details and keep all required selectors. The English hosted-service documentation and the newer Dutch version agree on these authentication values. The Dutch page also shows a default monitoring DMARC record; do not overwrite an established policy with it. English hosted-service records · Dutch hosted-service records

For the VPS Mailservice, DNS is only part of setup. The service requires activation, domain authentication, its issued authentication-hash TXT record and relay configuration on the VPS. The panel’s VPS Mailservice workflow supplies the required values; automatic DNS addition is limited to eligible same-account domains using TransIP nameservers. Otherwise publish the supplied records at the actual DNS host. Use the provider’s MTA-specific configuration instructions rather than assuming that publishing hosted-mail CNAMEs redirects a VPS’s mail through the relay. VPS Mailservice setup

A self-managed server sending directly is another route. It needs its own outbound-IP authorization and configured signing system. TransIP’s general DKIM page distinguishes that arrangement from its managed mail services. Do not upload a randomly generated private key to a website and expect hosted mail to use it. TransIP DKIM service boundaries

Preserve DMARC and arrange useful reporting

DMARC passes when either SPF passes with alignment to the visible From domain, or DKIM passes with an aligned d= domain. Relaxed alignment allows the same organizational domain; strict alignment requires an exact match. A provider-domain SPF pass is not automatically aligned. Current DMARC standard

Inspect the existing policy at _dmarc and any applicable parent policy before adding or changing one. Do not create competing DMARC records or downgrade p=quarantine or p=reject to finish a setup wizard. For a new rollout with no existing applicable policy, a monitored starting example is:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Publish the new value as TXT at _dmarc.example.com: in the example.com zone, the relative Name is _dmarc. For a policy specifically covering a From domain of news.example.com, the full owner is _dmarc.news.example.com. Enter _dmarc.news in the parent example.com zone, or _dmarc if news.example.com is a separately delegated authoritative zone. Follow the DNS host’s full-name convention if it does not use relative names. Do not add a child policy merely to replace an applicable inherited policy. DMARC policy publication

Before publishing a first monitoring policy, confirm absence of any direct or applicable inherited policy and obtain the domain owner’s explicit approval of the monitoring and review plan. A supplied default does not authorize replacing existing policy.

Replace the example address with an authorized reporting destination that actually accepts reports. This is not a TransIP-required value. If the receiver of reports uses another organizational domain, arrange the external-report authorization described in RFC 9990. Do not publish a guessed reporting vendor address.

Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4.

Review reports by sending source and authentication identity, including legitimate services unrelated to TransIP. Confirm failures before advancing enforcement. The DMARC reporting guide explains the investigation workflow. Current DMARC specifications have replaced RFC 7489; do not base a new rollout on its removed pct percentage mechanism.

RFC 9989 section 7.4 requires valid DKIM for domains publishing p=reject and warns about interoperability with indirect delivery and mailing lists. Check those legitimate paths before any enforcement decision; one direct-message success is not domain-wide readiness. Preserve existing policy while diagnosing failures, and obtain separate owner approval for any policy change. DMARC interoperability requirements.

Verify authoritative DNS and delivered messages

The following commands are templates for your administrator, not tests performed for this article. Replace the zone, authoritative server, envelope owner, signing domain and selector with the values collected earlier. Repeat authoritative queries against each active nameserver.

dig +short NS example.com
dig @ns1.dns-host.example example.com TXT +noall +answer
dig @ns1.dns-host.example bounce.example.com CNAME +noall +answer
dig @ns1.dns-host.example selector._domainkey.example.com CNAME +noall +answer
dig @ns1.dns-host.example selector._domainkey.example.com TXT +noall +answer
dig @ns1.dns-host.example _dmarc.example.com TXT +noall +answer
dig +short TXT bounce.example.com
dig +short TXT selector._domainkey.example.com

Query the exact SPF owner, not only the apex. Where a CNAME is returned, compare its complete target with the sender’s instructions and query the target’s TXT answer too. Expect one applicable SPF policy, the intended usable DKIM key path and one valid DMARC policy at the relevant owner. An empty p= is a revoked DKIM key. A missing answer requires checking the name, delegation and resolver response, not assuming the sender has no DKIM anywhere.

Next, send a controlled message through each intended route to a mailbox you can inspect. Read the recipient system’s trusted Authentication-Results, not an arbitrary header copied from the sender. Authentication-Results trust boundary

Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust. For this branded-DKIM deployment, require the intended provider signature itself to have trusted dkim=pass and a d= domain aligned with the intended unchanged visible From under effective adkim, plus the trusted receiver’s dmarc=pass for that From. A DMARC pass through SPF alone does not complete the DKIM task. DMARC alignment. Diagnose the actual smtp.mailfrom result independently: fail or softfail calls for checking the connecting sender against the approved authorization; temperror is a transient evaluation failure, often DNS; permerror requires checking malformed or duplicate policies and the evaluated lookup budget. An aligned DKIM pass does not repair these SPF faults. Do not change an unrelated apex policy to fix a provider-controlled envelope domain. SPF result definitions.

Accept the configuration only when you have recorded:

• The expected branded From address and actual MAIL FROM identity.
• dkim=pass for the intended branded signing domain and selector. A pass for only a platform domain does not demonstrate that your custom DKIM works.
• spf=pass for the actual envelope domain on direct, unforwarded mail, or a specifically explained limitation. Investigate fail, softfail, none, temperror and permerror rather than overlooking them because DKIM passes.
• dmarc=pass with at least one verified aligned path. An intentional strict-SPF mismatch may be covered by aligned DKIM, but a broken SPF policy still needs repair.
• Successful delivery to the intended test recipient. Authentication success does not establish inbox placement for all future mail.

Troubleshooting and safe rollback

If a change causes failure, restore the affected records from the saved known-good values and retest all senders that share the owner. A whole-zone restore may undo unrelated work made since the backup, so inspect the diff first. Do not remove an old DKIM selector until its former sender and queued mail no longer require it. Document who owns the next check.