SPF Record for a Domain That Does Not Send Email

The short answer

A domain that never sends email should publish this SPF record at the root: v=spf1 -all.

That record says no IP address is allowed to send mail for the domain. It is the right SPF policy for a parked domain, a defensive registration, or an old domain that you keep but do not use for email.

SPF by itself is not the whole lock. SPF checks the envelope sender or HELO identity, while DMARC protects the visible From domain when SPF or DKIM passes with alignment. For a domain that sends nothing, publish SPF, null MX, and DMARC together so receivers that check these standards get a clear signal.

The DNS records to publish

Use three records. They each answer a different question about mail for the domain.

• SPF TXT at the root: use v=spf1 -all. The -all result is SPF hard fail. Do not use ~all for a non-sending domain. Soft fail means the message is probably not authorized, which is weaker than the policy you want.
• Null MX at the root: use an MX record with priority 0 and target .. RFC 7505 defines this as the way to say the domain accepts no mail. It controls inbound mail, not outbound authentication.
• DMARC TXT at _dmarc: start with v=DMARC1; p=reject; rua=mailto:you@example.com. DMARC p=reject asks receivers that evaluate DMARC to reject messages that fail DMARC. The rua address receives aggregate reports, which can show attempted abuse. If you need to read those XML reports, the free DMARC report reader turns them into plain English.

For subdomains, add sp=reject if you want the DMARC record to say the same thing explicitly for names under the domain. Also check any delegated subdomain. If a subdomain has its own NS records, its DNS is managed somewhere else.

Why this works

A parked domain has no real mail stream, so the safest sender list is an empty sender list.

v=spf1 -all is also simple. It has no include, a, mx, ptr, exists, or redirect mechanism, so it does not spend any of the SPF 10 DNS lookup limit from RFC 7208. That removes a common cause of SPF permanent errors.

DKIM is different. DKIM signs mail with a selector record, such as selector1._domainkey.example.com. A domain that sends nothing has no mail to sign, so it does not need a DKIM selector today. If the domain later starts sending, set up DKIM signing with the mail provider before the first real send.

Gmail, Outlook, and other mailbox providers use authentication, reputation, user complaints, content, blocklists, and their own local rules when they decide whether to accept, reject, or spam-folder mail. These records do not force every provider to act the same way, but they give standards-aware receivers the clearest possible policy for a domain that should never send.

Mistakes to avoid

Most bad parked-domain setups fail because one record is missing or too vague.

• Publishing two SPF records. A domain must have only one TXT record that starts with v=spf1. Multiple SPF records cause SPF permerror.
• Using ~all. Soft fail is for cautious sender migrations. A domain with no valid senders should use hard fail.
• Stopping at SPF. SPF does not create a DMARC policy for the visible From domain. Add DMARC so receivers know what you want done with failing mail.
• Leaving old mail vendors in DNS. Remove stale SPF includes, old DKIM selectors that belong to vendors you no longer use, and old MX records that no longer serve a purpose.
• Assuming blocklists are fixed by DNS alone. Good authentication helps receivers judge mail, but a listing usually has its own removal process. Check the listing source before guessing.

After DNS changes, run the domain through the free domain scorecard. It reads the live SPF, DKIM, DMARC, and MX records so you can confirm the lockdown is actually published.

This does not control AI crawlers

Email DNS records do not decide whether AI search engines can crawl your website.

If you also care about appearing in AI answers, check your site access separately. The crawlers tied to live AI answers are OAI-SearchBot for ChatGPT search, Claude-SearchBot for Claude, PerplexityBot for Perplexity, Googlebot for Google Search and AI Overviews, and Applebot for Apple Intelligence. Blocking those in robots.txt removes you from that engine.

GPTBot, ClaudeBot, CCBot, Google-Extended, and Applebot-Extended are training or opt-out controls. Google-Extended and Applebot-Extended are robots-only control tokens, not separate crawler user agents. Blocking these training controls does not block live AI-search visibility. Robots.txt is a stated policy, not proof of what a bot actually did. Only Googlebot documents JavaScript rendering, so client-side-only content is a risk for other AI crawlers unless their docs say otherwise. The free AI visibility checker checks the crawler rules separately from email DNS.