IONOS SPF Security issues - IT Support

Email security is not optional for UK SMEs. One fundamental component is the Sender Policy Framework (SPF), a DNS record designed to prevent email spoofing and improve deliverability. Correct SPF configuration confirms which servers are authorised to send email on your domain's behalf. An incorrect or ambiguous setup, however, leaves your business vulnerable to phishing and reputation damage. We routinely encounter issues with SPF records, particularly with hosting providers whose default configurations can be less than optimal. IONOS, a widely used provider, offers a standard SPF recommendation that, in our assessment, requires refinement for proper security.

What SPF actually means

An SPF record acts as your domain's email gatekeeper. It is a specific type of DNS TXT record that lists all IP addresses and hostnames permitted to send email using your domain. When an email arrives, the recipient's mail server checks your domain's SPF record. If the sending server's IP address is listed, the email passes this check. If not, the receiving server applies a policy based on your record's instructions, which can range from marking the email as spam to outright rejection. This mechanism is crucial for validating email authenticity and protecting your domain from unauthorised use.

Why it matters for UK SMEs

For UK SMEs, effective email security is not just good practice; it is a commercial imperative and a regulatory necessity. A poorly configured SPF record, or its absence, directly impacts your business.

Firstly, it exposes your organisation to email spoofing. Cyber criminals can forge emails appearing to come from your domain, targeting your clients, suppliers, or even your own staff with phishing attacks. Such incidents can lead to significant financial loss, reputational damage, and a breakdown of trust with your stakeholders. The National Cyber Security Centre (NCSC) consistently highlights email as a primary vector for cyber attacks, making robust email authentication a core defence.

Secondly, deliverability suffers. Receiving mail servers are increasingly strict about email authentication. If your SPF record is misconfigured or too permissive, your legitimate emails are more likely to be flagged as spam or rejected by recipient systems. This means important communications — invoices, client updates, marketing messages — may not reach their intended audience, disrupting operations and impacting revenue.

Finally, there are compliance implications. Under the General Data Protection Regulation (GDPR), organisations are responsible for protecting personal data. Email spoofing can facilitate data breaches, leading to potential fines from the Information Commissioner's Office (ICO) and mandatory breach reporting. Furthermore, for SMEs pursuing certifications like Cyber Essentials, proper email authentication (including SPF, DKIM, and DMARC) is a fundamental control. Failing to implement these measures correctly can prevent certification and signal a lack of due diligence in your cyber defence. In essence, a weak SPF record is a business risk that no SME can afford to ignore.

How to implement and optimise your SPF record

Implementing and optimising your SPF record involves understanding its components, respecting technical limitations, and adopting a layered security approach. This is where many organisations, particularly those relying on default settings from providers like IONOS, encounter issues.

Understanding SPF Components

An SPF record begins with v=spf1 and contains various mechanisms and qualifiers.

Mechanisms: These define who is authorised to send email.

• ip4: Specifies an IPv4 address or range (e.g., ip4:192.168.1.1 or ip4:192.168.1.0/24).
• include: References another domain's SPF record. This is common for third-party email services (e.g., include:_spf.google.com).
• a or mx: Authorises IP addresses associated with your domain's A records or MX records.
• ptr: (Rarely used, generally discouraged due to performance and security concerns).

Qualifiers: These dictate the policy for each mechanism or for senders not explicitly matched.

• + (Pass): Explicitly authorises the sender. This is the default if no qualifier is specified.
• - (Fail): Explicitly rejects the sender. This is a "Hard Fail" and means the email should be rejected.
• ~ (SoftFail): Marks the sender as not authorised but allows the email to be accepted, often with a spam flag. This is common when paired with DMARC.
• ? (Neutral): Takes no stance. The sender is neither authorised nor unauthorised.

The all mechanism, typically placed at the end of the record (e.g., -all, ~all, ?all), defines the default policy for any sender not matched by the preceding mechanisms.

The 10-DNS Lookup Limit

A critical technical constraint is the SPF 10-DNS lookup limit. Each include, a, mx, and ptr mechanism in your SPF record, or within any included SPF records, counts as one DNS lookup. Exceeding this limit renders your SPF record invalid, effectively leaving your domain unprotected. This often occurs when businesses add multiple third-party email services (marketing platforms, CRM systems, HR software) without consolidating or optimising their SPF record.

Main Records vs. Include Records

Your primary SPF record for your domain (e.g., yourdomain.co.uk) sets the overarching policy. An include record, such as _spf.google.com, is a sub-record. While the all qualifier in your main record dictates the final policy, the qualifiers within include records are not entirely irrelevant. An include record ending in -all clearly states that only the IPs listed within that specific include are authorised, which is the desired outcome for third-party services. An include record ending in ?all, however, introduces ambiguity.

The IONOS ?all Problem

IONOS's recommended SPF record often looks like this: v=spf1 include:_spf-eu.ionos.com ~all. The ~all in the main record is generally acceptable when combined with DKIM and DMARC. However, the _spf-eu.ionos.com record itself 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.

The ?all qualifier at the end of IONOS's included record is problematic. While IONOS clearly lists their authorised mail server IPs, the ?all effectively states "no policy" for anything not matching those IPs within that specific include. This dilutes the authority of the listed IPs and introduces unnecessary ambiguity. It's a security gap because it doesn't firmly assert that only those specific IONOS IPs are legitimate senders for their service. Some might call ?all a policy of studied indifference; we call it a security risk.

Black Sheep Support's Recommended Approach

At Black Sheep Support, we advocate for a layered email security strategy combining SPF, DKIM (DomainKeys Identified Mail), and DMARC (Domain-based Message Authentication, Reporting & Conformance). This combination provides robust protection against spoofing and phishing.

For IONOS users, we recommend replacing include:_spf-eu.ionos.com with a more precise include that uses a -all qualifier. IONOS provides alternatives that cover the same IP ranges more securely:

• For _spf.perfora.net: v=spf1 ip4:74.208.4.192/26 ip4:82.165.159.128/27 -all
• For _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

Your main SPF record should then be configured as: v=spf1 include:_spf.kundenserver.de include:_spf.google.com ~all (adjusting for any other legitimate senders, like _spf.google.com if you use Google Workspace). The ~all in the main record is appropriate when DMARC is also in place, allowing DMARC to handle the ultimate policy for unmatched senders (quarantine or reject) based on aggregated reports.

Our Solution in Practice:

When we onboard a new client, our process is thorough. For example, we recently onboarded a 30-user architectural practice in Manchester. Their initial SPF record was exceeding the 10-lookup limit due to multiple marketing tools, and their main mail provider's include record contained a ?all qualifier. This meant their email was effectively unprotected against direct spoofing, a common vector for phishing attempts.

Our approach involves:

1. Auditing All Senders: We map every service authorised to send email on your behalf, from your primary mail provider to CRM systems and marketing platforms.
2. Optimising SPF: We consolidate and streamline your SPF record, replacing ambiguous includes like _spf-eu.ionos.com with tighter alternatives (e.g., _spf.kundenserver.de) and ensuring all includes end with -all. Your main record will typically conclude with ~all as part of a DMARC strategy.
3. Implementing DKIM & DMARC: We configure DKIM for digital signatures and set up a DMARC policy (e.g., v=DMARC1; p=none; rua=mailto:[email protected];). This provides verifiable email authentication and crucial reporting on email activity and potential spoofing attempts.
4. Verification and Monitoring: We use domain security checkers to confirm correct configuration and establish ongoing DMARC reporting to continuously monitor for issues and detect unauthorised use of your domain.

Common mistakes we see

1. Exceeding the 10-DNS lookup limit: Adding too many include mechanisms or using a or mx records unnecessarily can invalidate your SPF record, rendering it useless.
2. Using +all or ?all in the main record: This effectively tells recipient servers that anyone can send email from your domain, providing no protection against spoofing.
3. Missing legitimate senders: Forgetting to include an email marketing platform or a CRM system in your SPF record will cause legitimate emails to be marked as spam or rejected.
4. Not implementing DKIM or DMARC: Relying solely on SPF leaves significant gaps in your email security, as SPF alone cannot fully prevent all forms of spoofing.
5. Ignoring DMARC reports: Without monitoring DMARC reports, you cannot identify who is spoofing your domain or if your legitimate emails are failing authentication checks.

Key Takeaways

• SPF is a critical DNS record for email authentication and preventing spoofing.
• IONOS's default SPF include with ?all is a security weakness requiring correction.
• A comprehensive email security strategy requires SPF, DKIM, and DMARC working together.
• Regular auditing and optimisation of your SPF record are essential, especially when adding new email services.
• Proper configuration protects your brand reputation, ensures email deliverability, and helps maintain compliance.

When to call in help

Configuring SPF, DKIM, and DMARC correctly, especially when dealing with multiple third-party senders and potentially ambiguous default settings from hosting providers, can be complex and time-consuming. Missteps can lead to legitimate emails being rejected or, worse, leave your domain open to spoofing attacks. If you lack the in-house expertise or time to manage this critical aspect of your cyber security, engaging specialists is a prudent decision. We have the experience to audit your current setup, implement best practices, and ensure your email infrastructure is securely configured and continuously monitored.

To take the next step

Book a Discovery Call