Hetzner SPF, DKIM and DMARC setup, step by step

For Hetzner managed mail, enable DKIM in the actual konsoleH mail service and verify the public record it generates. Reconcile SPF with every legitimate outbound route, including applications. Publishing a zone in Hetzner Console or renting a Hetzner cloud server does not itself enable managed-mail signing.

This guide preserves the managed-mail and Microsoft 365 application-relay scenarios, with DNS publication at Hetzner or an external authoritative provider. It is not a self-managed mail-server installation, Xneelo configuration, or general DNS migration guide.

Establish the actual sender and DNS owner

Inventory ordinary mailbox mail, website-generated mail and application relay as separate paths. Record the product/account, visible From domain, expected SMTP envelope, signing domain, DNS owner and person authorized to approve changes. A site hosted at Hetzner can send through another delivery platform; users moved to Microsoft 365 can leave a local application on the old managed server.

Confirm the public delegation for every relevant owner, including child zones and _domainkey delegations. Do not infer authority from a zone listed in an account. Preserve the original DNS values, TTLs, active mail-system state and application configuration for recovery. Do not change MX, nameservers, DNSSEC, forwarding or unrelated website records just to match an authentication example.

Hetzner's DNS administration documentation says DNS management is primarily in Hetzner Console; managed-server navigation also exposes hosting name, DNS Management, DNS Records. These account surfaces are distinct from the mail service's DKIM control. A Reset zone operation loses previous custom changes, and Delete zone removes the zone. Neither is an authentication repair.

Enable the managed-mail key, not a copied selector

In the correct domain's konsoleH email-security configuration, use the documented Enable DKIM function. It generates a key pair. With konsoleH nameservers, the service can publish the necessary record automatically; with external nameservers, publish the displayed TXT record at the actual authoritative provider. Obtain the complete owner, selector and public value from that account. This is the workflow described in Hetzner email security, not a universal static record.

Retain the full public tagged value, including its key material. Do not expose the private key in DNS, screenshots or support messages. The provider also supports an own-key route and says its private key must not be password-protected; that is a separate credential-handling decision, not a reason to export or weaken an existing key during this routine generated-key setup.

Inspect the resulting DNS and enabled state rather than assuming automatic publication succeeded. If the account offers different controls or no expected record, stop and confirm product/account applicability with support. The public source establishes the Enable DKIM function, not every tenant's menu layout. Do not invent an additional activation button or treat DNS visibility as proof the intended messages are signed.

Keep existing selectors until dependent senders and queued messages have been assessed. A new key can coexist at a new selector; deleting an old selector before its users stop signing creates failures that a green dashboard may not reveal.

Reconcile SPF with mailbox and application traffic

The managed service documents automatic default SPF with konsoleH nameservers, but external senders must be accounted for. Inspect the actual generated policy; do not replace it with a guessed include, a cloud-server address, or a record from a differently scoped provider guide. With external DNS, obtain the required authorization from the current service/account and merge it at the correct owner.

SPF evaluates SMTP MAIL FROM, or HELO where applicable, not simply the visible From header. Maintain one v=spf1 TXT policy at the evaluated owner while preserving unrelated TXT verification records. Combine legitimate approved mechanisms without changing existing qualifiers casually. Include nested evaluation when checking the ten DNS-dependent-term budget; it is not ten visible includes. An all mechanism causes redirect to be ignored. -all expresses SPF failure, not a guarantee that every receiver will reject the message. See RFC 7208.

The Microsoft 365 relay case below deliberately includes parent-domain authorization. Do not generalize that case into apex SPF changes for an unrelated application with a provider-owned envelope. Record the actual identities separately before deciding what a policy change can accomplish.

Publish in the current Hetzner Console when it is authoritative

In the appropriate project, choose DNS, select the zone, select Type, fill the record fields and use Add for a genuinely new record. Review an existing record before replacing its value. This current route is documented in Adding records; it is not a request to migrate an older console or move DNS into this project.

Hetzner's TXT record documentation uses @ for the root, quoted TXT values and multiple quoted strings when needed. For a zone example.com, prepare these illustrative mappings:

• Apex SPF at example.com: Name @.
• DKIM at SELECTOR._domainkey.example.com: Name SELECTOR._domainkey.
• DMARC at _dmarc.example.com: Name _dmarc.
• Relay SPF at relay.example.com in the parent zone: Name relay.
• Relay DKIM at SELECTOR._domainkey.relay.example.com: Name SELECTOR._domainkey.relay.
• Relay DMARC at _dmarc.relay.example.com: Name _dmarc.relay.

If relay.example.com is separately delegated, use that actual child zone: SPF is @, DKIM is SELECTOR._domainkey, DMARC is _dmarc. If _domainkey.example.com is delegated, the selector is SELECTOR relative to that zone. Preserve the delegation rather than creating a shadow record in its parent.

Keep the complete key as one TXT record. A long value can contain multiple character-strings; their concatenation must reproduce the exact supplied content without inserted whitespace. Do not split it into separate competing key records. RFC 6376 section 3.6.2.2 defines that key-record processing. Use straight presentation quotes, not smart quotes copied from formatted examples.

The managed-mail procedure issues TXT, not a made-up DKIM CNAME. If a different approved sender supplies CNAMEs for the same DNS zone, preserve that type and target. Hetzner's CNAME rules distinguish relative names from absolute names ending in a dot, prohibit CNAME at the zone apex and prohibit other records at the same owner. Use the full issued destination with the absolute trailing-dot representation; never add TXT, A, AAAA, MX or another CNAME at that alias owner.

Keep authentication aliases DNS-only rather than HTTP-proxied, redirected or replaced with ANAME/ALIAS. If another DNS layer applies flattening, check per-record, zone-wide, apex and same-zone behavior. Where a literal CNAME is required, disable relevant per-record flattening when available and ensure the applicable zone behavior retains the alias. No Hetzner-specific flattening switch is assumed here. If mandatory behavior cannot preserve the required answer, stop and coordinate a supported configuration, not a global settings change or deletion of shared NS records.

Handle the Microsoft 365 application relay as a routing project

This branch applies only to the documented migration scenario: mailboxes are handled by Microsoft 365 while applications on the managed server still need to send using the domain. It is not a generic fix for a DKIM warning. Before proceeding, obtain approval for disabling local delivery, the dedicated subdomain, server addresses, MX destination and application change. Confirm no live mailbox or local-routing dependency will be stranded, and define recovery and inbound-mail tests.

The provider's SMTP relay procedure has this sequence:

1. Disable the original domain's mail system in konsoleH as part of the approved migration.
2. Create the relay subdomain as an external Addon Domain in the hosting account.
3. Publish its A, AAAA and MX records using the actual managed-server addresses and hostname; the documented MX preference is 10.
4. Create a dedicated mailbox under that subdomain for SMTP authentication.
5. Enable its DKIM and configure its SPF; also merge the managed-server authorization into the original domain's SPF without removing existing mechanisms.
6. Configure the application to authenticate with the relay mailbox. Its visible sender can remain an address at the original domain.

For the parent SPF change, the documentation uses the mechanism shape a:SERVER-NAME.your-server.de. SERVER-NAME must be the actual approved managed server, not a literal placeholder or guessed host. The dedicated login, visible sender, envelope sender and signing domain remain different identities. The procedure does not prove exact strict alignment for an unseen message.

Check each A/AAAA address and MX target against the authorized routing plan before publishing. Merely receiving a packet is not approval to route mail there. Keep the mailbox password in the approved application secret store; it is not DNS data. Do not copy an unrelated generic mail-client port configuration over the application's tested connection settings.

Preserve DMARC protection and authorized reporting

Inspect the direct policy and any applicable inherited policy. Retain enforcement, alignment modes and authorized report destinations. Never lower an established policy to p=none to accommodate an unverified relay, create duplicate policies or copy a vendor's example report address.

Only if there is no direct or applicable inherited policy, the owner approves monitoring, and someone will review the reports, this is an illustrative first policy:

Full owner: _dmarc.YOUR-DOMAIN.example
Type: TXT
Logical value: v=DMARC1; p=none; rua=mailto:APPROVED-REPORT-MAILBOX

Replace APPROVED-REPORT-MAILBOX with a mailbox address, not another mailto: URI. Map the owner to the actual zone and use its documented TXT quoting. Do not copy obsolete pct tags from older DNS examples. DMARC policy preferences do not guarantee a recipient's final handling; current RFC 9989 governs alignment and evaluation.

A report destination in a different Organizational Domain from the policy domain requires the report-generating receiver's DNS authorization check. A destination within the same Organizational Domain is excepted even when the hostname differs. Coordinate any required authorization with the report operator and obtain the domain owner's separate data-sharing approval. See RFC 9990 section 4.

Verify publication, signing and alignment separately

Use actual names in read-only DNS checks, for example:

dig @AUTHORITATIVE-NS.example SELECTOR._domainkey.YOUR-DOMAIN.example TXT +noall +answer
dig @AUTHORITATIVE-NS.example YOUR-DOMAIN.example TXT +noall +answer
dig @AUTHORITATIVE-NS.example _dmarc.YOUR-DOMAIN.example TXT +noall +answer
dig SELECTOR._domainkey.YOUR-DOMAIN.example TXT +noall +answer

These are proposed commands, not observed output. Check each authoritative server, then a recursive resolver. Compare exact owner, type, joined value and aliases; distinguish an absent record from a wrong target or stale cache. Preserve the previous TTL and allow its cached answers to expire.

Confirm the managed service's enabled state, then send controlled non-sensitive messages through the ordinary mailbox route and every distinct application route to valid authorized test recipients. Use Authentication-Results created within the receiving service's known processing boundary. Establish how that receiver removes or disregards externally supplied forged fields through its documentation or administrator. A matching authserv-id or header position alone is not trustworthy. Ignore attacker-supplied results. RFC 8601 explains the boundary.

For newly configured branded DKIM, require the intended signature to pass and align with the intended visible From under the active adkim mode, plus trusted dmarc=pass. SPF-only DMARC success does not prove DKIM works. Do not accept a provider-rewritten From as successful authentication of the intended brand.

For example, a valid intended signature with d=relay.example.com and visible From noreply@example.com aligns in relaxed mode when both have Organizational Domain example.com, but not in strict mode. d=example.com matches that From domain in both modes. These are illustrative identities, not a claim about Hetzner's observed signer. Compare SPF's actual envelope separately under aspf; SMTP login is not the envelope. EmailAuth's raw-versus-aligned DKIM guide explains why cryptographic success and alignment are separate.

Troubleshooting and recovery

• Managed DKIM enabled, public key absent: establish authority and automatic DNS permission; compare the displayed record with the public answer and the correct child zone.
• Mailbox succeeds, application fails: compare actual server and identities before replacing keys. The application may still use another route.
• SPF permerror: investigate duplicate policies, syntax and DNS-term budget. Temperror needs temporary-DNS diagnosis; fail means the authorization did not pass. Address SPF defects even if DKIM currently supplies DMARC success.
• DKIM passes but the brand does not align: compare d=, visible From and strict/relaxed policy; an extra TXT record cannot change the signer's identity.
• Inbound mail stops after migration: pause the affected rollout, reconcile local mail-system state and approved MX routing, and execute the reviewed recovery plan.

Restore only the approved prior values and application settings implicated in the fault. Avoid blanket Reset/Delete zone actions. Coordinate key retirement and keep dependent selectors available. Verify inbound delivery as well as controlled outbound authentication after any routing reversal. Authentication is not an inbox-placement guarantee.