DEV Community: Håkan Fägnell

SPF Record Checker: How to Test, Read, and Fix Your SPF Record

Håkan Fägnell — Mon, 20 Jul 2026 07:17:43 +0000

Email is still the number-one way attackers break into organisations — and the cheapest trick in the book is pretending to be you. The FBI's Internet Crime Complaint Center logged 193,407 phishing and spoofing complaints in 2024, more than any other crime type, and $2.77 billion lost to business email compromise (IC3 2024 Annual Report). The first line of defence against someone forging your domain is a correctly published SPF record — and the fastest way to know yours is healthy is to run it through an SPF record checker.

This guide explains what SPF is, how to read a record line by line, how to check it manually and with a free tool, and the exact errors a checker catches before they wreck your deliverability.

Quick check: FortifyNet's free 60-second scan validates your SPF, DKIM and DMARC together. Run a free scan and see your email-authentication score instantly.

What is an SPF record?

SPF (Sender Policy Framework) is an email-authentication standard, defined in RFC 7208, that lets a domain owner publish the list of mail servers allowed to send email on behalf of their domain. It lives in DNS as a single TXT record that begins with v=spf1. When a receiving server accepts a message, it looks up that record and checks whether the sending server's IP address is authorised.

A typical record looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net ip4:198.51.100.10 ~all

One crucial nuance: SPF authenticates the envelope sender (the hidden MAIL FROM / Return-Path address), not the From: address your recipients actually see. That gap is exactly why SPF needs DMARC alongside it — more on that below.

Related guides: What is DMARC? · DNS security configuration

Why you need an SPF record checker

Since February 2024, Google and Yahoo have required SPF for every sender, plus full SPF + DKIM + DMARC for anyone sending 5,000 or more messages a day to their users. Microsoft began enforcing the same rules in May 2025 (Red Sift). As of November 2025, Gmail rejects non-compliant bulk mail outright with 550 errors instead of deferring it. A single typo in your SPF record can now mean your invoices, password resets and newsletters bounce — not land in spam, but bounce.

A checker matters because SPF fails silently. Your mail keeps flowing until the day a receiver decides your record is broken — and then it doesn't. Running a checker turns those invisible problems into a clear pass or fail you can act on.

How to read your SPF record

An SPF record is a list of mechanisms (which senders are allowed) and qualifiers (what to do with everyone else).

Common mechanisms are ip4 / ip6 (a specific address or range), a (the domain's A record), mx (its mail servers), include (delegate to another domain's SPF, such as your email provider) and all (matches everything, always placed last).

The qualifier in front of all is the most important character in the entire record:

Qualifier	Symbol	SPF result	What receivers typically do
Pass	`+`	Authorised	Deliver normally
Fail (hardfail)	`-all`	Not authorised	Reject the message
Softfail	`~all`	Probably not authorised	Accept, but mark as suspicious
Neutral	`?all`	No assertion	Deliver; no opinion

Best practice in 2026 is to pair ~all (softfail) with a DMARC p=reject policy. M3AAWG and most deliverability teams now recommend this combination because DMARC becomes the real enforcement layer, while softfail avoids accidentally blocking a forgotten legitimate sender (Valimail). Never publish +all — it authorises the entire internet to send as you.

How to check your SPF record (step by step)

You can inspect any domain's SPF record yourself from a terminal:

macOS / Linux: dig TXT example.com +short
Windows: nslookup -type=TXT example.com

Look for the line that starts with v=spf1. If you see two of them, that is already a problem (see below). Reading the raw record tells you what is published, but it will not count DNS lookups or flag policy mistakes — that is where a dedicated checker earns its keep.

To check SPF, DKIM and DMARC in a single pass, run FortifyNet's free scan: enter your domain and you will get each record parsed, the DNS-lookup count, and a prioritised list of fixes in about a minute.

The 10-DNS-lookup limit (the error most checkers catch)

This is the single most common SPF failure, and it stays invisible until it bites. RFC 7208 states that an SPF evaluation may trigger at most 10 DNS lookups. The include, a, mx, ptr and exists mechanisms and the redirect modifier each count; ip4, ip6 and all do not. Go over 10 and the receiver returns a PermError, which fails SPF for every message you send (DMARCLY).

There is a quieter second cap too: a maximum of 2 "void" lookups (mechanisms that resolve to nothing). A dead include pointing at a discontinued vendor can tip you over it.

It is easy to breach 10 lookups without realising. Each include: for a SaaS vendor (Google, Microsoft 365, a CRM, a help desk, a marketing platform) can itself contain nested includes, so three or four vendors is often enough. The fix is "SPF flattening": replace nested includes with the IP ranges they resolve to, or consolidate vendors.

Common SPF errors an SPF record checker flags

What the checker finds	Result it triggers	How to fix it
More than 10 DNS lookups	PermError	Flatten or remove `include:` entries; consolidate senders
More than 2 void lookups	PermError	Delete includes, `a` or `mx` that resolve to nothing
Two or more SPF records	PermError	Merge everything into one `v=spf1` TXT record
A string over 255 characters	Invalid / truncated record	Split into multiple quoted strings inside the same TXT record
`+all` present	Passes every forgery	Replace with `~all` or `-all` immediately
No `all` mechanism	Ambiguous policy	End the record with `~all` (or `-all`)

The email-authentication gap, in one chart

Most domains still get this wrong. Of 73.3 million domains analysed in December 2025, 83.9% had no DMARC record at all and only 2.5% enforced p=reject — meaning the vast majority can be spoofed with little resistance (DMARC adoption research, 2025). SPF is the foundation that makes the rest possible.

Source: DMARC adoption research, December 2025 (73.3M-domain sample). SPF feeds the DMARC checks shown here.

SPF best-practice checklist

Publish exactly one v=spf1 TXT record per sending domain.
Authorise every legitimate source: your mail host, marketing platform, CRM, ticketing system and any server that sends on your behalf.
Keep total DNS lookups at or under 10; flatten when you add vendors.
End with ~all and back it with DMARC p=reject (or use -all on parked, non-sending domains).
Add SPF for subdomains and parked domains too — attackers love unused ones. A domain that never sends mail should publish v=spf1 -all.
Re-check after every change to your email vendors; SPF drifts as your stack changes.

SPF, DKIM and DMARC: the full picture

SPF on its own is necessary but not sufficient. Three records work together:

SPF authorises sending servers (the envelope sender).
DKIM cryptographically signs each message so it cannot be tampered with in transit.
DMARC ties SPF and DKIM back to the visible From: domain (alignment), tells receivers what to do when authentication fails, and emails you reports.

You need all three to satisfy Gmail, Yahoo and Microsoft — and to actually stop spoofing. Once your SPF passes, continue with our DMARC guide, and use the MXToolbox alternative for ongoing DNS and mail-record checks.

Frequently asked questions

How often should I check my SPF record? After every change to your email providers, and at least once a quarter. SPF silently drifts as you add and drop SaaS tools.

Can I have two SPF records? No. A domain must publish exactly one v=spf1 TXT record; two or more cause a PermError. Combine them into a single record.

Does SPF stop all spoofing? No. SPF only checks the envelope sender, so attackers can still forge the visible From: address. DMARC closes that gap by enforcing alignment — which is why you need both.

What is the difference between ~all and -all? ~all (softfail) tells receivers that unlisted senders are probably unauthorised but to accept and flag them; -all (hardfail) tells them to reject outright. Most senders use ~all plus DMARC enforcement.

Is a free SPF record checker accurate? Yes. A good checker performs the same DNS resolution and lookup counting that a receiving mail server does. FortifyNet's scan also validates DKIM and DMARC in the same pass.

Check your SPF record now

A broken SPF record is invisible until your email stops arriving — and with Gmail, Yahoo and Microsoft now rejecting unauthenticated mail outright, you cannot afford to guess. Run FortifyNet's free 60-second scan to validate your SPF, DKIM and DMARC, count your DNS lookups and get a clear, prioritised fix list. No signup required.

Website Security Checklist: 12 Essential Steps for 2026

Håkan Fägnell — Sat, 18 Jul 2026 08:23:00 +0000

Website Security Checklist: 12 Essential Steps for 2026

Website breaches are no longer a big-company problem. According to IBM's Cost of a Data Breach Report 2025, the global average breach now costs $4.44 million, and in the United States the average hit a record $10.22 million. Meanwhile, the Verizon 2025 Data Breach Investigations Report found that most intrusions still start with the basics: stolen credentials (22% of breaches), exploited vulnerabilities (20%, up 34% year over year) and phishing (16%).

The good news: the majority of those entry points are closed by unglamorous, well-documented hygiene. This website security checklist walks you through 12 checks — from transport encryption and DNS to email authentication and dark-web exposure — roughly in priority order. Most sites can complete the quick wins in a single afternoon.

The checklist at a glance

#	Check	Protects against	Effort	Priority
1	Enforce HTTPS everywhere	Eavesdropping, session hijacking	Low	Critical
2	Monitor certificate expiry	Outages, browser warnings	Low	Critical
3	Harden TLS configuration	Protocol downgrade attacks	Medium	High
4	Set security headers	XSS, clickjacking	Low	High
5	Set up SPF, DKIM and DMARC	Email spoofing, phishing	Medium	Critical
6	Lock down DNS	Hijacking, rogue certificates	Medium	High
7	Patch CMS and plugins	Known-vulnerability exploits	Ongoing	Critical
8	Enforce MFA and strong passwords	Credential stuffing	Low	Critical
9	Automate and test backups	Ransomware, data loss	Medium	Critical
10	Add a WAF and rate limiting	Bots, injection, brute force	Medium	Medium
11	Monitor dark-web exposure	Leaked credential reuse	Low	Medium
12	Monitor uptime and changes	Silent failures, defacement	Low	Medium

1. Enforce HTTPS on every page

Every request — not just the login page — should be served over HTTPS. Redirect all HTTP traffic with a permanent 301 redirect, update internal links and canonicals to https://, and eliminate mixed content (images, scripts or styles still loaded over HTTP), which browsers increasingly block outright. If visitors ever see the "Your connection is not private" interstitial, you lose them before your homepage even loads.

2. Watch certificate expiry — lifetimes are shrinking fast

An expired certificate takes your site down as effectively as any attack. This item is getting harder: under the CA/Browser Forum's ballot SC-081v3, the maximum TLS certificate lifetime dropped to 200 days in March 2026, falls to 100 days in 2027 and lands at just 47 days by 2029. Manual renewal is no longer a sustainable plan.

Automate issuance with an ACME client (Let's Encrypt, or your CA's tooling) and add independent expiry monitoring. You can check your current certificate dates from a terminal:

openssl s_client -connect example.com:443 -servername example.com </dev/null | openssl x509 -noout -dates

3. Harden your TLS configuration

Having a certificate isn't the same as having good TLS. Disable TLS 1.0 and 1.1 entirely, support TLS 1.2 and 1.3 only, and drop legacy cipher suites. A weak configuration invites downgrade attacks and fails compliance scans. Our guide to achieving an A+ SSL/TLS rating covers the exact server settings.

4. Set the core security headers

Security headers are the cheapest hardening you will ever deploy — a few lines of server configuration that instruct browsers to block entire attack classes:

Strict-Transport-Security (HSTS) — forces HTTPS on repeat visits
Content-Security-Policy — your strongest defense against XSS
X-Content-Type-Options: nosniff — stops MIME-type confusion
X-Frame-Options / frame-ancestors — prevents clickjacking
Referrer-Policy and Permissions-Policy — limit data leakage and powerful browser features

See our complete security headers guide for copy-paste nginx and Apache examples.

5. Authenticate your email: SPF, DKIM and DMARC

Your domain sends email even if your website doesn't — and attackers will happily spoof it if you let them. Google and Yahoo have required SPF, DKIM and DMARC for bulk senders since February 2024, and Microsoft applied the same requirements to Outlook in May 2025 for domains sending over 5,000 messages a day. Non-compliant mail is junked or rejected outright.

Publish an SPF record, sign with DKIM, then deploy DMARC starting at p=none to collect reports before tightening to quarantine and reject. Our step-by-step DMARC setup guide walks through the full rollout.

6. Lock down your DNS

DNS is the control plane for everything else on this list. Four checks: enable DNSSEC so responses can't be silently forged; publish a CAA record so only your chosen certificate authority can issue certificates for your domain; turn on registrar lock and MFA at your DNS provider; and prune stale subdomains pointing at decommissioned services — dangling records are a classic subdomain-takeover vector.

7. Patch your CMS, plugins and dependencies

Exploitation of known vulnerabilities was the initial entry point in 20% of breaches in the 2025 DBIR — a 34% jump in one year — and internet-facing, unpatched systems are the prime target. If you run WordPress or another CMS, the attack surface is mostly plugins and themes: enable automatic minor updates, remove anything unused, and subscribe to security advisories for the components you keep.

Stolen credentials, unpatched software and phishing together opened the door in over half of analyzed breaches. Source: Verizon DBIR 2025.

8. Turn on MFA and retire weak credentials

Credential abuse remains the single most common way in (22% of breaches). Enable multi-factor authentication on every account that can change your website: CMS admin, hosting control panel, domain registrar, DNS provider and email. Use a password manager to generate unique passwords, rename or disable default admin accounts, and remove accounts of people who no longer need access.

9. Back up as if you'll be hit tomorrow

Backups are your last line against ransomware and your first line against fat-fingered deletions. Follow the 3-2-1 rule: three copies, on two different media, one off-site — and keep at least one copy offline or immutable so an attacker who owns your server can't encrypt the backups too. A backup you haven't test-restored is a hope, not a plan: schedule a restore drill at least quarterly.

10. Put a WAF and rate limiting in front

A managed web application firewall (from your CDN, host or a service like Cloudflare) filters injection attempts, malicious bots and scanner noise before they reach your application. Add rate limiting on login, signup and API endpoints to blunt credential stuffing and brute force — the attacks feeding item 8.

11. Monitor the dark web for leaked credentials

Your credentials can leak without your site ever being touched — a third-party breach is enough, and password reuse does the rest. Monitor whether accounts on your domain appear in known breach dumps, and when they do, force a reset and confirm MFA is active. Our dark web monitoring guide explains how exposure happens and what to do about it.

12. Monitor uptime, performance and unexpected change

Availability is part of security. Uptime and performance monitoring often provides the earliest signal that something is wrong — an expired certificate, a defaced page, a crypto-mining script dragging response times down. Alerting on unexpected content or configuration changes turns a week of silent compromise into a five-minute incident.

How often should you run through this checklist?

Cadence	What to do
After every deploy	Re-check HTTPS, headers and forms on changed pages
Monthly	Review updates, user accounts, WAF logs and DMARC reports
Quarterly	Full checklist pass, backup restore drill, dependency audit
Annually	Review DNS records, access policies and incident response plan

FAQ

Is HTTPS enough to make my website secure?
No. HTTPS encrypts traffic in transit, but it does nothing against vulnerable plugins, weak admin passwords, spoofed email or leaked credentials. It's step 1 of 12 for a reason — necessary, not sufficient.

What single item gives the biggest security gain?
Combine items 7 and 8: patching known vulnerabilities and enforcing MFA. Together they directly address the two largest breach entry points measured in the 2025 DBIR — 42% of breaches combined.

Do small websites really get attacked?
Yes, constantly — just not personally. Automated scanners probe every reachable IP and domain for expired certificates, outdated plugins and open admin panels. Bots don't check your traffic stats before exploiting you.

How long does the full checklist take?
Items 1, 2, 4 and 8 are typically an afternoon of work. Email authentication and TLS hardening take a few days including DMARC monitoring. The rest are ongoing habits you automate once.

Check all of this in 60 seconds

You could verify each item by hand — or let a scanner do the first pass. The free FortifyNet scan checks your SSL/TLS setup, security headers, DNS configuration, SPF/DKIM/DMARC records, dark-web exposure and performance in about a minute, and tells you exactly which items on this checklist need attention first.

Related guides

Originally published on the FortifyNet blog. FortifyNet is a free 60-second website security audit — I'm the founder, happy to answer questions in the comments.

Website Vulnerability Scanner: What It Checks and How to Read Results

Håkan Fägnell — Sat, 18 Jul 2026 07:37:20 +0000

A website vulnerability scanner is an automated tool that inspects your site the way an attacker would, then tells you where it is exposed before someone else finds out. In the time it takes to read this intro, a good scanner can fingerprint your TLS configuration, parse your security headers, query your DNS and email authentication records, probe for files that should never be public, and cross-reference your domain against known data breaches.

This guide explains what a website vulnerability scanner does, how to read a report without a security background, how to fix the issues that matter most, and how to choose a scanner you can trust. The web is not getting safer on its own: in a 2025 analysis, about 43% of applications had no Content-Security-Policy header at all (HTTP Archive Web Almanac, 2025), and roughly 83.9% of domains still publish no DMARC record (dmarc.org, December 2025). A scan turns those abstract risks into a concrete, fixable list.

A website vulnerability scanner automates the manual checks a security engineer would otherwise run one by one. Photo: Unsplash.

What a website vulnerability scanner does

At its core, a scanner sends a series of harmless requests to your site and inspects the responses. It does not break in or change anything; it observes how your server behaves and compares that to security best practices. Think of it as a home inspection rather than a burglary: it rattles the doors and windows to see which are unlocked, then hands you a report.

Most scanners fall into two families. Passive, non-intrusive scanners (the category FortifyNet's free scan belongs to) analyse what your site already exposes publicly: certificates, headers, DNS, reachable files. Active or authenticated scanners (such as OWASP ZAP or commercial DAST tools) send crafted payloads to find application flaws like SQL injection or cross-site scripting. The two are complementary, but a fast external scan is the right starting point for almost every site owner: no installation, no credentials, no risk to production.

What a scanner checks

A thorough external scan covers six dimensions, each mapping to a different class of real-world attack.

1. TLS/SSL configuration

The scanner connects over HTTPS and inspects your certificate and the encryption protecting traffic between visitors and your server. It flags certificates that are expired, self-signed or about to lapse; deprecated protocols (anything older than TLS 1.2); and weak cipher suites. A broken certificate does not just trigger scary browser warnings, it can break checkout flows and destroy trust. For a deeper walkthrough, see our SSL/TLS certificate security guide.

2. HTTP security headers

Security headers are small instructions your server sends with every page, telling the browser how to behave defensively. The most important are:

Content-Security-Policy (CSP) restricts which scripts and resources can load, the single strongest defence against cross-site scripting.
Strict-Transport-Security (HSTS) forces browsers to use HTTPS and prevents downgrade attacks.
X-Content-Type-Options: nosniff stops the browser reinterpreting files as executable content (OWASP HTTP Headers Cheat Sheet).
X-Frame-Options blocks clickjacking by preventing your site being framed by others.
Referrer-Policy limits how much URL information leaks to third parties; strict-origin-when-cross-origin is a safe default.

These headers are free to add, yet adoption is poor: the same 2025 data found more than 40% of sites missing HSTS entirely. Our HTTP security headers guide covers exact values to deploy.

3. DNS and email authentication

Your DNS records control where mail and traffic go, and they are a favourite target for spoofing. A scanner checks three records that stop criminals sending email that looks like it came from you:

SPF lists the servers allowed to send mail for your domain.
DKIM cryptographically signs your messages so recipients can verify them.
DMARC tells receivers what to do with mail that fails SPF or DKIM, and where to send reports.

Missing DMARC is the norm, not the exception, which is exactly why phishing remains so effective. See our DNS security configuration guide for record-by-record setup.

4. Exposed files and secrets

Scanners probe for files that should never be reachable publicly: .env files holding database passwords and API keys, exposed .git/ directories that leak your entire source history, backup archives and open admin panels. This is not theoretical. A 2024 scan of 10,000 sites found 34% had exposed configuration files (SiteLeak), and GitGuardian detected more than 39 million leaked secrets in 2024 alone (GitGuardian). A single exposed .env can hand an attacker your database within minutes.

5. Dark-web and breach exposure

Even a perfectly configured site can be compromised through credentials leaked elsewhere. This check cross-references your domain against known breach datasets to see whether employee or customer email addresses and passwords are already circulating. If your team reuses a leaked password, no amount of TLS hardening will help, so surfacing that exposure early is essential.

6. Performance

Performance belongs in a security report for two reasons: slow, unoptimised sites often signal outdated software and missing caching or CDN protection, and degraded performance is itself a symptom of many denial-of-service and bot-abuse problems. A scanner measures load time and responsiveness so you catch both user-experience and resilience issues in one pass.

How to read your scan results

A good report ranks findings by severity rather than dumping a raw list. Read it in this order:

Critical and high first. An exposed .env, an expired certificate or a readable .git/ directory can be exploited today. Treat these as emergencies.
Then medium issues. Missing CSP or HSTS, no DMARC, weak ciphers widen your attack surface and should be scheduled within days, not months.
Then low and informational. Sub-optimal cache headers or a missing Referrer-Policy are worth fixing but rarely urgent.

Watch for false positives. External scanners infer behaviour from responses and occasionally flag something intentional (for example, a deliberately permissive CSP on a documentation subdomain). The fix is context: confirm each finding against how your site is actually meant to work before you act. A trustworthy scanner explains why something is flagged and what value it recommends, so you are not left guessing.

What each scan dimension reveals

Scan dimension	What the scanner checks	What a failure reveals	Typical severity
TLS/SSL	Certificate validity, protocol version, cipher strength	Traffic can be intercepted; browser trust warnings	High
Security headers	CSP, HSTS, X-Frame-Options, nosniff	Exposure to XSS, clickjacking, downgrade attacks	Medium-High
DNS & email auth	SPF, DKIM, DMARC records	Your domain can be spoofed in phishing	Medium-High
Exposed files	`.env`, `.git/`, backups, open admin panels	Secrets and source code leak directly	Critical
Dark-web exposure	Domain in known breach datasets	Reused credentials enable account takeover	High
Performance	Load time, responsiveness	Poor UX; may mask DoS or bot abuse	Low-Medium

How to fix the top issues

You can resolve most high-impact findings without specialist help:

Renew or fix your certificate with an automated provider (such as Let's Encrypt) so renewal never lapses again.
Add security headers. Most can be set in your web server config or CDN in a few lines. Start with HSTS and a baseline CSP, then tighten.
Publish SPF, DKIM and DMARC. Begin DMARC at p=none to monitor, then move to quarantine and finally reject once legitimate mail passes.
Remove exposed files. Block access to .env, .git/ and backups at the server level, and rotate any secret that was ever exposed, since it must be considered compromised.
Respond to breach hits. Force password resets and enable multi-factor authentication for any account flagged in a breach.

Re-scan after each change. Security is not a one-time event: configurations drift, certificates expire and new code introduces new exposure, so continuous monitoring beats a single annual audit.

How to choose a website vulnerability scanner

Not all scanners are equal. Look for:

Breadth across all six dimensions, not just headers or just SSL. A partial picture creates a false sense of safety.
Severity-ranked, actionable output that tells you what to fix and how.
Accuracy and low false-positive rates, with clear explanations for each finding.
Continuous monitoring, so you are alerted when something changes rather than discovering it months later.
No-risk, non-intrusive scanning that needs no software installation and cannot harm production.

Free vs. paid scanners

Capability	Free scan	Paid / continuous monitoring
One-off external assessment	Yes	Yes
All six scan dimensions	Often partial	Comprehensive
Scheduled re-scans & alerts	Rarely	Yes
Historical tracking & trends	No	Yes
Multi-site / team management	No	Yes
Cost	Free	Subscription

A free scan is the perfect way to get an honest baseline today; continuous monitoring is what keeps you secure tomorrow.

Frequently asked questions

Is a website vulnerability scanner safe to run on my live site?
Yes, if it is a passive external scanner. It only reads what your site already exposes publicly and sends no attack payloads, so there is no risk to production. Active penetration testing is different and should be scheduled deliberately.

How often should I scan my website?
Run a full scan after every significant change, and enable continuous monitoring so certificate expiries, configuration drift and new breaches are caught automatically. A once-a-year audit leaves long blind spots.

Will a scanner find every vulnerability?
No tool catches everything. External scanners excel at configuration, exposure and authentication issues; deeper application logic flaws need authenticated testing or manual review. A good external scan still eliminates the majority of easily exploited weaknesses.

Do I need technical skills to act on the results?
For the common fixes, no. A clear report tells you what to change and where. Complex application issues may need a developer, but renewing a certificate, adding a header or publishing a DMARC record is well within reach for most site owners.

Run a free scan in 60 seconds

You cannot fix what you cannot see. FortifyNet's free website vulnerability scanner checks your TLS/SSL, security headers, DNS and email authentication, exposed files, dark-web exposure and performance in about 60 seconds, then hands you a severity-ranked report with plain-language fixes. No installation, no risk to your site. See where you stand, then decide what to harden first.

Originally published on the FortifyNet blog. FortifyNet is a free 60-second website security audit — I'm the founder, happy to answer questions in the comments.

"Your Connection Is Not Private": What It Means and How to Fix It

Håkan Fägnell — Fri, 17 Jul 2026 21:18:34 +0000

You click a link, expect a familiar page, and instead Chrome fills the screen with a stark warning: "Your connection is not private." Below it sits a cryptic code like NET::ERR_CERT_AUTHORITY_INVALID. Whether you are a visitor trying to reach a site or the owner watching traffic evaporate, the error is almost always fixable in minutes — once you know which of a handful of causes is behind it.

The warning is not malware, and it does not mean you have been hacked. It means your browser tried to establish an encrypted HTTPS connection and could not verify the website's SSL/TLS certificate. Because the certificate is the site's identity document, the browser refuses to load the page rather than risk sending your data to an impostor.

This guide explains what triggers the warning, how visitors can clear it in seven quick steps, and how site owners can diagnose and permanently fix it — plus why an industry-wide change to certificate lifetimes means you will see this error more often from 2026 onward.

What the warning actually means

More than 95% of pages loaded in Chrome are served over HTTPS, according to Google's Transparency Report. HTTPS does two jobs: it encrypts traffic, and it proves the server really is the one named in the address bar. That proof comes from the TLS certificate, which your browser validates on every single connection. Three checks must all pass:

Trust — the certificate was issued by a certificate authority (CA) your device trusts.
Validity — today's date falls inside the certificate's validity window.
Identity — the domain in the address bar matches a name listed in the certificate.

If any check fails, the browser blocks the page and shows the interstitial instead. Encryption without verified identity is worthless — an attacker on public Wi‑Fi could otherwise silently decrypt everything you send.

The same error in every browser

Each browser words the warning differently, but the underlying certificate problem is identical.

Browser	Warning text	Typical error codes
Chrome	"Your connection is not private"	`NET::ERR_CERT_AUTHORITY_INVALID`, `NET::ERR_CERT_DATE_INVALID`
Edge	"Your connection isn't private"	Same `NET::ERR_CERT_*` codes as Chrome
Firefox	"Warning: Potential Security Risk Ahead"	`SEC_ERROR_EXPIRED_CERTIFICATE`, `SEC_ERROR_UNKNOWN_ISSUER`
Safari	"This Connection Is Not Private"	Plain-language description, no code

The code at the bottom of the warning is the most useful diagnostic you have:

NET::ERR_CERT_DATE_INVALID — the certificate has expired, or your device clock is wrong.
NET::ERR_CERT_AUTHORITY_INVALID — the issuing CA is not trusted: a self-signed certificate, an incomplete certificate chain, or antivirus/proxy interception.
NET::ERR_CERT_COMMON_NAME_INVALID — the certificate does not cover this exact domain, e.g. it covers www.example.com but not example.com.
NET::ERR_CERT_REVOKED — the CA has withdrawn the certificate, often after a key compromise.

If you're a visitor: 7 fixes, fastest first

Reload, then try an incognito/private window. This rules out a stale cached certificate or a misbehaving extension.
Check your device's date and time. A clock that is off by months makes every valid certificate look expired or not yet valid. Enable automatic time. This alone resolves a large share of DATE_INVALID errors.
On public Wi‑Fi, log in to the network first. Hotel and airport captive portals hijack requests until you authenticate, which breaks HTTPS. Visit a plain-HTTP site such as http://neverssl.com to force the login page to appear.
Update your browser and operating system. Root certificates ship with OS and browser updates; very old devices no longer know the CAs modern sites use — the fate of many pre-7.1.1 Android phones after Let's Encrypt's root transition.
Temporarily disable HTTPS scanning in your antivirus. Security suites that inspect encrypted traffic re-sign it with their own certificate; when that goes wrong you get AUTHORITY_INVALID on every site. If the warning disappears, re-enable the feature and update or reconfigure the antivirus.
Clear your browser's cache and SSL state. In Chrome: Settings → Privacy and security → Clear browsing data.
Still failing on one specific site — from every device and network? Then the problem is the site's, not yours. Do not click "Proceed"; on a login or payment page, that is exactly the risk this warning exists to prevent.

If it's your website: diagnose, fix, automate

First, see what the certificate actually says. From any terminal:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

Or skip the command line: a free FortifyNet scan reads your certificate, chain, and TLS configuration in about 60 seconds and tells you exactly what is wrong.

Cause	Typical code	Permanent fix
Expired certificate	`DATE_INVALID`	Renew now, then automate renewal (ACME/Certbot)
Incomplete chain (missing intermediate)	`AUTHORITY_INVALID` — often only on mobile	Serve the full chain (`fullchain.pem`, not `cert.pem`)
Name mismatch	`COMMON_NAME_INVALID`	Reissue with SANs for apex + `www`; wildcard if needed
Self-signed certificate in production	`AUTHORITY_INVALID`	Replace with a CA-issued certificate — Let's Encrypt is free
Revoked certificate	`ERR_CERT_REVOKED`	Reissue with a new private key

With Let's Encrypt securing hundreds of millions of sites at no cost, there is no reason to run production on a self-signed certificate. A typical setup on nginx:

sudo certbot --nginx -d example.com -d www.example.com
sudo certbot renew --dry-run

Certbot installs the certificate with its full chain and schedules automatic renewal — the single most effective protection against ever showing this warning.

Why this error is about to get more common

In April 2025 the CA/Browser Forum passed Ballot SC-081v3, a schedule that shrinks the maximum lifetime of public TLS certificates from 398 days to just 47 days by 2029, as DigiCert explains. Since 15 March 2026, no public CA may issue a certificate valid for longer than 200 days; in March 2027 the cap drops to 100 days, and in March 2029 to 47.

The practical consequence: a site renewing certificates by hand needs to do it at least twice a year today, and roughly eight times a year from 2029. Every manual step is a chance to forget — which is why automation plus expiry monitoring is now the baseline, not a nice-to-have.

FAQ

Is it ever safe to click "Proceed anyway"?
Only when you know exactly why the warning appears and no sensitive data is involved — for example, your own router's admin panel using a self-signed certificate. Never on banking, email, shopping, or any login page.

Why do I see the warning when nobody else does?
That points to a local cause: a wrong clock, aggressive antivirus, a captive portal, or an outdated OS that lacks modern root certificates. Work through visitor steps 1–6 above.

Why does my site show the error only on phones?
A classic sign of an incomplete certificate chain. Desktop browsers often cache missing intermediates; mobile browsers are stricter. Configure your server to send the full chain.

Does the warning affect SEO and traffic?
Directly: most visitors leave immediately, since the interstitial takes two deliberate clicks to bypass. Indirectly: HTTPS is a Google ranking signal, and prolonged certificate failures depress crawling and conversions alike.

Related guides

Catch certificate problems before your visitors do

The warning your visitors see is the last symptom of a problem that was detectable weeks earlier. Run a free FortifyNet scan — 60 seconds, no signup — and get a plain-English report on your certificate expiry, chain, TLS configuration, security headers, DNS, and email authentication.

Originally published on the FortifyNet blog. FortifyNet is a free 60-second website security audit — I'm the founder, happy to answer questions in the comments.

How to Set Up DMARC, Step by Step (From p=none to p=reject)

Håkan Fägnell — Wed, 15 Jul 2026 08:15:00 +0000

Anyone can put your domain in the From field of an email. Without DMARC, a scammer can send fake invoices, password resets or CEO-fraud messages that look exactly like they came from you — and many receiving servers will deliver them. DMARC closes that door, and the world's largest mailbox providers have stopped treating it as optional: Gmail and Yahoo have required it for bulk senders since February 2024, and Microsoft began rejecting non-compliant high-volume mail in May 2025.

This guide walks you through the whole setup: your first monitoring record in about 15 minutes, then a safe, staged path to full enforcement. No mail gets lost along the way if you follow the stages in order.

What a DMARC record actually does

DMARC (Domain-based Message Authentication, Reporting and Conformance, defined in RFC 7489) is a TXT record in your DNS that builds on two other standards, SPF and DKIM. It tells every receiving mail server three things:

How to verify that mail claiming to be from your domain really is — the From domain must align with the domain that passed SPF or DKIM.
What to do when verification fails — nothing (p=none), send it to spam (p=quarantine), or refuse it outright (p=reject).
Where to send reports about everything it saw, so you get visibility into every service sending as your domain — legitimate or not.

If you want the concepts in more depth, read our guide What is DMARC and why is it important? — this article is the hands-on rollout.

Before you start: three prerequisites

Access to your DNS. You will add TXT records at your DNS host (Cloudflare, your registrar, Route 53, etc.).
A working SPF record. It lists which servers may send mail for your domain. Verify yours with our SPF record guide.
DKIM enabled in every sending service. Each service cryptographically signs your mail. Google Workspace, Microsoft 365, Mailchimp, HubSpot, Zendesk and most invoicing platforms all have a DKIM or "domain authentication" setting — turn it on everywhere.

Take five minutes to inventory everything that sends email as your domain: mail platform, newsletter tool, CRM, helpdesk, billing system, website contact forms. Every one of them must eventually authenticate, or enforcement will bite you later.

You can check your current state from any terminal:

dig TXT yourdomain.com +short
dig TXT _dmarc.yourdomain.com +short

On Windows, nslookup -type=TXT _dmarc.yourdomain.com does the same job. If the second query returns nothing, you have no DMARC record yet — which is exactly what we are about to fix.

Step 1: Publish a monitoring-only record (p=none)

Create a TXT record with these values at your DNS host:

Host/Name: _dmarc
Type:      TXT
Value:     v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

The record lives at _dmarc.yourdomain.com — most DNS panels only ask for the _dmarc part. Three practical notes:

Use a dedicated mailbox (or alias) for rua. Aggregate reports arrive daily from every major receiver and will clutter a personal inbox fast.
Publish exactly one DMARC record. Two records at _dmarc means receivers ignore both.
p=none changes nothing about delivery. It is pure observation mode — the safe starting point for every domain, no matter how messy your email setup is.

DNS propagation usually takes minutes, occasionally a few hours depending on TTL.

The DMARC tags that matter

Tag	What it does	Recommended
`v`	Protocol version	`DMARC1` (mandatory, must be first)
`p`	Policy for your domain	`none` → `quarantine` → `reject` over time
`rua`	Where aggregate reports go	`mailto:` address you actually check
`ruf`	Forensic (per-message) reports	Skip it — most receivers no longer send these
`sp`	Policy for subdomains	Set `sp=reject` at the final stage
`adkim`	DKIM alignment mode	`r` (relaxed, default) is right for most
`aspf`	SPF alignment mode	`r` (relaxed, default) is right for most
`pct`	% of failing mail the policy applies to	Use for ramping quarantine (25 → 50 → 100)
`fo`	Failure-report options	Leave default unless debugging DKIM

Step 2: Read the reports and fix what fails (2–6 weeks)

Within a day or two, aggregate reports (XML files) start arriving from Gmail, Yahoo, Microsoft and others. Each one lists the IP addresses that sent mail using your domain, how many messages, and whether they passed SPF, DKIM and — crucially — alignment: the From domain matching the domain that actually passed. Relaxed alignment accepts subdomains (mail.yourdomain.com aligns with yourdomain.com); strict requires an exact match.

The typical findings, in order of frequency:

A newsletter or CRM tool signs with its own domain, not yours. Fix: enable custom-domain DKIM (often called "domain authentication") inside that tool.
A server or SaaS tool is missing from SPF. Fix: add its include or IP to your SPF record.
Forwarded mail fails SPF. Expected — forwarding rewrites the sending IP. As long as DKIM survives (it usually does), aligned DKIM keeps the mail passing DMARC.

At low volume you can read the XML by hand; beyond a few reports a day, a report analyzer saves real time. Give this phase two to six weeks — long enough to catch monthly senders like invoicing runs.

Step 3: Tighten to quarantine

Once reports show all legitimate sources passing with alignment for several consecutive weeks, step up:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@yourdomain.com

Failing mail now lands in spam folders — for 25% of failures. Raise pct to 50, then 100 over a few weeks while watching the reports. One caveat: some receivers apply the policy to all mail regardless of intermediate pct values, so treat the ramp as a convenience, not a guarantee — and don't camp at pct=25 for months.

Step 4: Move to reject and cover subdomains

The destination — spoofed mail is refused outright:

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@yourdomain.com

sp=reject closes the subdomain loophole (invoices.yourdomain.com, hr.yourdomain.com) that attackers probe next. Two final habits: keep the rua address alive forever — reports are how you notice when a new tool starts sending unauthenticated — and put parked domains that never send mail straight at p=reject with a restrictive SPF (v=spf1 -all). Scammers love forgotten domains.

The deadlines that made DMARC mandatory

Provider	In force	Applies to	Minimum requirement
Gmail	Feb 2024, rejections since late 2025	5,000+ msgs/day to Gmail	SPF + DKIM + DMARC (`p=none` or stronger), aligned From, one-click unsubscribe, spam rate < 0.3%
Yahoo/AOL	Feb 2024	5,000+ msgs/day	Same core set: SPF + DKIM + DMARC with alignment
Outlook.com / Hotmail / Live	May 5, 2025 — non-compliant mail rejected (error 550 5.7.515)	5,000+ msgs/day to consumer accounts	SPF + DKIM + DMARC at least `p=none`, aligned with SPF or DKIM

Below 5,000 messages a day you escape the letter of these rules, but not their spirit: the same providers still weigh authentication heavily in spam filtering for everyone, and the thresholds have only moved in one direction.

Most domains stop halfway — don't

EasyDMARC's 2026 adoption report, analyzing 1.8 million domains, found 52% now publish a DMARC record (up from 47.7% in 2025) — but 56% of those never move past p=none. Monitoring mode satisfies the mailbox providers' checkbox, yet blocks nothing: a spoofed invoice still lands in your customer's inbox. Meanwhile 95% of the Fortune 500 publish DMARC and more than 80% of them enforce it.

Share of DMARC-enabled domains by policy level, 2026 (source: EasyDMARC adoption report).

Common mistakes

Two DMARC records at _dmarc — receivers must ignore both. Merge into one.
A typo in the rua address — you fly blind for weeks before noticing.
Publishing the record at the root instead of the _dmarc host — it is simply never found.
Jumping straight to p=reject without a monitoring phase — the fastest way to lose your own newsletter or invoices.
Forgetting subdomains — without sp=, subdomains inherit p=, but check that this is what you want at each stage.
Treating p=none as done — it proves you exist; it protects nothing.

Frequently asked questions

I send fewer than 5,000 emails a day. Do I still need DMARC?
Yes. Spoofing doesn't check your volume — small companies are prime targets for invoice fraud precisely because they lack enforcement. The bulk-sender rules are a floor, not the definition of who benefits.

How long does the whole rollout take?
Typically 4–12 weeks from first record to p=reject, driven mostly by how many sending services you must fix during monitoring. A domain with one mail platform can move in a month.

Will DMARC improve my deliverability?
Aligned SPF/DKIM/DMARC is now part of how Gmail, Yahoo and Microsoft score senders, so yes — properly authenticated domains see fewer spam-folder placements. The reverse is also true: broken authentication increasingly means rejection.

What's the practical difference between quarantine and reject?
quarantine delivers failing mail to the spam folder — recipients can still find it. reject refuses it at the door — the strongest protection and the end goal for domains that have cleaned up their senders.

Do I need a paid tool to read the reports?
Not at low volume — the XML is human-readable. Once multiple reports arrive daily, a free or paid analyzer pays for itself in time saved.

Check your email authentication in 60 seconds

Not sure where your domain stands right now? Run the free FortifyNet scan — it checks your SPF, DKIM and DMARC records (including policy strength and common syntax errors), plus SSL/TLS, security headers and dark-web exposure. One minute, no signup, and you'll know exactly which step of this guide to start at.

Related guides

Originally published on the FortifyNet blog. FortifyNet is a free 60-second website security audit — I'm the founder, happy to answer questions in the comments.

What Is HSTS? HTTP Strict Transport Security Explained

Håkan Fägnell — Sun, 12 Jul 2026 11:40:00 +0000

Your site probably redirects to HTTPS already, and the padlock shows up just fine. But every time a returning visitor types your address without https://, their browser still sends one unencrypted HTTP request before your redirect kicks in. On hostile networks — airport Wi-Fi, hotel hotspots, a compromised router — that single request is the opening an attacker needs. HTTP Strict Transport Security (HSTS) closes it for good: one response header that tells browsers to never speak plain HTTP to your domain again.

The gap is real: according to W3Techs (July 2026), 90.1% of all websites now default to HTTPS, but only 34.1% send an HSTS header. Nine sites in ten encrypt; barely one in three actually enforces it.

What is HSTS?

HSTS (HTTP Strict Transport Security) is a web security policy mechanism standardized in RFC 6797 back in 2012. It consists of a single HTTP response header:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

When a browser receives this header over a valid HTTPS connection, it remembers — for max-age seconds — that your host is HTTPS-only. From that moment:

Every http:// link, bookmark, or typed address for your domain is rewritten to https:// inside the browser (an internal 307 redirect), before a single packet leaves the device.
Certificate warnings on your site become non-bypassable: no "Proceed anyway" link. If the certificate is broken — or someone is intercepting the connection — the browser refuses, full stop.

All major browsers — Chrome, Edge, Firefox, Safari — have supported HSTS for roughly a decade, on desktop and mobile.

Why an HTTPS redirect alone isn't enough

A classic 301 redirect from HTTP to HTTPS happens server-side — the browser must first send the plain-HTTP request, and an attacker sitting between your visitor and your server sees it before your redirect ever answers. That is exactly how SSL stripping works, a downgrade attack demonstrated by Moxie Marlinspike back in 2009: the attacker silently keeps the victim on HTTP while talking HTTPS to the real server, reading everything in transit.

Protection	301 redirect only	HSTS	HSTS + preload
Later visits upgraded before any network request	❌	✅	✅
The very first visit protected	❌	❌	✅
Certificate errors non-bypassable	❌	✅	✅
Defeats SSL stripping (downgrade attacks)	❌	✅ after first visit	✅ always

What each level of HTTPS enforcement actually protects.

Keep the redirect — you still need it for first-time visitors and for preload eligibility — but understand what it cannot do alone.

How HSTS works, step by step

First visit. The browser loads https://example.com, the response carries the Strict-Transport-Security header, and the policy is cached.
Every visit after that. Any attempt to reach http://example.com is upgraded internally to HTTPS. A packet capture on the network would show no plaintext request at all.
The timer slides. Each new HTTPS response containing the header resets max-age, so regular visitors stay protected indefinitely.
Hard failure on bad certificates. Expired, self-signed, or man-in-the-middle certificates produce an error page that cannot be clicked through.

The three directives

Directive	Required?	What it does	Recommended value
`max-age`	Yes	How long (in seconds) the browser enforces HTTPS-only	`31536000` (1 year); `63072000` (2 years) is also common
`includeSubDomains`	For preload	Extends the policy to every subdomain	Only after confirming all subdomains serve HTTPS
`preload`	For preload	Opts in to browsers' built-in preload list	After running at a 1-year `max-age` without issues

How to enable HSTS on your server

Add the header only in the HTTPS configuration — browsers ignore HSTS sent over plain HTTP, as required by the spec.

nginx (inside the server block that listens on 443):

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Apache (with mod_headers enabled, in the HTTPS vhost):

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

IIS (web.config):

<httpProtocol>
  <customHeaders>
    <add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains" />
  </customHeaders>
</httpProtocol>

Cloudflare: SSL/TLS → Edge Certificates → HTTP Strict Transport Security (HSTS) → Enable, then set max-age and subdomain options in the dashboard.

Then confirm the header is actually served: open your site, check the Network tab in your browser's DevTools, and look for strict-transport-security among the response headers — or simply run the free FortifyNet scan, which flags a missing or weak HSTS policy.

Roll it out gradually

A mistaken HSTS policy locks visitors out of any broken HTTP-only resource for the full remaining max-age — you cannot take it back remotely except by serving max-age=0 over valid HTTPS to each affected browser. Ramp up instead:

Stage	Header value	Hold for
1 — Test	`max-age=300`	A day or two
2 — Short	`max-age=86400`	A week
3 — Medium	`max-age=2592000`	A month
4 — Full	`max-age=31536000; includeSubDomains`	3+ months
5 — Preload	`max-age=31536000; includeSubDomains; preload`	Permanent

HSTS preload: closing the first-visit gap

Plain HSTS is trust on first use: the very first request from a brand-new visitor is still unprotected until the first header arrives. The preload list fixes that — your domain ships inside the browser itself as HTTPS-only, so even visit number one never touches plain HTTP.

Submission is free at hstspreload.org (the Chromium-maintained list, also consumed by Edge, Firefox, and Safari). The requirements:

A valid TLS certificate.
HTTP redirects to HTTPS on the same host (port 80 → 443).
The HSTS header served on the HTTPS response of the base domain with max-age of at least 31536000 (1 year), plus both includeSubDomains and preload.
Every subdomain — including www — reachable over HTTPS.

Treat preload as a one-way door. Removal from the list takes months to propagate through browser releases. Do not preload until every subdomain — including internal ones like intranet. or mail. — has working HTTPS.

Adoption in 2026: HTTPS everywhere, enforcement lagging

HTTPS is near-universal, yet only about a third of sites enforce it with HSTS (source: W3Techs, July 2026).

Browsers are pushing hard in the same direction. In Chrome 147 (April 2026), Google enabled "Always Use Secure Connections" for the 1 billion+ users with Enhanced Safe Browsing, and with Chrome 154 (October 2026) it becomes the default for everyone: Chrome will attempt HTTPS first and warn before loading public HTTP sites.

Does that make HSTS obsolete? No. Chrome's warning is bypassable by the user; HSTS is your server's own non-bypassable guarantee. It works in every browser regardless of settings, covers all your subdomains, and blocks certificate click-through. The two complement each other.

Common HSTS mistakes

Enabling includeSubDomains blind — one forgotten HTTP-only subdomain (intranet, staging, a printer portal) becomes unreachable for the whole max-age.
Sending the header over HTTP — harmless but useless; browsers ignore it.
A max-age of a few minutes in production — near-zero protection, and it fails preload requirements.
Forgetting HSTS after a server or CDN migration — the policy silently expires and nobody notices.

Frequently asked questions

Does HSTS replace my HTTP→HTTPS redirect?
No. Keep the redirect: first-time visitors need it, and the preload list requires it.

Can I undo HSTS?
Serve Strict-Transport-Security: max-age=0 over HTTPS and browsers drop the policy on their next visit. Preload removal is much slower — months — which is why you ramp up carefully.

Does HSTS affect SEO?
Only positively: it guarantees users and crawlers land on one canonical HTTPS version of your site. There is no downside for rankings.

How do I know if my site sends HSTS?
Check the response headers in your browser's DevTools (Network tab) for strict-transport-security — or run a free FortifyNet scan, which checks HSTS along with the rest of your security headers.

Is HSTS all I need?
It is one of several headers a hardened site sends. Pair it with Content-Security-Policy, X-Content-Type-Options and friends — see our complete security headers guide.

Check your HSTS in 60 seconds

The free FortifyNet scan tests your SSL/TLS setup, HSTS and all other security headers, DNS and email authentication, and dark-web exposure — in about a minute, no signup required. If HSTS is missing or misconfigured, you will see exactly what to fix.

Related guides

Originally published on the FortifyNet blog. FortifyNet is a free 60-second website security audit — I'm the founder, happy to answer questions in the comments.

Best Semrush Alternatives in 2026 (For Website Security & Audits)

Håkan Fägnell — Tue, 30 Jun 2026 08:20:10 +0000

Originally published on the FortifyNet blog. Reposting here for the community.

Why Look for a Semrush Alternative?

Semrush is genuinely powerful. If you're a digital marketing agency managing keyword rankings, backlink profiles, and competitor analysis, it's hard to beat. But for many website owners, it's overkill — and overpriced.

Common frustrations that drive people to search for alternatives:

Price: Semrush starts at $139.95/month. That's steep if you just want to audit your website.
Complexity: The platform has 50+ tools. Finding what you need takes time.
Security blind spots: Semrush focuses on SEO. It won't tell you about your SSL expiry, GDPR compliance gaps, or dark web leaks.
Wrong tool for the job: If you need a security audit, you don't need keyword rankings.

What Semrush Actually Does Well

Before comparing, let's be honest about Semrush's strengths:

Keyword research — world-class database
Backlink analysis — large, frequently updated index
Technical SEO audit — crawls your site for broken links, redirect issues, crawlability
Competitive intelligence — see what competitors rank for
Content marketing tools

What it doesn't cover:

SSL certificate health
Security headers
DNS configuration
Dark web monitoring
GDPR / NIS2 compliance posture
JavaScript secret exposure
Real-time security monitoring

Top Semrush Alternatives in 2026

1. FortifyNet ⭐ (Best for Technical Security Audits)

If the reason you're considering Semrush is to run website audits — not rank keywords — then FortifyNet is built exactly for that use case.

What it does:

Full technical website audit (SSL, DNS, security headers, performance, compliance)
Continuous monitoring with automated alerts when issues are detected
Dark web leak monitoring for your domain and company emails
GDPR and NIS2 compliance scoring
Exposure scan (JavaScript secrets, exposed files, cloud bucket leaks)
Multi-domain management for agencies

Pros:
✅ Purpose-built for security audits, not SEO keyword fluff
✅ Actionable recommendations with severity ratings
✅ Continuous monitoring — not just a point-in-time snapshot
✅ Affordable: starts at free trial, paid plans significantly cheaper than Semrush
✅ Covers what Semrush misses: SSL, headers, dark web, GDPR
✅ Clean UI — no 50-tool overwhelm
✅ Ideal for agencies managing multiple client websites

Cons:
❌ No keyword research or backlink analysis
❌ Not an SEO content marketing tool
❌ Newer platform than Semrush

Verdict: If your goal is "I want to know everything wrong with my website from a security and technical perspective," FortifyNet wins outright. Start your free audit →

2. Ahrefs

Ahrefs is arguably Semrush's closest competitor — focused on backlinks and keyword research.

Pros:
✅ Excellent backlink index (some say better than Semrush)
✅ Good keyword explorer
✅ Site audit tool for technical SEO
✅ Slightly cheaper than Semrush ($129/month)

Cons:
❌ Still expensive for non-SEO professionals
❌ Zero security features (no SSL, headers, dark web)
❌ Not built for non-marketers
❌ Limited free tier

3. Moz Pro

Moz was one of the original SEO tools and still holds its own for domain authority tracking.

Pros:
✅ Good Domain Authority (DA) metric widely used in industry
✅ Solid site crawl for technical SEO issues
✅ More approachable than Semrush/Ahrefs for beginners

Cons:
❌ Smaller keyword/backlink database than Semrush
❌ No security features
❌ Pricing similar to competitors

4. Screaming Frog SEO Spider

A technical SEO crawler loved by developers and SEO specialists.

Pros:
✅ Very detailed technical crawl
✅ Free up to 500 URLs
✅ Runs locally — fast

Cons:
❌ Desktop software, not cloud-based
❌ No monitoring or alerting
❌ No security, SSL, or compliance features
❌ Requires technical knowledge to interpret

5. Ubersuggest (Neil Patel)

Pros:
✅ Much more affordable
✅ Good for beginners
✅ Lifetime deal available

Cons:
❌ Smaller data sets than Semrush/Ahrefs
❌ Limited technical SEO depth
❌ No security features

Feature Comparison Table

Feature	FortifyNet	Semrush	Ahrefs	Moz Pro	Screaming Frog
SSL analysis	✅	❌	❌	❌	❌
DNS audit	✅	❌	❌	❌	❌
Security headers	✅	❌	❌	❌	❌
Dark web monitoring	✅	❌	❌	❌	❌
GDPR compliance	✅	❌	❌	❌	❌
Technical SEO audit	✅	✅	✅	✅	✅
Keyword research	❌	✅	✅	✅	❌
Backlink analysis	❌	✅	✅	✅	❌
Continuous monitoring	✅	❌	❌	❌	❌
Price	Free trial / low	$139.95/mo	$129/mo	$99/mo	Free / £259/yr

The Real Difference: SEO vs. Security Audits

Semrush is built for marketers. FortifyNet is built for website owners who want to know their site is safe, fast, and compliant.

These are genuinely different needs:

Use Semrush (or Ahrefs) if you:

Are an SEO professional or agency
Need keyword ranking data
Manage backlink outreach campaigns
Compete in content marketing

Use FortifyNet if you:

Want to audit your website's security posture
Need to verify SSL, DNS, and security headers are correct
Must demonstrate GDPR/NIS2 compliance to clients or auditors
Want continuous monitoring instead of periodic manual checks
Manage multiple client websites and need one dashboard

Many teams actually use both — Semrush for SEO, FortifyNet for security. And since FortifyNet is significantly cheaper, the combined cost is often less than Semrush alone.

FAQ

How much does Semrush cost?

Semrush starts at $139.95/month for the Pro plan. Business plans can exceed $449/month. Annual billing offers a discount.

What is the best free Semrush alternative?

For technical website audits, FortifyNet's free trial is the most comprehensive option covering security, performance, DNS, and SSL. Screaming Frog offers a free tier for up to 500 URLs if you specifically need a technical SEO crawl.

Can FortifyNet replace Semrush?

For security audits, yes. For SEO keyword research and backlink analysis, no — they serve different purposes. FortifyNet covers the security blind spots that Semrush leaves entirely open.

Does Semrush check SSL certificates?

No. Semrush's site audit checks technical SEO factors like broken links and missing meta tags. It does not audit SSL certificates, HSTS configuration, or security headers.

Is FortifyNet good for agencies?

Yes. FortifyNet supports multi-domain management, making it ideal for agencies managing security and performance for multiple client websites simultaneously.

What technical SEO issues does FortifyNet check?

FortifyNet checks performance (Core Web Vitals via PageSpeed API), DNS configuration, SSL/TLS settings, security headers (CSP, HSTS, X-Frame-Options, etc.), server exposure, and compliance indicators — all the technical foundations that affect both security and SEO.

Try FortifyNet free → | See all features → | Compare plans →

Best MX Toolbox Alternatives in 2026 (Honest Review)

Håkan Fägnell — Tue, 30 Jun 2026 08:15:22 +0000

Originally published on the FortifyNet blog. Reposting here for the community.

Why People Search for MX Toolbox Alternatives

MX Toolbox has been around for years. It's a go-to for IT admins who need quick DNS lookups, MX record checks, and blacklist monitoring. But times change. Modern websites need more than just email diagnostics — they need full-stack security awareness.

If you've landed here, you're probably frustrated with one of these:

MX Toolbox's free tier limitations
Lack of actionable security recommendations
No continuous monitoring
No performance or SSL insights in one place

Let's walk through the real alternatives, including their pros, cons, and pricing.

What Does MX Toolbox Actually Do?

Before comparing alternatives, let's be fair. MX Toolbox is genuinely useful for:

MX record lookups — quickly check where your email routes
Blacklist checks — see if your IP or domain appears on spam lists
SPF/DKIM/DMARC validation — essential for email deliverability
DNS propagation checks

But it stops there. There's no SSL monitoring, no security headers check, no performance scoring, and no dark web monitoring. It's a specialist tool in a world that now needs generalists.

Top MX Toolbox Alternatives

1. FortifyNet ⭐ (Best Overall)

FortifyNet is a full-stack website and domain security platform built for the modern web. It goes far beyond what MX Toolbox offers.

What it does:

DNS health check (including MX, SPF, DKIM, DMARC)
Blacklist monitoring across 80+ providers
SSL/TLS certificate analysis with expiry alerts
Security headers audit (CSP, HSTS, X-Frame-Options, etc.)
Performance scoring using real metrics
Dark web leak monitoring
GDPR/NIS2 compliance checks
Continuous automated monitoring with alerts

Pros:
✅ All-in-one platform — no juggling 5 different tools
✅ Actionable recommendations, not just raw data
✅ Continuous monitoring with email alerts
✅ Clean, modern UI designed for non-technical users too
✅ Covers compliance requirements (GDPR, NIS2)
✅ Affordable plans starting at free trial

Cons:
❌ Newer platform, so fewer community forum discussions
❌ Not focused solely on email/DNS (by design — it does much more)

Verdict: If you want to replace MX Toolbox and reduce 4–5 other tools, FortifyNet is the obvious choice. Start your free audit →

2. MXToolbox (The Original)

Fair is fair — let's put MXToolbox itself in context.

Pros:
✅ Very fast DNS lookups
✅ Good blacklist database
✅ Free tier available
✅ Long history and trusted by IT professionals

Cons:
❌ No SSL monitoring
❌ No security headers checks
❌ No performance insights
❌ Alert system requires paid plan
❌ UI feels dated compared to modern alternatives
❌ No GDPR/compliance context

3. DNSChecker.org

A solid free tool for DNS propagation checks globally.

Pros:
✅ Free and simple to use
✅ Good global DNS propagation view

Cons:
❌ Zero security recommendations
❌ No monitoring capabilities
❌ No SSL, performance, or compliance checks

4. Dmarcian

Focused specifically on DMARC reporting and email authentication.

Pros:
✅ Deep DMARC analytics
✅ Good for large email senders

Cons:
❌ Very narrow focus — only email auth
❌ Can be expensive for small teams
❌ No website security features

5. Sucuri SiteCheck

A website scanner focused on malware detection.

Pros:
✅ Good malware scanning
✅ Reputation check included

Cons:
❌ No DNS/email diagnostics
❌ Limited free checks
❌ No performance or headers analysis

Feature Comparison Table

Feature	FortifyNet	MXToolbox	DNSChecker	Dmarcian
MX / DNS checks	✅	✅	✅	❌
SPF / DKIM / DMARC	✅	✅	❌	✅
Blacklist check	✅	✅	❌	❌
SSL monitoring	✅	❌	❌	❌
Security headers	✅	❌	❌	❌
Performance score	✅	❌	❌	❌
Dark web monitoring	✅	❌	❌	❌
GDPR compliance	✅	❌	❌	❌
Continuous monitoring	✅	✅ (paid)	❌	✅ (paid)
Price (entry)	Free trial	Free / $49/mo	Free	$199/mo

Why FortifyNet Is the Best MX Toolbox Alternative in 2026

The digital threat landscape in 2026 isn't just about email anymore. A misconfigured DNS record is serious. But so is an expired SSL certificate, a missing Content Security Policy header, or your company domain showing up in a dark web data dump.

MX Toolbox solves one slice of the problem. FortifyNet solves the whole picture — and it does it with continuous monitoring, so you're not relying on manually running checks.

For agencies, consultants, and businesses managing multiple websites, FortifyNet's multi-domain support makes it significantly more cost-effective than stitching together 4–5 point solutions.

Try FortifyNet free → | See all features → | Compare plans →

FAQ

Is MX Toolbox free?

MX Toolbox offers a free tier for basic lookups. Advanced monitoring, alerts, and API access require a paid subscription starting at around $49/month.

What is the best free MX Toolbox alternative?

FortifyNet offers a free trial that includes DNS checks, SSL analysis, security headers, and performance scoring — making it the most comprehensive free starting point.

Can FortifyNet replace MX Toolbox?

Yes. FortifyNet covers all DNS and email security checks MX Toolbox offers, plus SSL, performance, security headers, dark web monitoring, and GDPR compliance — in one dashboard.

Does FortifyNet check blacklists?

Yes. FortifyNet checks your domain and IP against 80+ blacklist providers as part of its standard DNS audit.

What is DMARC and why does it matter?

DMARC (Domain-based Message Authentication, Reporting & Conformance) is a protocol that tells receiving mail servers what to do with emails that fail SPF or DKIM checks. It protects your domain from being used in phishing attacks. Both MX Toolbox and FortifyNet can validate your DMARC setup.

Is FortifyNet GDPR compliant?

FortifyNet is built with GDPR and NIS2 compliance in mind. It not only helps you check your own site's compliance posture but also operates transparently regarding data it processes.