Last updated: July 2026

In short: After this guide your domain publishes a correct SPF record. Receiving mail servers can then tell which servers are allowed to send in your name — and sort out forged senders.

Prerequisites

  • A domain at checkdomain with active checkdomain nameservers
  • Access to the customer area (customer number or email address)

What is SPF?

SPF (Sender Policy Framework) is a TXT record in your domain’s DNS. It lists which mail servers are allowed to send email with your domain as the sender. Receiving servers look up the record on every incoming message and check whether the delivering server is on the list. Without SPF, any server can send mail in your name — and your legitimate mail lands in spam faster, because large receivers like Gmail now simply expect SPF.

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 checkdomain

checkdomain offers no ready-made SPF switch: you create the record yourself as a TXT entry, tucked away in the Pro settings area of the nameserver management. Two peculiarities from the official guide:

  • The value is entered without quotation marks (other providers — Hetzner, for instance — require exactly the opposite; don’t blindly copy from other guides).
  • checkdomain explicitly points out that nameserver management is your own responsibility — faulty entries disrupt mail delivery.

checkdomain’s documented example is the classic mx-based record:

v=spf1 mx -all

The mx mechanism authorizes the servers behind your MX records. If your mailboxes run at checkdomain (so your MX points to checkdomain servers), this single entry covers them automatically.

Step-by-step guide

1. Check whether SPF is already active

Fastest via the terminal:

dig TXT example.com +short | grep spf1

If a record with v=spf1 comes back, your domain already publishes SPF. Alternatively, drop your domain into the free MXAudit scanner — it checks the record for syntax and lookup limits at the same time.

2. Open the customer area

Open www.checkdomain.de, click My Login at the top right and choose Customer area. Log in with your customer number or email address.

3. Navigate to the domain configuration

In the left navigation, click Domains, find your domain, and click Configuration. On the detail page, open Checkdomain Nameserver.

4. Set the SPF entry in the pro settings

Open the Pro settings area and create a TXT entry for the domain. Enter the SPF value without quotation marks:

v=spf1 mx -all

Check the value and click Save. Important: there may be only one SPF entry per domain — if a TXT record with v=spf1 already exists, edit it instead of creating a second one.

5. Add additional senders (if needed)

If you also send via other services — newsletter tool, CRM, shop system — their servers must be in the record too. You’ll find the required include value in that service’s docs (search for “SPF”):

v=spf1 mx include:spf.newsletter-dienst.de ~all

6. Wait until the change is live

According to checkdomain, the change is usually saved within seconds; until it’s fully visible worldwide it can take up to 48 hours.

The components in detail

ComponentMeaning
v=spf1version identifier, always at the start
mxallows the servers behind your domain’s MX records
include:allows the servers of an external service (1 DNS lookup per include)
-allhardfail: non-listed servers are rejected
~allsoftfail: the milder variant — sensible while you’re still sorting out sending paths

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

Quotation marks copied along. At checkdomain the value goes in the field without quotation marks. Copying "v=spf1 mx -all" including the marks from someone else’s guide creates a broken record.

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 doesn’t cover all sending paths. The example record only authorizes the servers from your MX records. If a shop system or form mailer sends from elsewhere, it needs include: or ip4: additions.

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

Forwarding fails. If a recipient auto-forwards your mail, SPF often fails at the final recipient — the forwarding server isn’t in your record. That’s a design weakness of SPF, not a configuration error; DKIM and DMARC catch this case.

Further reading