Hetzner SPF DKIM DMARC Setup: Add Email DNS Records Correctly

Hetzner SPF DKIM DMARC setup is straightforward once you know which DNS zone is authoritative and how Hetzner interprets record names. The difficult part is rarely the email protocol itself: it is entering the right hostname, record type, and destination without accidentally duplicating your domain name.

This guide explains how to add the DNS records required by an email provider, including a custom return-path domain, when you bought your domain through Hetzner. It uses example.com as a safe placeholder. Replace every example value with the values supplied by your actual sending platform.

Start by identifying where your DNS is actually managed

Buying a domain from Hetzner does not automatically mean that every DNS record should be edited in the same Hetzner area, or even at Hetzner at all. A domain registrar controls registration and delegation, while the authoritative nameservers control the DNS zone that inbox providers query for SPF, DKIM, DMARC, MX, and return-path records.

That distinction matters because email-domain verification will fail if you add perfect records in a DNS zone that is not authoritative. For example, you may have registered example.com through Hetzner but delegated it to Cloudflare, another managed DNS provider, a hosting company, or your own nameservers. In that situation, adding records in the Hetzner Console will not change what the public internet sees.

Before adding anything, answer these questions:

• Which nameservers are currently delegated for the domain?
• Is there already a DNS zone for the domain in the Hetzner Console?
• Are you sending from the root domain, such as example.com, or a dedicated sending subdomain, such as mail.example.com?
• Which services already send mail using this domain, including workspace email, support software, ecommerce platforms, product-email providers, and servers?
• Did your email platform provide DKIM as TXT records, CNAME records, or both?

A domain can have many DNS records, but it has one active set of authoritative nameservers at a time. Check the nameservers first, then make changes only in the DNS service those nameservers use.

If Hetzner is authoritative, the DNS zone normally appears in the Hetzner Console. Hetzner documentation also distinguishes its domain-registration interfaces from DNS management: domains may be registered through Robot, but DNS management is handled in the Hetzner Console. That is an easy source of confusion for customers who start in the domain-registration area and cannot find the record editor.

What SPF, DKIM, DMARC, and return-path records each do

Email authentication is not one record and not one pass-or-fail test. It is a group of systems that evaluate different identities in an email message.

SPF authorizes sending infrastructure

SPF, or Sender Policy Framework, publishes a list of systems permitted to send mail for a domain used in the SMTP envelope sender. Receivers typically evaluate the domain in the SMTP MAIL FROM identity. Recipients may see this identity as the Return-Path in message details.

An SPF record does not sign an email and does not directly validate the visible From: address. It says, in effect, that a particular server, IP address, or included provider policy is authorized to send for an envelope domain.

A common SPF record looks like this:

v=spf1 include:spf.sender-example.net -all

The exact include domain must come from the sending provider. Never substitute a guessed include hostname just because another provider uses a similar pattern.

DKIM cryptographically signs messages

DKIM, or DomainKeys Identified Mail, lets a sending service sign outgoing email with a private key. The corresponding public key is published in DNS. Receiving systems retrieve that public key and use it to validate the signature.

The DKIM lookup name combines:

• A selector, such as s1 or mail
• The fixed label _domainkey
• The signing domain

For a selector of s1 and domain example.com, the DKIM lookup name is:

s1._domainkey.example.com

Providers commonly ask you to publish either a DKIM TXT record containing a public key or a DKIM CNAME record pointing to a provider-controlled hostname. CNAME-based DKIM lets the provider rotate keys without requiring you to edit DNS for every rotation.

DMARC connects authentication to the visible From domain

DMARC, or Domain-based Message Authentication, Reporting, and Conformance, evaluates whether SPF or DKIM passes and aligns with the domain in the visible From: header. It also publishes a policy telling receivers how to handle messages that fail DMARC and where to send aggregate reports.

This alignment requirement is why a message can pass SPF but still fail DMARC. If SPF passes for bounce.vendor-mail.example while the visible From address is billing@example.com, SPF may not align with example.com. A DKIM signature aligned with example.com can still make DMARC pass.

A custom return-path gives SPF an aligned identity

A custom return-path, sometimes called a custom MAIL FROM domain or bounce domain, is usually a subdomain you delegate to the sending provider with a CNAME record. An example might be:

bounce.example.com

When configured correctly, the sending platform can use that subdomain for envelope sending and bounce processing. This separates the sending service from your root-domain SPF record and can allow SPF alignment with the organizational domain under relaxed DMARC alignment.

The exact setup varies by provider. Some providers require one CNAME for a return-path domain; others require a set of CNAME records for DKIM plus another CNAME for tracking or bounce handling. Treat the provider's domain-verification screen as the source of truth for the exact labels and values.

The Hetzner DNS navigation path

As of writing, Hetzner's current documentation describes the DNS-record workflow in the Hetzner Console as:

1. Sign in to the Hetzner Console.
2. Select the project that contains the DNS zone.
3. Choose DNS in the left menu.
4. Select the relevant zone, such as example.com.
5. Use the record editor and select the record Type to choose TXT or CNAME.
6. Enter the record name, value, and TTL, then save the record.

If the domain has not yet been added as a zone in the Hetzner Console, the documented flow is to open DNS in the left menu and select Add zone. Creating a zone alone does not make it authoritative for your domain. You must also ensure the domain's delegated nameservers point to the nameservers for that zone.

For customers using Hetzner managed hosting and the older konsoleH environment, the route can be different. Hetzner documentation describes a path through the hosting name, then DNS Management, then DNS Records. In other konsoleH domain views, DNS entries may be under the selected domain's Settings area. Use the interface that actually hosts the authoritative zone rather than assuming every Hetzner account uses the same dashboard.

If you registered the domain through Hetzner Robot, do not assume records are edited in Robot. Hetzner's own documentation states that DNS management is performed in the Hetzner Console. If you cannot find the zone in the Console, first verify the current nameservers rather than creating duplicate or inactive records.

Record shapes for SPF, DKIM, DMARC, and return-path DNS

The table below shows the record shape, not universal copy-and-paste values. Values from your email platform may differ, especially for DKIM selectors and CNAME destinations.

For root-domain SPF, Hetzner documents @ as the root name in its TXT record examples. For DMARC, enter _dmarc, not _dmarc.example.com, when the selected zone is already example.com.

The most important rule is this: the HOST or NAME field is usually relative to the zone currently open in Hetzner. When you are editing the example.com zone, _dmarc represents _dmarc.example.com, and s1._domainkey represents s1._domainkey.example.com.

Add SPF without creating multiple SPF records

SPF is published as a TXT record. For a root domain, the record name is normally @ in Hetzner's DNS editor. If you use a dedicated mail subdomain, such as mail.example.com, the name would be mail within the example.com zone.

Build one policy, not one record per sender

A domain must not publish multiple competing SPF TXT records that begin with v=spf1. Multiple SPF policies at the same hostname can produce an SPF permerror, which means receivers may treat SPF as invalid.

This is a common scenario:

• Google Workspace is already authorized to send mail for example.com.
• Your application email provider also needs authorization.
• A support desk or CRM needs to send messages using the same envelope domain.
• Each service gives you an SPF value and tells you to add it as a TXT record.

Do not add every value as a separate root TXT record. Instead, merge the required mechanisms into a single SPF policy, assuming the providers' documentation supports that arrangement.

For example, these two separate records are wrong when both exist at example.com:

v=spf1 include:_spf.google.com -all

v=spf1 include:spf.sender-example.net -all

A combined policy might look like this:

v=spf1 include:_spf.google.com include:spf.sender-example.net -all

Do not blindly combine values if one provider specifically instructs you to use a different envelope domain or a dedicated return-path CNAME. In many cases, a custom return-path is preferable because it keeps a vendor's infrastructure off the root-domain SPF policy.

Understand the ending mechanism

The final portion of an SPF record matters:

• -all means systems not matched earlier should fail SPF.
• ~all means systems not matched earlier should soft-fail SPF.
• ?all is neutral and provides little enforcement.

For a fully inventoried domain, -all is usually the intended endpoint. But do not switch an existing production SPF policy from ~all to -all until you know every legitimate sending source. SPF is evaluated against envelope infrastructure, not merely the applications you remember using.

Watch the DNS lookup limit

SPF evaluation has a DNS-lookup limit. Includes, redirects, some a, mx, exists, and ptr mechanisms can contribute to the limit. A long chain of SaaS includes may cause SPF to exceed the limit, leading to a permanent error.

This is another reason to avoid treating the root SPF record as a dumping ground for every vendor. A dedicated custom return-path can reduce the need to merge vendors into one root policy, while aligned DKIM can provide a more resilient path to DMARC compliance.

Add DKIM records exactly as your provider supplies them

DKIM is where record-type mistakes are especially costly. A sending platform may show a hostname that looks like a TXT record but require a CNAME, or it may show a long public key that requires a TXT record. The record type is not interchangeable.

DKIM TXT record example

A provider using a direct public key might give you a record conceptually similar to:

In the Hetzner example.com zone, enter s1._domainkey as the name. The platform's full lookup name is then s1._domainkey.example.com.

A DKIM key can be long. Hetzner supports TXT values that consist of multiple strings, and DNS software can concatenate those strings. Still, use the format requested by the provider and do not insert extra spaces into the base64 public-key material after p=. A copied newline, a missing character, or an accidental quote can make the published key unusable.

DKIM CNAME record example

A provider using delegated keys might give you:

This tells DNS resolvers that s1._domainkey.example.com aliases the provider's key hostname. The provider can then publish and rotate the actual DKIM public key at the destination it controls.

Do not create a TXT record at the same DKIM hostname when a provider requires CNAME. A hostname with a CNAME cannot coexist with other data records. If old TXT, A, AAAA, or CNAME records already occupy that exact hostname, review and remove only the conflicting obsolete record after confirming it is no longer required.

Use every selector the platform provides

Many sending services publish two or three DKIM selectors for redundancy and key rotation. Add every required record, not just the first one. If the provider lists s1._domainkey, s2._domainkey, and s3._domainkey, each is a separate hostname and must be created separately.

Do not rename selectors. The selector in the DNS record must match the selector used by the sender's DKIM signature. A receiver reads the s= and d= values from the message's DKIM-Signature header and queries the corresponding record.

Add a custom return-path CNAME carefully

A custom return-path is often the best answer when your transactional email provider asks you to authorize a bounce or MAIL FROM subdomain. It gives the provider an address for bounce handling while allowing SPF to authenticate a domain under your organizational domain.

A provider might ask for a record shaped like this:

In the example.com zone, the resulting public hostname is bounce.example.com.

Some providers use names such as mail, send, em, rp, bounce, or a generated label. Do not replace their provided label with your own preferred wording. The provider's verification system checks the exact requested hostname.

Why the return-path is not the visible From address

A return-path record does not change the From address recipients see in their inbox. You might send a message with:

• Visible From: receipts@example.com
• Envelope sender or return-path: bounces@bounce.example.com

That separation is normal. SPF checks the envelope identity, while DMARC evaluates whether SPF or DKIM aligns with the visible From domain. With relaxed SPF alignment, a properly configured subdomain such as bounce.example.com can align with example.com. DKIM aligned directly with example.com remains important because it provides an independent authentication path.

Avoid using the root domain for a CNAME

A root domain normally has essential records such as NS, SOA, A, MX, and TXT. DNS rules do not allow a CNAME to coexist with those records. Use a subdomain for return-path delegation, never @, unless a provider explicitly documents a different supported method.

Add DMARC in monitoring mode first

DMARC is also a TXT record. In the example.com zone, the host is _dmarc, which resolves publicly as _dmarc.example.com.

A safe starting record is:

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

This tells receivers to monitor failures without requesting enforcement, while aggregate reports are sent to the address in rua.

Choose a reporting mailbox deliberately

DMARC aggregate reports are typically XML files, often compressed, and can arrive in significant volume for active domains. Use a mailbox or reporting service designed to receive them. Do not point rua at a personal inbox that nobody monitors.

If you send reports to a third-party domain, DMARC requires additional authorization in many cases. Keeping the initial rua address under your own domain is simpler unless your reporting provider documents the required external-report authorization record.

Progress from observation to enforcement

A practical rollout usually follows these stages:

1. Publish p=none and collect reports.
2. Identify every legitimate sender that uses the visible From domain.
3. Fix SPF and DKIM failures, especially alignment failures.
4. Move to p=quarantine when legitimate mail consistently passes.
5. Move to p=reject after you are confident spoofed mail should be rejected.

For example, an eventual enforcement record might be:

v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=r; aspf=r

The adkim=r and aspf=r tags specify relaxed alignment, which is also the usual default behavior. Do not set strict alignment merely because it sounds more secure. Strict alignment can break legitimate mail flows where a carefully controlled subdomain is used for return-path or DKIM signing.

DMARC standards were updated in 2026 through RFC 9989 and related reporting RFCs, but the familiar operational record format still begins with v=DMARC1 and is published at _dmarc as a TXT record. The core deployment principle remains unchanged: establish authenticated, aligned legitimate mail before enforcing rejection.

The Hetzner-specific hostname mistake to avoid

The most common Hetzner DNS entry mistake is putting the full root domain into the HOST or NAME field when Hetzner is already editing that domain's zone.

Suppose your selected zone is example.com and your provider asks for this DKIM hostname:

s1._domainkey.example.com

In Hetzner's host/name field, enter:

s1._domainkey

Do not enter:

s1._domainkey.example.com

Hetzner's documentation explains that a name entered without a trailing period is treated as relative to the zone, with the zone appended. Entering the complete domain in the host field can therefore create an unintended name such as:

s1._domainkey.example.com.example.com

The same issue appears with DMARC and return-path records:

Do not confuse the host field with the CNAME destination

The host/name field identifies the record you are creating inside your zone. The CNAME value identifies where that hostname should point.

For example:

• Host/name: s1._domainkey
• Resulting source hostname: s1._domainkey.example.com
• CNAME destination: s1.domainkey.provider-example.net.

For the destination value, paste the provider's hostname exactly as supplied. If it ends in a period, preserve that trailing period. The period denotes a fully qualified domain name in DNS notation and prevents a zone suffix from being appended in zone-file syntax.

This is why it is dangerous to copy only part of a provider's DNS instruction. Preserve the record type, host, value, and any documented trailing period as a complete unit.

Verify records before asking the sending platform to recheck

DNS changes may appear quickly, but public propagation depends on TTLs, resolver caches, nameserver updates, and the provider's own verification schedule. Do not repeatedly modify records while waiting; that often creates new errors and resets the troubleshooting process.

Check the published DNS records

You can use command-line DNS queries to see what public resolvers return:

# SPF at the root domain
dig TXT example.com +short

# DMARC record
dig TXT _dmarc.example.com +short

# DKIM record or CNAME target
dig CNAME s1._domainkey.example.com +short
dig TXT s1._domainkey.example.com +short

# Custom return-path CNAME
dig CNAME bounce.example.com +short

For DKIM, query the record type your provider requested. A CNAME-based DKIM record should return the expected CNAME target. A TXT-based DKIM record should return the public key tags.

If you use an email platform with automated verification, wait until the public query shows the expected answer before selecting its verify or retry action. If public DNS is correct but verification still fails, compare every character in the platform's expected record with the published result.

For sending-domain configuration details and provider-side verification steps, consult the email API reference and setup guides.

Send a real test message

DNS verification is necessary but insufficient. Send a message to a mailbox you can inspect, then view the complete headers. Look for results similar to:

• spf=pass
• dkim=pass
• dmarc=pass

Also check the domains that passed. A pass from an unexpected vendor domain may reveal a lack of alignment even if the sending platform reports that the domain is verified.

For example, an ideal transactional message sent as updates@example.com would generally show DKIM signing aligned to example.com or an acceptable subdomain. If SPF passes only for a generic provider hostname but DKIM is aligned to your domain, DMARC can still pass. If both are unaligned, DMARC can fail despite individual authentication passes.

Troubleshoot common Hetzner email DNS failures

The record is visible in Hetzner but not in public DNS

First verify nameserver delegation. The zone displayed in Hetzner may be inactive if the domain delegates to another DNS provider. Compare the domain's current NS records with the nameservers assigned to the Hetzner zone.

Also check for a simple zone mismatch. If you own both example.com and mail.example.com as separate zones, entering bounce in the wrong zone creates a different public hostname than intended.

DKIM verification says the record is missing

Check the selector and record type. A provider expecting s1._domainkey will not find s2._domainkey, and it will not accept a TXT key when it asks for a CNAME delegation.

Next, inspect for an accidental duplicated suffix. A public lookup of s1._domainkey.example.com returning nothing while s1._domainkey.example.com.example.com returns data is a clear sign that the full hostname was entered into Hetzner's relative host field.

CNAME verification fails even though the name looks right

Check the CNAME destination, including every label. Copying a provider value without its final label, using the wrong region-specific hostname, or replacing a generated destination with a guessed hostname will fail verification.

Also ensure no other record exists at the same source hostname. A CNAME must stand alone; remove only records that conflict at that exact hostname and are confirmed obsolete.

SPF produces a permanent error or does not pass

Look for more than one TXT record beginning with v=spf1 at the same hostname. Merge authorized mechanisms into one valid policy where appropriate.

Then inspect DNS lookup complexity. Too many nested includes can exceed SPF's lookup limit. If a vendor supports a dedicated custom return-path subdomain, using it may be cleaner than continually adding includes to root-domain SPF.

DMARC is failing after you published a record

Publishing a DMARC record does not make mail authenticated. Check whether SPF or DKIM passes and whether at least one passing result aligns with the visible From domain.

A frequent cause is an old service still sending messages as @example.com without DKIM or with an unrelated envelope sender. DMARC reports are useful precisely because they expose those forgotten systems before you enforce quarantine or reject.

Maintain the configuration as your email stack changes

Email authentication is ongoing infrastructure work, not a one-time DNS project. Every new sender, marketing tool, support platform, invoice system, or SMTP relay can change your authentication posture.

Keep a simple inventory containing:

• The service name and owner
• The visible From domain it uses
• The envelope sender or return-path domain it uses
• Its DKIM selector or selectors
• The DNS records it requires
• Whether the service is still active
• The date the records were last verified

Prefer a dedicated sending subdomain for application and campaign mail when it makes operational sense. For example, use mail.example.com or another clearly managed subdomain for a product-email provider while preserving the root domain for employee mail and corporate identity. This can reduce SPF complexity and make DMARC reporting easier to interpret.

Before deleting an old SPF include, DKIM selector, or return-path CNAME, confirm that no scheduled jobs, password resets, invoice notices, or legacy applications still use it. DNS cleanup improves security and reduces confusion, but removing a record prematurely can silently disrupt critical mail.

Conclusion

A reliable Hetzner SPF DKIM DMARC setup starts with DNS authority, then follows the exact record instructions from your sending provider. In the Hetzner Console, select the correct project and DNS zone, use relative hostnames such as _dmarc, bounce, and s1._domainkey, and paste provider-supplied values exactly.

The biggest Hetzner-specific trap is entering the full domain in a host field that already belongs to the example.com zone. Avoid that duplicated-domain error, keep only one SPF policy per hostname, publish every required DKIM selector, and begin DMARC with monitoring before enforcing a rejection policy. Finally, test real messages and inspect authentication headers instead of relying only on a green verification badge.

FAQ

Where do I manage DNS for a domain bought through Hetzner?

For zones managed by Hetzner's current DNS service, open the Hetzner Console, select the relevant project, choose DNS in the left navigation, and select the domain's zone. Domain registration and DNS management can be separate interfaces, so confirm that the domain's authoritative nameservers point to the zone you are editing.

Should I enter _dmarc.example.com or _dmarc in Hetzner?

When editing the example.com zone, enter _dmarc. Hetzner appends the zone name, producing _dmarc.example.com. Entering the full hostname can create _dmarc.example.com.example.com.

Can I have more than one SPF record?

You can have multiple TXT records at a domain for different purposes, but you should have only one SPF policy beginning with v=spf1 at a given hostname. Merge authorized senders into one SPF policy or use dedicated return-path domains where supported.

Is DKIM always a TXT record?

No. DKIM can be published directly as a TXT public key or delegated using a CNAME record. Use the exact type and values supplied by your email provider. Do not substitute one type for the other.

How long do SPF, DKIM, DMARC, and return-path changes take?

The DNS record may become publicly visible quickly, but propagation and provider verification can take longer because of TTLs, resolver caching, and verification queues. Confirm the public DNS answer first, then retry verification after the requested record is visible.