Email Deliverability / Free checkFree

  SPF Record Checker

Is your SPF record valid?

A free SPF record checker for UK businesses. Paste your domain — we fetch your SPF record, validate the syntax, count the DNS lookups against the 10-lookup limit, grade your terminating policy, and catch the classic failure modes: duplicate records, a permissive +all, or a forgotten sender. DKIM and DMARC checked in the same pass.

Check your record

Domain or email address — we strip the user@ part client-side. Read-only DNS lookups: we don't send mail or touch your server.

What we catch

Four ways
SPF breaks

An SPF record is one TXT entry — v=spf1 include:_spf.google.com -all in its simplest healthy form. Almost every broken record fails in one of four ways, and three of the four fail silently.

  • № 01

    Two SPF records

    The most common self-inflicted wound. Marketing adds Mailchimp's record without merging it into the existing one; the spec says multiple v=spf1 records mean a permanent error — receivers treat the domain as having no valid SPF at all. Everything must live in a single record, multiple include: mechanisms side by side.

  • № 02

    The 10-lookup budget

    Every include:, a, mx and redirect= costs a DNS lookup, and includes nest — Microsoft 365's record alone spends several. Past ten, receivers return permerror and your SPF stops working entirely. Years of accreting mail tools (CRM, helpdesk, newsletter, e-sign) is how sound records quietly tip over the edge.

  • № 03

    A soft or open ending

    The final mechanism sets the policy for everyone not listed. -all says fail them; ~all says softfail — treat with suspicion; +all says anyone may send as this domain, which cancels the whole record. We grade the qualifier and recommend ~all while you're still confirming senders, -all once the list is complete.

  • № 04

    A missing sender

    The invoice system, the booking platform, the new CRM — anything that sends mail as your domain must be in the record. A sender you forgot fails SPF on every message, and once DMARC enforces, those messages go to spam or bounce. This is the one that surfaces as "customers say they never got the confirmation email".

FAQ

Common
questions

  • Q1

    What is an SPF record?

    A TXT record on your domain's DNS listing every mail server authorised to send email as your domain — Google Workspace, Microsoft 365, your newsletter tool, your own SMTP server. Receivers check the sending server against the list on every message; unlisted servers fail the check.

  • Q2

    What's the difference between ~all and -all?

    Both end the record and set the default for unlisted senders. ~all (softfail) marks them suspicious — most receivers treat it as a fail signal for DMARC purposes but won't hard-bounce on it alone. -all (fail) is the strict version. Start with ~all while you confirm every legitimate sender is listed, then tighten to -all. Never use +all — it authorises the entire internet.

  • Q3

    Can I have more than one SPF record?

    No. Two or more v=spf1 TXT records is a permanent error — receivers behave as if you have no SPF at all. Merge everything into one record with multiple include: mechanisms, for example v=spf1 include:_spf.google.com include:servers.mcsv.net ~all.

  • Q4

    Does SPF alone stop spoofing?

    No. SPF checks the envelope sender, which recipients never see — a spoofer can pass SPF on their own domain while displaying yours in the From line. Stopping that requires DMARC, which forces the visible From domain to align with what SPF or DKIM verified. SPF is necessary, not sufficient.

The other two records

SPF is one leg of a three-legged stool.