Does having no SPF record mean my email will be rejected?

Usually not on its own. The result is none rather than fail, and most receivers do not reject purely on a missing SPF record. The real cost is that you have no way to prove which servers are yours, and no SPF path for DMARC to pass on.

Where exactly does the SPF record go?

In a TXT record at the apex of the domain: the record name is the bare domain, entered as @ in most DNS panels. It does not go at spf. or _spf. Those names are used inside include statements by providers, but your own record belongs at the apex.

Do subdomains inherit the SPF record from the parent domain?

No. SPF is evaluated against the exact domain in the envelope sender, and there is no inheritance. If mail is sent from mail.example.com, that name needs its own SPF record. This differs from DMARC, which does apply to subdomains by default.

Does SPF stop people spoofing my domain?

Not by itself. SPF checks the envelope sender, which the recipient never sees. A message can pass SPF for a domain the sender controls while displaying your domain in the From: header. Only DMARC ties the visible From: address to an authenticated identity, which is why SPF is a component of the answer rather than the whole of it.

Should the record end in ~all or -all?

Start with ~all. Softfail asks receivers to treat unlisted senders with suspicion without rejecting them outright, which gives you room to discover senders you forgot. Move to -all once DMARC reports show that everything legitimate is accounted for.

HighAuthentication

No SPF record found

The domain publishes no SPF record, so receivers have no list of which servers may send mail using it. SPF returns a result of none rather than fail, which means it neither helps nor blocks anything, and under DMARC it removes SPF entirely as a way for your legitimate mail to pass. Anyone can put your domain in the envelope sender of a message and nothing in DNS contradicts them.

Check your own domainSPF checker

What causes this

SPF is a TXT record at your domain listing which mail servers are allowed to send email using your domain in the envelope sender. Without it, a receiving mail server has nothing to compare an incoming message against, so the SPF check returns 'none'. Google, Yahoo and Microsoft all expect bulk senders to publish SPF, and a missing record is one of the first things their filters notice.

What it breaks

Messages from your domain cannot pass SPF. Because DMARC needs either SPF or DKIM to pass with alignment, a missing SPF record also removes one of the two ways your mail can satisfy DMARC.

What the receiving server does

A receiver looks for a TXT record at the exact domain used in the envelope sender (the address in the SMTP MAIL FROM command, not the From: header the recipient sees). Finding no record beginning v=spf1, it records the result as none and moves on. That is not a failure and will not by itself send mail to spam, which is precisely why the problem goes unnoticed: nothing breaks visibly. What is lost is the ability to prove anything. If you later publish DMARC, alignment has to come from DKIM alone, and if DKIM is missing or misaligned then DMARC fails for your own mail.

What a minimal correct record contains

An SPF record is one TXT record at the apex of the domain. It starts with the version tag, lists the senders you authorise, and ends with a policy for everything else. Build it from what actually sends mail on your behalf: the mail platform, and any application or marketing tool that sends using your domain.

tagv=spf1must be first, and identifies this TXT record as SPF

hostinclude:_spf.google.comthe mail platform, added by include

appinclude:sendgrid.netanything else that sends as you

end~allsoftfail: everything not listed above is unauthorised

How to fix it

Publish a TXT record at your domain listing every service that sends mail as you.

List every system that sends email using your domain: your mailbox provider, and any marketing, billing, ticketing or application services.
Find the SPF include value each of those providers documents (for example include:_spf.google.com).
Combine them into a single TXT record at your root domain. There must be exactly one SPF record.
End the record with ~all so unlisted senders are marked as a soft failure while you confirm the list is complete.
After a week with no legitimate mail being marked as a failure, consider tightening ~all to -all.

TXT · @

v=spf1 <one include: per service that sends as you> ~all

This is the shape of the record, not a record to paste. We could not determine which services send as your domain, so we will not guess: replace the placeholder with the include values your own providers document. A wrong include silently de-authorises your real senders.

If you send with

Google Workspace: Publish v=spf1 include:_spf.google.com ~all at the apex. Google has flattened that record to plain IP ranges, so today it costs a single lookup, but do not treat that as permanent, because it has changed before and the number that matters is the one a receiver computes at delivery time. Do not list Google IP addresses individually; the include already covers them and the addresses change.
Microsoft 365: Publish v=spf1 include:spf.protection.outlook.com ~all at the apex. Microsoft has also flattened that record to IP ranges, so it currently costs a single lookup. If you also relay through a connector or an on-premises server, add that source explicitly, because mail leaving from an address Microsoft does not own will not be covered by the include.
A domain that sends no mail at all: Publish v=spf1 -all. That authorises nobody, which is the correct and strongest statement for a domain that never sends. Pair it with a DMARC record at p=reject and null MX to close the domain off properly.

Confirming the fix worked

Publish the record as a TXT record at the apex of the domain: the name is the domain itself, usually entered as @, not spf or _spf.
Confirm you have exactly one record starting v=spf1. A second one is a permanent error, and receivers will not merge them.
Re-run the check above once the TTL has elapsed, and confirm the lookup count is comfortably under ten.
Send a message to an address you control at a different provider and inspect the headers for an Authentication-Results line showing spf=pass.

Common questions

Does having no SPF record mean my email will be rejected?: Usually not on its own. The result is none rather than fail, and most receivers do not reject purely on a missing SPF record. The real cost is that you have no way to prove which servers are yours, and no SPF path for DMARC to pass on.
Where exactly does the SPF record go?: In a TXT record at the apex of the domain: the record name is the bare domain, entered as @ in most DNS panels. It does not go at spf. or _spf. Those names are used inside include statements by providers, but your own record belongs at the apex.
Do subdomains inherit the SPF record from the parent domain?: No. SPF is evaluated against the exact domain in the envelope sender, and there is no inheritance. If mail is sent from mail.example.com, that name needs its own SPF record. This differs from DMARC, which does apply to subdomains by default.
Does SPF stop people spoofing my domain?: Not by itself. SPF checks the envelope sender, which the recipient never sees. A message can pass SPF for a domain the sender controls while displaying your domain in the From: header. Only DMARC ties the visible From: address to an authenticated identity, which is why SPF is a component of the answer rather than the whole of it.
Should the record end in ~all or -all?: Start with ~all. Softfail asks receivers to treat unlisted senders with suspicion without rejecting them outright, which gives you room to discover senders you forgot. Move to -all once DMARC reports show that everything legitimate is accounted for.