SPF checker
An SPF record says which servers are allowed to send email as your domain. Most of the ones that fail do not fail loudly - they fail by quietly letting everyone through. Check a domain you control and get the record and what it actually instructs a receiving server to do.
Watched, not just checked
This is one scan of one layer, run once. In AYAsec the same check runs on a schedule across every asset you own, and you are told the day a grade drops.
What an SPF record is, in one paragraph
When a mail server receives a message claiming to be from your domain, it can ask your domain which servers are permitted to send on your behalf. The answer is a TXT record in your DNS beginning v=spf1. If the sending server is on that list, the message passes. If it is not, what happens next depends entirely on how your record ends - and that is where most of the trouble is.
Six reasons to check your own SPF record
01
The ten-lookup limit, which breaks records silently
This is the failure nobody expects and almost everybody eventually meets.
When a receiving server evaluates your SPF record it has to resolve every include:, a, mx, ptr and redirect it finds - and each of those can contain more of the same. The standard caps this at ten DNS lookups. Exceed it and the evaluation does not fall back to a pass or a fail; it returns a permanent error, and most receivers treat that as no SPF at all.
Records exceed it by growing. A marketing platform here, a helpdesk there, a payroll provider, a new CRM - each adds one include:, and each include: may hide several lookups inside it. Nothing warns you. The record still looks fine in your DNS panel, and delivery starts suffering for reasons nobody connects to a change made four months earlier.
02
A soft fail that authorises nobody and stops nothing
Every SPF record ends with an all mechanism, and the character in front of it decides everything:
| Ending | What it tells the receiver |
|---|---|
-all | Hard fail. This server is not authorised. Reject it |
~all | Soft fail. This server is not authorised, but accept it anyway and mark it |
?all | Neutral. No opinion |
+all | Everyone is authorised. Never correct |
Most domains end with ~all, which is the right place to start and the wrong place to stay. It means your record describes who may send without insisting on it, and that is a statement, not a defence.
03
The include: you added is somebody else's list, and it changes
include: does not copy a provider's servers into your record - it points at theirs and imports whatever is there at the moment of checking.
That is convenient and it means part of your mail authentication is maintained by a company you do not control. When they add infrastructure, your record silently covers more. When they restructure, your lookup count can jump. It is worth knowing which of your include: entries are large, because those are the ones that will push you over the limit.
04
The domain that sends no mail at all
A domain you own and never send from is the easiest of all to impersonate, because nobody is watching the replies and nobody notices the complaints.
Such a domain should still have an SPF record - one that authorises nothing:
v=spf1 -allThat is a complete, correct record. It says: no server is permitted to send as this domain. Parked domains, old brands and domains bought defensively all deserve one.
05
Several records where there should be one
A domain may have exactly one SPF record. Two TXT records both beginning v=spf1 is not twice the protection - it is a permanent error, and the result is the same as having none.
It happens when a second provider's setup wizard adds its own record rather than editing yours. The fix is to merge them into one; the problem is noticing.
06
Evidence that the record was correct on a given date
"We have SPF configured" is an assertion. A dated report showing the record and its policy is evidence, and it is what an insurer or a customer's security review actually wants. Building that record is a subject of its own.
Know the day your record changes
DNS is edited by more people than any other layer, and an SPF record is edited by the ones least likely to tell the security team: marketing adding a sending platform, IT moving a mail provider, a contractor connecting a form.
Each edit is small and none are reviewed. Scheduled scans turn that into a difference you are told about: this record gained an entry, this policy went from -all back to ~all. Alerts arrive in-app, by e-mail, or through Slack, Teams, Jira or a webhook.
Step 01
Name the domain
A domain you control, added to your AYAsec account. Ownership is checked before anything is dispatched - AYAsec will not schedule scans against infrastructure you have not demonstrated control of, and proving it takes one DNS record. The quick check above skips this: no account, no verification, just IP rate-limiting and a rule that the target has to be a public address.
Step 02
Let the check run
SPF records are public, so this reads rather than probes. It looks the record up the way a receiving mail server would.
Step 03
Read the result
Findings arrive ordered by severity and scored A+ to F. A record that authorises everyone and a soft fail are not sitting in the same undifferentiated list.
What this is part of
SPF is one of several mail-related records AYAsec checks as part of its DNS scan, alongside DKIM, DMARC, MTA-STS, TLS-RPT and DNSSEC. It is one scan, and this page is about one part of what it looks at.
DNS carries 20% of the composite grade. The others are HTTP at 30%, TLS and ports at 20% each, and domain credibility at 10%. All of them together are what attack surface management means in practice.
Questions before you check
What may I check?
Infrastructure you own or are contracted to test. The quick check above doesn't verify that for you - it only rate-limits by IP and refuses to target anything but a public address. Add the domain to an AYAsec account instead, and control is verified before anything scheduled runs: a legal boundary as much as a practical one, since an unverified scan is of no use to you as evidence either.
SPF records are public. Why does this need verification?
The record is public and the check is read-only, so the check itself is harmless. Verification is about what happens next: a domain in your AYAsec account is monitored, graded and kept in your history, and none of that should be possible for a domain that is not yours.
Is SPF enough on its own?
No. SPF authorises servers; it does not survive forwarding, and it says nothing about whether the message was altered. That is what DKIM is for, and DMARC is what ties the two together and decides what happens when they fail.
How do I get under the ten-lookup limit?
Usually by removing providers you no longer use, replacing a broad include: with the specific mechanisms you need from it, or flattening the record - resolving the chain yourself and listing the addresses directly. Flattening works and carries a cost: the record stops updating when the provider changes their servers, so it has to be re-flattened on a schedule.
Can one record cover subdomains?
Not automatically. SPF is checked against the domain in the envelope sender, so a subdomain that sends mail needs its own record.
Do you keep the results?
Not the quick check above - it lives in memory for about fifteen minutes so you can read it once, then it's gone. That's a deliberate privacy choice, not a limitation: nobody but you ever sees that scan, and you can download the full result before it expires. Add the domain to an AYAsec account instead, and every scan is kept - a series that tells you which edit broke it. Retention depends on your plan.
Keep the history, not just the result
Run the full DNS check against your own domains, on a schedule, with every change flagged to whoever needs to see it.