Does your domain publish an SPF record that says which servers are allowed to send your email?
Checks for the DNS record that prevents others from sending email pretending to be from your domain.
What this signal tests
SPF, the Sender Policy Framework, is a small public record attached to your domain name in DNS. It lists which email servers are authorised to send mail using your domain name in the From address. We look for an SPF record at your apex domain, confirm it starts with v=spf1, and check that it ends with a restrictive directive (-all or ~all) rather than an open one. An SPF record that ends with +all is worse than no record at all.
Why it matters for your visibility in AI
Email authentication is one of the strongest indicators that a domain is actively operated and well governed. AI systems that rank publishers, summarise news, or judge brand legitimacy treat SPF as a baseline. Without it, your domain is more easily spoofed in phishing campaigns, your legitimate marketing emails are more likely to land in spam, and your overall domain reputation suffers in the trust databases that feed both inbox filters and AI retrieval pipelines. The practical chain is concrete. SPF is the foundation. DKIM and DMARC build on it. BIMI builds on DMARC. Each layer requires the one beneath. A missing SPF record breaks the whole stack, and AI tools that read brand-trust signals see the gap immediately.
Pass criteria at a glance
| Criterion | Passes when |
|---|---|
| Single v=spf1 record with restrictive all. |
How we test it
We send a DNS query for the TXT records at your apex domain. Among them we look for one that starts with v=spf1. We then read the rest of the record to confirm it ends with -all (strict reject) or ~all (soft fail). We also check that you do not have multiple SPF records, because the SPF spec only permits one per domain. The lookup is plain DNS and completes in milliseconds.
Show technical detection method
DNS TXT at apex; find record beginning v=spf1; ensure ends with -all or ~all (not +all or missing).
If your site fails: how to fix it
- Identify every service that sends email using your domain. Common examples: Google Workspace or Microsoft 365 for staff mail, Mailchimp or Resend for newsletters, Stripe or Shopify for transactional receipts, your CRM, your help desk.
- Find each provider's recommended SPF include. For example, Google Workspace uses `include:_spf.google.com`, Microsoft 365 uses `include:spf.protection.outlook.com`, Mailchimp uses `include:servers.mcsv.net`.
- Open your DNS console at your registrar (Cloudflare, GoDaddy, Namecheap, Route 53, etc.) and add a single TXT record at the apex with all your includes combined, ending in -all. For example: `v=spf1 include:_spf.google.com include:servers.mcsv.net -all`.
- If you already have an SPF record, edit it in place rather than adding a second one. Multiple SPF records at the same domain are invalid and cause silent failures.
- Wait a few minutes for DNS to propagate, then test with a tool like mxtoolbox.com or dmarcian's SPF surveyor before re-running the AI Ready Test scan.
Quick facts
| Maturity | ESTABLISHED |
|---|---|
| Weight | medium |
| Category | Trust & Provenance |
Primary sources
Related signals
Frequently asked questions
Will I need IT help to fix this?
Usually no, but you do need access to your DNS console and a clear list of services that send email for you. The hardest part is inventorying senders. Once you have the list, adding the TXT record is a single DNS edit.
What if my email is hosted by Google Workspace or Microsoft 365 - is this already done for me?
Partly. Both vendors document the SPF include line you must add, but neither writes the DNS record on your behalf. You still have to log into your DNS provider and publish the TXT record. The vendors only provide the value, not the publishing step.
Does this affect my email deliverability too?
Significantly. A well-formed SPF record is one of the three pillars (SPF, DKIM, DMARC) that mainstream inbox providers use to decide whether to deliver your email. Missing SPF often means more of your legitimate mail ends up in spam, which is a much larger business impact than the AI signal alone.
How long until the change propagates?
Most DNS providers publish TXT updates within minutes. Allow up to an hour for older or cached resolvers, and 24 hours in the rare case of very long TTLs. Use `dig txt yourdomain.com +short` or an online SPF lookup to verify.
Run your own scan
Run a free scan and see how your site grades across all 155 AI-readiness signals.