Do You Need an SPF Record for a Subdomain?

The short answer

A root-domain SPF record does not cover a subdomain. If the subdomain is used in the return-path for mail, publish SPF at that exact subdomain.

SPF is checked against the envelope sender domain, also called the MAIL FROM or return-path domain. That domain can be different from the address people see in the inbox. A message can show hello@example.com while the return-path is bounces.mail.example.com. In that case, the SPF check happens at bounces.mail.example.com, not at example.com.

So the practical rule is simple. Add SPF to a subdomain when that subdomain sends mail, appears in the return-path, or is used as a mail server HELO/EHLO identity. Do not add SPF just because the subdomain exists. A subdomain that only hosts a site, app, docs, or landing page does not need SPF.

• Subdomain used for bounces: publish SPF at that bounce subdomain.
• Subdomain only used for web pages: no SPF needed.
• One DNS name should have one SPF TXT record that starts with v=spf1.
• Merge duplicate SPF records instead of publishing two records at the same host.
• Run a free domain check at InboxRadar after DNS changes.

How SPF works for subdomains

Receivers look up SPF on the domain used by the SMTP envelope, not on every related domain.

If your newsletter provider says to set the return-path to mail.example.com, the SPF record belongs at mail.example.com. If your transactional mail provider uses bounce.example.com, the SPF record belongs there. If Google Workspace or Microsoft 365 sends mail directly from example.com, the SPF record usually belongs at the root.

Follow the sender's DNS instructions, but check the headers on a real message too. Look for Return-Path or the SPF result in Authentication-Results. That tells you which domain the receiver checked.

Keep the record small enough to evaluate. SPF has a hard limit of 10 DNS-querying terms during one check. The terms that can count include include, a, mx, exists, redirect, and ptr if you use it. Avoid ptr. It is slow and discouraged by the SPF standard. Nested includes count too, so a record can break even when it looks short.

• Use include: only for senders you still use.
• Remove old CRMs, marketing tools, and help desks from SPF.
• Avoid SPF flattening unless you can keep it updated.
• Do not use +all. It allows any sender.

Which SPF ending should you use?

~all is safer while you are finding every sender. -all is for domains with a clean, complete sender list.

~all means soft fail. It tells receivers that mail from other sources is probably not allowed, but it leaves room while you are still testing. -all means hard fail. It tells receivers that mail from other sources is not allowed. Receivers still make their own filtering decisions, but a hard fail is a stronger signal.

Use -all only after every real envelope sender is covered. DMARC aggregate reports can help prove that. If a vendor sends with its own return-path domain and passes DKIM aligned with your visible From domain, it may not need your SPF record. The point is to check the actual authentication path, not copy every vendor into SPF.

• Start with ~all for new or messy setups.
• Move to -all after real mail is passing cleanly.
• Use DMARC reports to spot senders you forgot.
• Keep SPF under the 10-lookup limit before tightening policy.

SPF is only one spam signal

Gmail and Outlook look at authentication, alignment, sending reputation, complaints, and how people handle your mail.

SPF answers one question: is this sending IP allowed for the envelope sender domain? It does not sign the message, and it does not check the visible From address by itself. Microsoft describes SPF as validating sources for the MAIL FROM domain only. Google also tells senders to set up SPF, DKIM, and DMARC because unauthenticated mail can be marked as spam or rejected.

DKIM signs the message with a private key. The public key usually lives at a selector such as selector1._domainkey.example.com. A valid DKIM signature proves the signed content has not changed and that the signing domain controls the key. For DMARC, the DKIM signing domain also needs to align with the visible From domain.

DMARC connects SPF and DKIM to the visible From domain. A DMARC record lives at _dmarc.example.com. Start with p=none and a rua address so you can review aggregate reports. Move to p=quarantine or p=reject only after normal mail passes. If the reports are hard to read, use the free DMARC report reader before tightening the policy.

MX records tell the internet where to deliver inbound mail. They do not make SPF pass. A send-only subdomain may not need MX unless it receives replies or bounces. Blocklists still matter too. Good authentication proves identity, but it does not erase a poor IP or domain reputation.

Common subdomain setups

The right SPF location depends on how each service sends mail.

• Root domain sends mail: publish SPF at example.com.
• Newsletter uses a return-path subdomain: publish SPF at that return-path subdomain.
• Transactional mail uses a bounce subdomain: publish SPF at the bounce subdomain and set up DKIM where the provider tells you.
• Subdomain only hosts a website: no SPF is needed unless it sends mail or appears in the mail envelope.
• Root DMARC is already live: that organizational DMARC policy can apply to subdomains unless an sp tag or a subdomain DMARC record changes it.

If you are unsure, send one test message from each system and inspect the headers. Find the return-path. Confirm SPF on that exact DNS name. Then check DKIM, DMARC alignment, MX where inbound mail matters, and obvious blocklist issues before blaming the sending tool. More related checks are in the InboxRadar guides.

What about AI search crawlers?

Email DNS and AI-search visibility are separate, but both depend on small records that are easy to forget.

If the same subdomain hosts docs, guides, or a marketing site, make sure AI search crawlers can reach the pages you want cited. The crawlers that decide whether you appear in AI answers are OAI-SearchBot for ChatGPT search, Claude-SearchBot for Claude, PerplexityBot for Perplexity, Googlebot for Google AI Overviews, and Applebot for Apple Intelligence. Google AI Overviews ride the normal Search index. There is no separate opt-out crawler for them.

Disallowing those crawlers in robots.txt removes you from that engine. By contrast, GPTBot, ClaudeBot, CCBot, Google-Extended, and Applebot-Extended are training or opt-out controls. Blocking them does not affect live AI-search visibility. Google-Extended and Applebot-Extended are robots-only control tokens with no separate crawl user-agent.

Treat robots.txt as a stated policy, not proof of behavior. Perplexity-User and Bytespider are reported to ignore it, so do not use the file alone as evidence of what a bot did. Only Googlebot documents JavaScript rendering. For the other AI crawlers, client-side-only content is an undocumented risk. Put important text in server-rendered HTML when you can. You can test the crawlability side with the free AI visibility checker.