DEV Community: Department of Doing Nothing

Your SPF record has a limit of 10 DNS lookups. Here's how to count yours and fix it

Department of Doing Nothing — Fri, 23 Oct 2026 21:40:36 +0000

If your email lands in spam and your SPF record "looks fine", count its DNS lookups. SPF has a hard limit that many domains cross without noticing, usually after adding a newsletter tool, a help desk and a shop platform over the years.

The rule

When a receiving server checks SPF, it may follow at most 10 mechanisms that need a DNS query (RFC 7208, section 4.6.4). These count:

include:
a and mx
ptr and exists:
the redirect= modifier

These do not count: ip4:, ip6: and all.

The count includes everything nested: if you include:_spf.google.com and that record includes three more, that is four lookups, not one.

Go over 10 and the receiver stops with a "permerror". SPF then counts as failed for every message, and DMARC has to rely on DKIM alone.

Count yours

Start with your own record:

dig +short TXT example.com | grep spf1

On Windows: nslookup -type=TXT example.com.

Then look up every include: and redirect= target the same way and add up the counting terms you find at each level:

dig +short TXT _spf.google.com
dig +short TXT spf.protection.outlook.com

A common real-world result: Google Workspace (about 4), Microsoft 365 (2), a newsletter tool (1-2), a help desk (1-2), a shop (1-3), plus a and mx at the top. That is 11-14 before anyone notices.

Fix it

Remove what you no longer use. Old newsletter tools and trial services are the usual culprits.
Drop a and mx unless your web or mail server sends mail itself. Most small businesses send through a provider, so these two lookups do nothing.
Move bulk senders to a subdomain. Send newsletters from news.example.com with its own SPF record; it has its own limit of 10.
Be careful with "flattening" (replacing includes with the IP addresses they contain). It works until your provider changes its addresses, and then mail fails silently. Prefer the steps above.
Keep exactly one SPF record. Two v=spf1 records on the same name are an error by themselves.

Or let a tool count it

I built a free checker that follows the nested includes, counts the lookups and also checks DKIM, DMARC, MTA-STS and DNSSEC: guides.webcareshelf.com/email-check. No signup, and it reads only public DNS.

Disclosure: it's our project. There's an optional $9 report that writes the corrected records for your domain; everything above works without it.

5 boring things that quietly break small-business websites (and how to check each in two minutes)

Department of Doing Nothing — Thu, 22 Oct 2026 15:23:30 +0000

Most small-business websites don't go down because of a clever attack. They go down because of something boring that nobody was watching: a certificate that expired on a Sunday, a domain renewal that failed because the card on file changed, or invoices that land in spam for months before anyone notices.

Here are the five I see most often, with a quick way to check each one yourself. Everything below uses public information only, so you can run it against any site you look after.

1. The TLS certificate expires

When the certificate expires, visitors get a full-page browser warning and most of them leave. Free certificates (Let's Encrypt and most hosting providers) last 90 days or less and depend on automatic renewal, which fails silently more often than you'd think: a DNS change, a moved server or a firewall rule is enough.

Check it:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -enddate

Fix it: make sure automatic renewal is actually on for the domain you are serving (including www), and put the expiry date in a calendar two weeks early as a backup.

2. The domain itself expires

This one is worse than the certificate: when the domain lapses, the website and the email stop working, and in the worst case someone else registers it.

Check it with RDAP, the modern replacement for WHOIS:

curl -sL https://rdap.org/domain/example.com \
  | jq -r '.events[] | select(.eventAction=="expiration") | .eventDate'

Fix it: turn on auto-renew at the registrar, check that the payment card on file is current, and make sure the registrar's emails go to an address someone actually reads.

3. `http://` doesn't redirect to `https://`

Many sites answer on both. People who type the address or follow an old link end up on the unencrypted version, and search engines may see two copies of every page.

Check it:

curl -sI http://example.com | head -n 5

You want a 301 or 308 status and a Location: header that starts with https://.

Fix it: most hosts have a "force HTTPS" switch. Once HTTPS works everywhere, add the Strict-Transport-Security header (HSTS) so browsers stop trying plain HTTP at all. Start with a short max-age and raise it once you're sure.

4. Email goes to spam: missing SPF or DMARC

If the domain has no SPF record, receiving mail servers can't tell which servers may send for it. Without DMARC, anyone can send mail that looks like it comes from your domain, and big providers increasingly send unauthenticated mail straight to spam.

Check it:

dig +short TXT example.com | grep spf1
dig +short TXT _dmarc.example.com

On Windows: nslookup -type=TXT example.com and nslookup -type=TXT _dmarc.example.com.

Fix it:

Publish exactly one SPF record that lists every service that sends for you, for example v=spf1 include:_spf.google.com ~all for Google Workspace. Two SPF records break both of them.
Start DMARC in monitoring mode: v=DMARC1; p=none; rua=mailto:dmarc@example.com. Read the reports for a few weeks, then move to p=quarantine.

5. The search basics are missing

A missing page title or description means search results show whatever text the search engine picks. A missing viewport tag makes the site look broken on phones. No robots.txt or sitemap.xml makes new pages slower to be found.

Check it: open the page source (Ctrl+U) and look for <title>, <meta name="description"> and <meta name="viewport">, then visit /robots.txt and /sitemap.xml.

Fix it: a title of 30 to 60 characters and a description of 50 to 160 characters that say what the business does and where. Most site builders have fields for both.

Bonus: security headers

While you are running curl -sI https://example.com, look for Strict-Transport-Security, X-Content-Type-Options: nosniff, a framing rule (X-Frame-Options or frame-ancestors in a Content-Security-Policy) and Referrer-Policy. None of them is hard to add, and together they block a whole class of cheap attacks.

Or check all of it at once

I got tired of running these by hand for every site, so I built a free checker that does all of the above (19 checks) in about 20 seconds: guides.webcareshelf.com/check. You get a score and the top three problems with no signup, and it doesn't save results.

Disclosure: it's my project. There is an optional $9 full report with every check and a plain-English fix for each problem, and the same key works again after you make the fixes. The commands above give you the same information for free.

If you find a false positive or a check you think is missing, tell me in the comments.

DEV Community: Department of Doing Nothing

Your SPF record has a limit of 10 DNS lookups. Here's how to count yours and fix it

The rule

Count yours

Fix it

Or let a tool count it

5 boring things that quietly break small-business websites (and how to check each in two minutes)

1. The TLS certificate expires

2. The domain itself expires

3. http:// doesn't redirect to https://

4. Email goes to spam: missing SPF or DMARC

5. The search basics are missing

Bonus: security headers

Or check all of it at once

3. `http://` doesn't redirect to `https://`