blueredix logo
medium spf-missing

SPF record missing

Without an SPF record, anyone on the internet can send email that pretends to come from your domain. Why it matters and how to fix it.

What this means in plain English

Your domain has no public statement listing the systems allowed to send email on its behalf. That statement is called an SPF record, and it lives in your domain’s DNS settings (the same place where “www.example.com” is mapped to a server).

Without it, the world’s email servers have no way to tell whether a message claiming to come from you@your-domain.example was actually sent by your provider — or by anyone with a laptop and an internet connection.

Why it matters to your business

Three concrete consequences:

  • Other people can pretend to be you. A scammer can send an invoice to one of your customers that looks like it comes from your finance address. Your customer pays the scammer’s bank account, then asks you a few weeks later why they haven’t received the goods.
  • Your real emails land in spam more often. Mail providers like Gmail, Outlook, and GMX use SPF as a trust signal. Domains with no SPF record get a worse reputation by default, which means your newsletters, order confirmations, and customer replies are more likely to end up in junk folders.
  • Some big providers refuse your mail entirely. Since 2024, Google and Yahoo require SPF for any sender that mails their users in any volume.

How a scammer would use this against you

It costs almost nothing. From any rented server on the internet, the attacker connects to your customer’s mail provider, types “this message is from accounting@your-company.example”, and the mail goes through. Without your SPF record, the receiving server has no authoritative way to say no.

Common targets are:

  • Your customers, with fake invoices or “your password expires today” emails.
  • Your suppliers, with fake bank-detail-update requests that redirect future payments.
  • Your own staff, with fake messages from “the CEO” asking them to install software, share credentials, or buy gift cards.

How to fix it

Adding SPF is a five-minute job for whoever manages your domain — your hosting provider, IT person, or web agency. Here’s the gist of what they need to do:

  1. List every system that sends email as your domain. Common ones include: your mail provider (Google Workspace, Microsoft 365, mailbox.org), your CRM (HubSpot, Pipedrive), your transactional sender (SendGrid, Mailgun, Postmark), your support tool (Zendesk, Freshdesk), your newsletter platform (Mailchimp, Brevo).
  2. Each provider publishes the exact text you need to add. It looks something like include:_spf.google.com or include:spf.protection.outlook.com.
  3. Combine them into a single line and add it to your DNS as a TXT record at the root of your domain. A typical entry reads:
    v=spf1 include:_spf.google.com include:sendgrid.net -all
    
  4. Verify it works with a free checker (linked below) or by running another scan with us.

The ending -all is the strict part — it tells receiving servers “reject any mail from anywhere that isn’t on this list”. That’s the goal. Many people start with ~all (a softer version) during the rollout and switch to -all once they’ve confirmed nothing legitimate broke.

A small thing to watch out for: SPF allows at most ten lookups when checking your record. If you include several mail vendors, the total can creep over the limit and the record stops working. The free checker linked below shows you the count.

Further reading

If you want to dig deeper or pass technical references to whoever implements this: