IONOS SPF Security issues
Understanding SPF Records: Why IONOS’s Setup Falls Short and How Black Sheep Support Can Fix It
At Black Sheep Support, we’re passionate about securing our clients’ email systems—because a secure domain is a trusted domain. A key player in this mission is the Sender Policy Framework (SPF), a DNS-based tool that prevents email spoofing and boosts deliverability. Today, we’re diving into SPF records, how they work, and why a small misstep in their configuration can leave you vulnerable. We’ll spotlight IONOS—a widely used hosting provider—and their SPF recommendation, which we believe needs a serious rethink. Spoiler: their approach isn’t as secure as it could be, and we’ve got a better way.
What Is an SPF Record?
SPF is your domain’s email gatekeeper. It tells receiving mail servers which IP addresses or hosts are allowed to send emails on your behalf. For example when an email arrives claiming to be from [email protected], the recipient’s server checks our SPF record in DNS to confirm the sender legitimacy. If the sender IP matches our SPF rules, it’s a pass. If not, the server follows any additional rejection policies set with DMARC and DKIM for example.
SPF records live as TXT records in your DNS, starting with v=spf1, followed by rules that define who’s authorised. Here’s the breakdown:
- Mechanisms: These are the “who” of your SPF record—specific senders to check. Examples include:
- ip4: A specific IP or range (e.g., ip4:192.168.1.1).
- include: Another SPF record to reference (e.g., include:_spf.google.com).
- a or mx: IPs tied to your domain’s A or MX records.
- Qualifiers: These are the “what happens” part, applied to each mechanism:
- + (Pass): This sender is authorised (default if no qualifier is specified).
- – (Fail): This sender is not authorised—reject it.
- ~ (SoftFail): This sender isn’t authorised but accept it with suspicion (e.g., mark as spam).
- ? (Neutral): No stance—neither authorised nor unauthorised.
- The all Mechanism: Paired with a qualifier (e.g., -all), it sets the default policy for any sender not matched by earlier rules.
Example: v=spf1 ip4:192.168.1.1 include:_spf.google.com ~all authorises 192.168.1.1 and Google’s mail servers, with a SoftFail (~all) for everything else.
How SPF Lookups and Includes Work
SPF isn’t static—it’s a chain of checks. When a server evaluates your SPF record, it processes each mechanism sequentially. The include mechanism pulls in another SPF record, delegating part of the authorisation process. But there’s a limit: SPF allows only 10 DNS lookups (e.g., include, a, mx) to avoid overloading servers. Exceed this, and your SPF breaks, leaving your domain exposed.
For IONOS users, their recommended SPF record is:
v=spf1 include:_spf-eu.ionos.com ~all
This points to _spf-eu.ionos.com, which resolves to:
v=spf1 ip4:212.227.126.128/25 ip4:82.165.159.0/26 ip4:212.227.15.0/25 ip4:212.227.17.0/27 ip4:217.72.192.64/26 ip4:185.48.116.13/32 ?all
(Per IONOS’s SPF guidance.)
We’ll dissect this setup—and its ?all quirk—shortly.
The Qualifiers: -all, ~all, +all, and ?all Explained
The qualifier tied to all defines your default policy for unmatched senders. Here’s what each means:
- -all (Hard Fail): Unmatched senders are rejected outright. It’s the strictest option—only explicitly listed senders pass. Example: v=spf1 ip4:192.168.1.1 -all blocks everything but 192.168.1.1.
- ~all (SoftFail): Unmatched senders are accepted but flagged (often as spam). It’s gentler, ideal for testing or when paired with DMARC/DKIM. IONOS uses this in their main record.
- +all (Pass): Everyone passes—authorised or not. This is a security disaster and virtually never used.
- ?all (Neutral): No policy—unmatched senders are neither approved nor denied. IONOS’s include record ends with this, and it’s a problem.
Main Records vs. Include Records
In your main SPF record (e.g., blacksheepsupport.co.uk), the qualifier sets the domain-wide policy. In an include record (e.g., _spf-eu.ionos.com), the qualifier applies only if that record is checked standalone—which is rare. When included, the main record’s qualifier overrides for unmatched senders. Still, an include’s qualifier matters—it reflects intent and can confuse downstream checks.
At Black Sheep Support, we believe include records should always use -all to firmly authorise their listed IPs, while the main record should use ~all when paired with DMARC and DKIM. Why? Read on.
The ?all Option: Is There Ever a Use Case?
?all is SPF’s “no comment” stance—neither authorising nor rejecting unmatched senders. It’s a holdover from SPF’s early days, but does it belong in 2025?
Possible Use Cases
- Early Testing: Before locking down senders, ?all avoids disrupting emails. Modern DMARC reporting makes this obsolete, though.
- Neutral Delegation: An include might use ?all to defer to the main record’s policy. But if the included IPs are trusted, why not use -all?
Why ?all Is a Red Flag
?all weakens SPF’s purpose—clarity. It leaves receiving servers guessing, risks inconsistent handling, and screams indecision. In IONOS’s _spf-eu.ionos.com, it’s especially odd—why list IPs then shrug with ?all? It’s a security gap we can’t ignore.
IONOS’s SPF Setup: A Weak Link
IONOS advises:
v=spf1 include:_spf-eu.ionos.com ~all
Where _spf-eu.ionos.com is:
v=spf1 ip4:212.227.126.128/25 ip4:82.165.159.0/26 ip4:212.227.15.0/25 ip4:212.227.17.0/27 ip4:217.72.192.64/26 ip4:185.48.116.13/32 ?all
The main record’s ~all is fine—it SoftFails unmatched senders. But the include’s ?all is a head-scratcher. IONOS lists their mail server IPs yet refuses to fail unmatched ones within that record. This creates:
- Ambiguity: The ?all dilutes trust in those IPs. Spoofers outside those ranges aren’t explicitly blocked at the include level.
- Spoofing Risk: While the main ~all SoftFails, the include’s neutrality could confuse servers or tools checking _spf-eu.ionos.com independently.
- Pointless Design: If those IPs are IONOS’s mail servers, -all in the include would lock it down. ?all adds nothing but risk.
Our Stance: SPF, DKIM, and DMARC Together
At Black Sheep Support, we’re firm believers in a layered approach:
- SPF Alone: Use -all in the main record if SPF is your only defence. It’s strict and effective—but no one should stop here.
- SPF + DKIM + DMARC: Use ~all in the main record and -all in includes. Why? DKIM (signatures) and DMARC (policy/reporting) catch what SPF misses. A Hard Fail (-all) risks rejecting legitimate emails during glitches (e.g., misaligned IPs), while ~all with DMARC’s p=quarantine or p=reject balances flexibility and security. Mailhardener explains this debate well.
IONOS’s ?all in the include breaks this model—it’s neither secure nor strategic.
A Better Way: Fixing IONOS’s SPF
Instead of _spf-eu.ionos.com, we recommend IONOS users switch to these tighter alternatives, which cover the same IP ranges with -all:
- _spf.perfora.net: v=spf1 ip4:74.208.4.192/26 ip4:82.165.159.128/27 -all
- _spf.kundenserver.de: v=spf1 ip4:212.227.126.128/25 ip4:82.165.159.0/26 ip4:212.227.15.0/25 ip4:212.227.17.0/27 ip4:217.72.192.64/26 -all
Then, set your main record as:
v=spf1 include:_spf.kundenserver.de ~all (or add other includes like _spf.google.com as needed).
Our Solution
- Audit Senders: We’ll map all your email sources—IONOS, marketing tools, etc.
- Optimise SPF: Swap _spf-eu.ionos.com for _spf.kundenserver.de or _spf.perfora.net, ending includes with -all, and set the main record to ~all.
- Add DKIM & DMARC: Secure signatures and a smart policy (e.g., v=DMARC1; p=none; rua=mailto:[email protected];).
- Check It: Use our Domain Security Checker for a free audit.
Final Thoughts
IONOS’s SPF advice (see their guide) isn’t outright broken, but its ?all include is a weak link. At Black Sheep Support, we’re here to replace ambiguity with precision. Want to see how your domain stacks up? Run our Domain Security Checker today, or contact us to lock down your email—because your domain deserves better.