SPF Record
Email from your domain gets junked or spoofed without sender authentication. SaaSalyst checks your DNS for an SPF record — the baseline policy that tells receiving servers which senders may use your domain.
What SaaSalyst Checks
SaaSalyst queries DNS TXT records at your registrable domain and looks for a v=spf1 policy. Present passes; absent warns. The scanner cannot know whether your domain SENDS mail, so the check is warn-only at low severity — absence is surfaced, never punished as a failure.
Why This Matters
A SaaS that sends anything — receipts, magic links, onboarding — lives and dies by inbox placement, and SPF is the first of the three authentication records (SPF, DKIM, DMARC) receivers evaluate. Without it, your transactional mail starts at a deliverability disadvantage and your domain is trivially spoofable in phishing campaigns aimed at your own customers.
How to Fix It
- Add a TXT record at your root domain: v=spf1 include:<your-email-provider> ~all (your provider documents its include token).
- Consolidate to ONE SPF record — multiple v=spf1 records are invalid.
- Verify with: dig TXT yourdomain.com +short — then add DMARC next (see the DMARC check).
Frequently Asked Questions
My marketing site sends no email — do I need SPF?
Still yes, defensively. SaaSalyst warns rather than fails precisely because it cannot see your mail flows, but a null policy (v=spf1 -all) on a non-sending domain prevents anyone from spoofing it — a two-minute DNS edit.
Is SPF alone enough for deliverability?
No. SaaSalyst checks SPF and DMARC separately because receivers evaluate the set: SPF authorizes senders, DKIM signs content, and DMARC tells receivers what to do on failure. Major inbox providers now expect all three from senders.
Check Your SaaS Now | Free
SaaSalyst scans your website in 30 seconds and checks for SPF Record along with 118+ other business readiness signals.
Scan Your App