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 domainfactory account with at least one domain
  • Access to the customer menu

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 domainfactory

domainfactory takes the record-writing off your hands: the nameserver settings include an SPF wizard. You answer three questions about your sending behavior, and the system generates the matching entry — pros can then adjust it via Edit manually.

One peculiarity that no other large German host does this way: when you save, two SPF entries are created — one for your-domain.tld and one for *.your-domain.tld. The wildcard entry thus also covers all subdomains that don’t have their own record.

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 nameserver settings

Log into the customer menu and select Nameserver settings. Click Edit next to your domain and then Add entry…

3. Fill in the SPF wizard

Under Type, choose SPF. The input form now shows three configuration questions:

OptionWhat it means
Email sending by scriptsDo form mailers, shop software, or CMS plugins send mail directly from the webspace? Then the web server IP has to go into the record.
SMTP serverDo you use the domainfactory mail servers? Here you can also enter additional mail servers of your own.
CompletenessDoes this capture all sending IP addresses — or are there more SMTP servers?

At the bottom the form shows the generated SPF entry. If everything fits, click Save — domainfactory then creates the two entries (domain + wildcard).

The script question is the most important. A WordPress contact form without an SMTP plugin sends via the web server. If you answer the question with No, its IP is missing from the record — and exactly those mails land in spam.

4. Subdomains and new domains

Subdomain with its own sending (e.g. newsletter.example.com): just create another SPF entry and put the subdomain in the Hostname field — the entry then applies only to it.

Automatically for new domains: switch to the Default settings tab in the nameserver settings (if not visible: first click Cancel domain selection at the top left), add an SPF entry there with an empty hostname — every newly ordered domain then gets the entry automatically.

5. Add additional sending services (if needed)

You enter a newsletter tool or CRM via the wizard under SMTP server — or via Edit manually as an include: value from that service’s docs. What stays important: only one SPF record per (sub)domain.

6. 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.

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

Denied script sending even though the CMS sends mail. Contact forms, shop order confirmations, and plugin notifications often run via the web server. If its IP is missing from the record, exactly those mails fail — answer the wizard’s “Email sending by scripts” question honestly, or switch to SMTP sending.

Answered “Completeness” too optimistically. If you state that all IPs are captured while a CRM or newsletter service is still sending, you lock those services out.

Created a second record manually. At domainfactory too, the rule holds: only one SPF entry per (sub)domain — two v=spf1 records cause a permerror. The wizard does this right; be careful with manual rework.

+all when editing manually. 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