Setting up SPF at Hetzner DNS — Step-by-Step Guide (2026)

Last updated: July 2026

In short: After this guide your Hetzner-hosted DNS zone publishes a correct SPF record for your mail server. Receiving servers can then tell who’s allowed to send in your name.

Prerequisites

A DNS zone at Hetzner (Hetzner Console; existing zones may still be in the older DNS Console)
You know which servers send email for your domain (your own mail server, hosting mailbox, newsletter service)

What is SPF?

SPF (Sender Policy Framework) is a TXT record in your domain’s DNS. Hetzner’s own docs put it succinctly: a TXT record is added to the zone file listing the domain’s authorized SMTP servers. Receiving mail servers check on every incoming message whether the delivering server is on this list. Without SPF, any server can send mail in your name — and your legitimate mail lands in spam faster.

For context: SPF alone is not complete protection. Only together with DKIM and DMARC does it become a solid foundation. But SPF is the easiest entry point.

The starting point at Hetzner

Hetzner DNS is a pure DNS service: unlike shared hosts, there is no ready-made SPF switch, because Hetzner doesn’t know where your mail runs. You write the record yourself — which fits well here, since as a Hetzner DNS user you typically run your own infrastructure anyway.

Exception: if you use konsoleH (Hetzner web hosting) with konsoleH nameservers, the system sets a default SPF record automatically — there you only need to act if external services should send too.

Step-by-step guide

1. Check whether SPF is already active

Fastest via the terminal:

dig TXT example.com +short | grep spf1

Alternatively, drop your domain into the free MXAudit scanner — it checks the record for syntax and lookup limits at the same time.

2. Build the record for your setup

The classic case, when the same servers send that also receive (your MX points to your mail server):

v=spf1 mx -all

The mx mechanism authorizes the IP addresses of all your domain’s MX hostnames — if the server IP changes, the SPF record stays correct automatically, as long as the MX record is right.

If additional machines send that aren’t in the MX (e.g. a separate sending host), you add them explicitly — Hetzner’s example from the docs:

v=spf1 mx ip4:213.133.98.98 a:test.example.com -all

Mechanism	Effect
`mx`	allows the servers behind your domain’s MX records
`ip4:` / `ip6:`	allows a fixed IP address or subnet
`a:host`	allows the IP behind the A/AAAA record of the given hostname
`-all`	hardfail: only the explicitly listed servers may send

With your own infrastructure, -all is the right choice — you know your sending paths. If you’re unsure during a rebuild, start with ~all and tighten to -all after a few days.

3. Enter the record in the Hetzner Console

Open your DNS zone and create a new record:

Field	Value
Type	`TXT`
Name	`@` (for the main domain)
Value	`"v=spf1 mx -all"`

Two Hetzner quirks from the docs: for the main domain, @ goes in the Name field, and the TXT value must be in quotation marks.

4. Add external sending services (if needed)

A newsletter tool, CRM, or ticketing system needs its include: value in the same record (from that service’s docs, search for “SPF”). The rule holds: only one SPF record per domain — edit the existing one, never create a second. The same applies in konsoleH: external services must be added to the automatically set record.

5. Wait until the change is live

DNS changes take time: depending on TTL and caching it can take a few hours until every server worldwide sees the new record.

Forwarding: why SPF breaks there — and what SRS has to do with it

Hetzner’s docs explain one point more thoroughly than most hosts: automatic forwarding only works with SPF if the forwarding server rewrites the sender address in the envelope — otherwise the final recipient checks your SPF record against the forwarding server’s IP and rejects it. The standardized rewriting method is called SRS (Sender Rewriting Scheme). If you run a forwarding mail server yourself, enable SRS; as a sender you can’t do anything about someone else’s badly configured forwarding — that’s what DKIM and DMARC are for.

Verify the result

Check your configuration with the free MXAudit scanner — it shows immediately whether your SPF record is syntactically correct and how many DNS lookups it consumes (the limit is 10).

Or directly in the terminal:

dig TXT example.com +short | grep spf1

The output must contain exactly one record with v=spf1.

Common mistakes

Forgetting the quotation marks. In the Hetzner Console the TXT value must be in quotation marks — without them the record isn’t created correctly.

Two SPF records. Two TXT entries with v=spf1 cause a permerror — receiving servers then ignore SPF entirely. All sources belong in a single record.

mx without matching MX records. v=spf1 mx -all authorizes exactly the servers from your MX records. If a machine sends that doesn’t appear there (e.g. a cron job on the web server), it’s rejected — add it via ip4: or a:.

+all at the end. A +all allows any server to send and makes the whole record useless — don’t copy it.

Exceeded the DNS lookup limit. SPF allows a maximum of 10 DNS lookups per check; mx, a:, and every include: count. With many external services it gets tight — MXAudit counts along for you.