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:
- 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).
- Each provider publishes the exact text you need to add. It
looks something like
include:_spf.google.comorinclude:spf.protection.outlook.com. - 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 - 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:
- MXToolbox SPF check — instant free verification of your published record.
- Google Workspace SPF setup guide
- Microsoft 365 SPF guidance
- RFC 7208 — Sender Policy Framework (the formal specification)