DEV Community: Håkan Fägnell

ERR_CERT_DATE_INVALID: Fix It on Any Device | FortifyNet

Håkan Fägnell — Mon, 14 Sep 2026 04:46:19 +0000

NET::ERR_CERT_DATE_INVALID is Chrome's way of saying the website's certificate is not valid right now: either the certificate has expired (or is not yet valid), or the clock on your own device is wrong, so a perfectly good certificate looks expired. Google's own data shows the second cause is far more common than most people expect: on Windows, a wrong system clock is behind 33.5% of all Chrome certificate warnings, versus 4.23% for certificates that have really expired (Acer et al., ACM CCS 2017). This guide shows you how to tell the two apart in under a minute, how to fix each one as a visitor or a site owner, and how to stop the error coming back.

What NET::ERR_CERT_DATE_INVALID actually means

Every TLS certificate carries two timestamps: a start date (notBefore) and an end date (notAfter). When Chrome, Edge or any Chromium-based browser opens an HTTPS connection, it compares those two dates with the current time as reported by your device. If "now" falls outside that window, the browser refuses to trust the certificate and shows a full-page warning with the code NET::ERR_CERT_DATE_INVALID.

There are only three ways to land outside the window, and they point at different people:

Situation	Whose problem	What Chrome shows
Your device clock is wrong (usually years behind)	The visitor	"Your clock is behind" or "Your clock is ahead", with no option to proceed
The site's certificate has expired	The site owner	"Your connection is not private", NET::ERR_CERT_DATE_INVALID
The certificate was issued minutes ago and your clock is slightly behind	Both	"Your connection is not private", NET::ERR_CERT_DATE_INVALID

Other browsers report the same underlying condition under different names. Firefox uses SEC_ERROR_EXPIRED_CERTIFICATE for an expired certificate and MOZILLA_PKIX_ERROR_NOT_YET_VALID_CERTIFICATE for one whose start date is still in the future. Safari shows "This Connection Is Not Private" and mentions the expiry only in the details. The fixes below apply to all of them.

Visitor or website owner? Find out in 30 seconds

Before changing anything, work out which side of the connection is wrong:

Open two or three other HTTPS sites. If they all show the same warning, the problem is your device, almost certainly its clock. If only one site fails, the problem is on that server.
Look at the date in your taskbar or menu bar. A device that has just replaced its battery or sat unused for months often boots with a date years in the past. If the year is wrong, you have found the cause.
Check the site from another device or network. If your phone on mobile data opens the site without a warning, your computer is the odd one out.
If you own the site, check the certificate from outside. A free FortifyNet scan reads the live certificate from the internet and shows its exact notBefore and notAfter dates, independent of any device clock.

Why this error is more often your clock than the website

Google and Carnegie Mellon researchers studied more than 300 million Chrome certificate warning reports to find out what really triggers them. The result, published as "Where the Wild Warnings Are" at ACM CCS 2017, is striking: on Windows, an incorrect system clock caused 33.5% of all certificate warnings, eight times more than certificates that had really expired. On macOS the split was 8.71% versus 4.39%, and on Android 8.46% versus 2.73%.

Share of Chrome certificate warning reports caused by a wrong device clock versus a genuinely expired or not yet valid server certificate, by operating system. Source: Acer et al., "Where the Wild Warnings Are", ACM CCS 2017, Table 1.

Two more details from the same study matter for the fix. Nearly all wrong clocks were in the past, not the future: the client clock was more than 24 hours behind in 6.7% of reports and more than 24 hours ahead in only 0.05%. And when a certificate had genuinely expired, it was usually a recent lapse: 57% of expired certificates had expired less than 30 days earlier, which is the signature of a renewal that somebody forgot, not a site that was abandoned.

The Chrome team used this data to build the "Your clock is behind" screen you may have seen. It first relied on a simple heuristic that compared the system time with the browser's build date, which caught only 68% of clock errors. In May 2017 Chrome shipped a secure time service that asks a Google server for the real time when it sees a date error, raising detection to 96%. When Chrome shows the clock-specific screen, 53% of users fixed their clock before dismissing it, compared with 3.9% when they only saw the generic warning. That screen deliberately has no "proceed anyway" link, so the only way past it is to correct the clock.

Fix ERR_CERT_DATE_INVALID as a visitor

Windows 10 and 11

Open Settings, go to Time & language, then Date & time. Turn on "Set time automatically" and "Set time zone automatically", then click "Sync now" under Additional settings. If the clock drifts again after every restart, the CMOS battery on the motherboard is probably flat; the researchers named dying CMOS batteries as one likely reason so many Windows clocks are wrong. From an administrator command prompt you can also force a resync with w32tm /resync.

macOS

Open System Settings, then General, then Date & Time, and turn on "Set time and date automatically". Make sure the time zone is also set automatically. If the option is greyed out, disconnect from any VPN first and try again.

Android and iPhone

On Android, open Settings, then System, then Date & time, and enable "Set time automatically" (some manufacturers call it "Use network-provided time"). On iPhone and iPad, go to Settings, General, Date & Time, and enable "Set Automatically". A device that has been powered off for a long time or had its SIM removed can boot with a stale date.

If the clock is right and the error persists

Old devices and expired roots. Certificates are trusted through a chain that ends at a root certificate on your device, and roots expire too. When the cross-signed Let's Encrypt chain expired on 30 September 2024, devices running Android 7.0 and earlier stopped trusting sites that use Let's Encrypt certificates, while Android 7.1 and newer, which already trusted ISRG Root X1 directly, were unaffected (Let's Encrypt). On a device that cannot be updated, Firefox is often the workaround, because it ships its own root store instead of using the operating system's.
Antivirus HTTPS scanning. Security products that inspect HTTPS traffic install their own root certificate and re-sign every site you visit. The CCS 2017 study traced a wave of date errors on properly configured sites to antivirus software whose own root certificate had expired. Temporarily disabling HTTPS or "web shield" scanning tells you whether that is the cause; updating the product usually fixes it.
Update the browser and clear the SSL state. An outdated browser may lack newer root certificates. On Windows, Internet Options, Content, "Clear SSL state" clears cached certificates that Chrome and Edge share with the system.

Fix ERR_CERT_DATE_INVALID as a site owner

If visitors are reporting the error and the site fails from more than one device, the certificate itself is the problem. Work through these steps:

Step 1: read the real dates. Query the certificate the server is actually serving with OpenSSL:

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

The output prints notBefore and notAfter. If notAfter is in the past, the certificate has expired. If notBefore is in the future, it is not yet valid.

Step 2: renew and reload. With an ACME client such as Certbot, sudo certbot renew obtains a new certificate, but the web server keeps serving the old one from memory until you reload it (sudo systemctl reload nginx or the Apache equivalent). Our renewal guide covers every major platform and CDN.

Step 3: check the whole chain. Your leaf certificate can be valid while an intermediate in the chain has expired. Deploy the full chain the CA gave you (fullchain.pem, not cert.pem), and check every endpoint that terminates TLS: the origin server, the load balancer and the CDN edge can each hold a different copy.

Step 4: beware the "not yet valid" trap. A certificate that becomes valid at the exact minute it is issued will fail for every visitor whose clock is even slightly behind. The CCS study recorded a spike in clock-related warnings on Windows in September 2016 when Google rolled out newly issued certificates at short notice. Most public CAs now backdate the start time slightly for this reason, but if you run a private CA, set notBefore at least an hour in the past.

Step 5: verify from outside. There is no propagation delay for certificates. As soon as the server is reloaded, an external scan shows the new dates.

Cause	How to recognise it	Who fixes it	Fix
Certificate expired	notAfter in the past; error on every device	Site owner	Renew, install full chain, reload server
Certificate not yet valid	notBefore in the future; error for some visitors right after deployment	Site owner	Wait, or issue with a backdated start time
Intermediate or root expired	Leaf looks fine, chain check fails	Site owner (or CA)	Install the updated chain
Device clock wrong	Every HTTPS site fails; Chrome says "Your clock is behind"	Visitor	Enable automatic time, replace CMOS battery
Old device missing new roots	Only newer sites or certain CAs fail	Visitor	Update OS, or use a browser with its own root store
Antivirus root expired	Error on well-configured sites, disappears when HTTPS scanning is off	Visitor	Update or reconfigure the security product

Why date errors will get more frequent, not less

Certificate lifetimes are shrinking. Under CA/Browser Forum ballot SC-081v3, the maximum lifetime of a public TLS certificate dropped from 398 to 200 days on 15 March 2026, falls to 100 days in March 2027 and to 47 days in March 2029 (CA/Browser Forum). Let's Encrypt is moving its default from 90 to 45 days (Let's Encrypt). Every renewal is a chance to miss the deadline, so a site that renews by hand will meet NET::ERR_CERT_DATE_INVALID several times a year. Automating issuance with ACME, configuring the reload hook, and monitoring expiry from outside are no longer optional.

Related guides

"Your connection is not private": what it means and how to fix it covers the warning page this error appears on.
SSL certificate expired: what happens and how to fix it fast goes deeper on the server-side cause.
How to renew an SSL certificate walks through renewal on every major platform.
ERR_CERT_AUTHORITY_INVALID: causes and fixes handles the chain errors that often follow a rushed renewal.

FAQ

Is NET::ERR_CERT_DATE_INVALID dangerous?
Usually not, but Chrome cannot tell a harmless clock error from an attack, so it blocks the page. Fix the clock or wait for the site to renew instead of clicking through, especially on banking or login pages.

Why does Chrome say "Your clock is behind" on one site but "connection is not private" on another?
Chrome only shows the clock-specific screen when its secure time check confirms your clock is wrong. If the check cannot complete within three seconds, or the difference is small, you get the generic warning with the same error code.

Can I bypass the error?
On the generic warning you can click Advanced and proceed, unless the site uses HSTS, which removes that option. On the "Your clock is behind" screen there is no bypass by design; correcting the clock is the only way through.

My clock is correct and only one site fails. What now?
The site's certificate has expired or its chain is broken. Nothing on your device will fix that; tell the site owner, or check the site's certificate dates yourself with an external scan.

How do I stop this happening on my own site?
Automate renewal with ACME, configure the deploy hook that reloads the server, and monitor expiry from outside with alerts at 30, 14 and 7 days.

Check your certificate dates before your visitors do

A wrong clock is the visitor's problem; an expired certificate is yours. Run a free FortifyNet scan to see your certificate's exact validity dates, the full chain, protocol configuration, security headers, DNS and email authentication in about 60 seconds. No signup required.

Sources: Acer et al., "Where the Wild Warnings Are: Root Causes of Chrome HTTPS Certificate Errors", ACM CCS 2017; Let's Encrypt, Shortening the Chain of Trust; CA/Browser Forum, Ballot SC-081v3; Let's Encrypt, From 90 to 45.

Originally published at fortifynet.com/blog/err-cert-date-invalid. I'm the founder of FortifyNet, a website security scanner; this article comes from our blog, so factor in that founder bias when you read any tool recommendations here.

How to Read DMARC Reports (Aggregate XML Guide) | FortifyNet

Håkan Fägnell — Fri, 11 Sep 2026 04:46:27 +0000

To read a DMARC report, open the compressed XML attachment, look at policy_published to confirm which policy receivers applied, then go through every record block: the source_ip and count tell you who sent how much, policy_evaluated gives the DMARC verdict, and auth_results shows the raw SPF and DKIM results underneath it. A row that passes SPF or DKIM but fails DMARC has an alignment problem. A row that fails everything is either a forgotten sender or someone spoofing you. This guide walks through a real report field by field, shows the seven patterns you will see most often, and explains what to do about each one.

What a DMARC report actually is

Every mail receiver that supports DMARC (Google, Microsoft 365, Yahoo, Mail.ru, Fastmail, Zoho and many others) counts the messages it sees claiming your domain in the From header. Once per UTC day it packs those counts into an XML file, compresses it, and emails it to the address in the rua= tag of your DMARC record. These are aggregate reports, sometimes called RUA reports. They contain no message content, only counts per sending IP with the authentication results for each.

Per RFC 9990, published by the IETF in May 2026 as the Standards Track specification for aggregate reporting, the reporting period is typically a single UTC day starting at 0000 UTC, the XML must be gzip compressed in normal circumstances, and each report covers exactly one policy domain. Reports arrive whether your policy is p=none, p=quarantine or p=reject. They are the only feedback loop DMARC gives you, and reading them is the difference between enforcing safely and blocking your own invoices.

Of the top 1.8 million domains, 937,931 (52.1%) publish DMARC, over 553,000 collect aggregate reports, and 411,935 enforce. Only around 9% do both. Source: EasyDMARC, 2026 DMARC Adoption Report, 30 March 2026.

The gap in that chart is the problem this article solves. EasyDMARC's March 2026 study of the top 1.8 million domains found that only about 9% of domains combine an enforcement policy with reporting. A separate DMARCguard scan of 5,499,028 Tranco domains on 27 February 2026 found that 776,918 of the 1,670,975 DMARC domains (46.5%) have no rua= tag at all. Most domain owners who do receive reports never open them, because raw XML looks hostile. It is not. There are only three sections.

Step 1: open the attachment

A genuine report email has a subject like Report Domain: example.com Submitter: google.com Report-ID: 1234567890 and a single attachment. RFC 9990 section 3.5.2 fixes the filename format as receiver!policy-domain!begin-timestamp!end-timestamp.xml.gz, for example google.com!example.com!1757462400!1757548799.xml.gz. The two numbers are Unix timestamps for the start and end of the reporting window, so you can tell the covered day before you open anything.

Decompress it on the command line:

gunzip google.com!example.com!1757462400!1757548799.xml.gz

Some senders, including Microsoft, use zip instead of gzip. In that case use unzip on the file. To pretty-print the result for reading:

xmllint --format google.com!example.com!1757462400!1757548799.xml

Any text editor works too. What you will see is a single feedback element containing report_metadata, policy_published and one or more record blocks.

Step 2: read the three sections

Here is a report trimmed to one record, using the structure from RFC 9990 Appendix B:

<feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0">
  <version>1.0</version>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <report_id>1757548799.example.com</report_id>
    <date_range>
      <begin>1757462400</begin>
      <end>1757548799</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>quarantine</p>
    <sp>none</sp>
  </policy_published>
  <record>
    <row>
      <source_ip>192.0.2.123</source_ip>
      <count>123</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <envelope_from>example.com</envelope_from>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>example.com</domain>
        <result>pass</result>
        <selector>abc123</selector>
      </dkim>
      <spf>
        <domain>example.com</domain>
        <result>fail</result>
      </spf>
    </auth_results>
  </record>
</feedback>

Older reports use the namespace http://dmarc.org/dmarc-xml/0.1 from RFC 7489. The fields are the same, so read them the same way.

Element	What it tells you	How to use it
`report_metadata` / `org_name`	Which receiver generated the report	Group findings per receiver; Google and Microsoft together usually cover most of your volume
`date_range`	Unix timestamps of the covered window	Match spikes to campaigns or incidents on that day
`policy_published`	Your DMARC record as the receiver read it	If `p` differs from what you published, DNS had not propagated or you have two records
`source_ip`	The IP that delivered the message to the receiver	Reverse-lookup it; this is your sender inventory
`count`	Messages from that IP with identical results	Big counts are your real mail streams; tiny counts are noise or probes
`policy_evaluated` / `dkim` and `spf`	Aligned DKIM and aligned SPF results	This is the DMARC verdict, after alignment, not the raw check
`disposition`	What the receiver did: `none`, `quarantine`, `reject`, or `pass` in RFC 9990 reports	Tells you what actually happened to the mail
`reason`	Why a receiver overrode your policy	`mailing_list`, `trusted_forwarder`, `local_policy`, `policy_test_mode` or `other`
`header_from`	The domain in the visible From header	The domain that DMARC is protecting in this row
`envelope_from`	The RFC5321.MailFrom domain SPF checked	If it differs from `header_from`, SPF cannot align
`auth_results` / `dkim`	Raw DKIM result, signing domain and selector	A pass here with a fail in `policy_evaluated` means the `d=` domain is not yours
`auth_results` / `spf`	Raw SPF result and the domain checked	A pass here with a fail above means the envelope domain is not aligned

The one distinction that trips up almost everyone: auth_results is the raw check, policy_evaluated is the check after alignment. DMARC only counts SPF or DKIM as passing if the authenticated domain matches your header_from domain. A marketing platform signing with its own domain will show DKIM pass in auth_results and DKIM fail in policy_evaluated. That is not a broken signature. It is an unaligned one.

Step 3: classify every row

Once the fields make sense, reading a report is pattern matching. These seven patterns cover nearly every row you will encounter.

#	What the row shows	Most likely cause	What to do
1	SPF aligned pass, DKIM aligned pass, high count	Your own mail server or a correctly configured service	Nothing. This is the target state
2	SPF aligned pass, DKIM fail or missing	A service you authorised in SPF that is not signing with your domain	Enable DKIM at that service and publish its CNAME or TXT selector
3	SPF fail, DKIM aligned pass, `envelope_from` is another domain	Forwarding, a mailing list, or a platform using its own bounce domain	Normal. DMARC still passes. Do not add the forwarder to SPF
4	Raw DKIM pass with signing domain not yours, aligned DKIM fail	Third-party sender signing with its own default key	Ask the vendor for a custom signing domain (a CNAME under yours)
5	Raw SPF pass for `envelope_from`, aligned SPF fail	Vendor uses its own return-path domain	Set a custom return-path or bounce domain at the vendor, or rely on DKIM
6	Everything fails, `source_ip` belongs to a cloud or hosting range you do not recognise, count in the hundreds or thousands	Spoofing or a phishing campaign using your domain	Leave it failing. Move toward `p=reject` so receivers drop it
7	Everything fails, low count, `reason` says `mailing_list` or `trusted_forwarder`	Receiver exempted the message from your policy	Informational. Nothing to fix on your side

For a row you cannot place, reverse-lookup the IP with dig -x 192.0.2.123 +short or host 192.0.2.123, then check the SPF include for your suspected vendor. A PTR record ending in outbound.protection.outlook.com, google.com, amazonses.com, sendgrid.net or mailgun.org usually points straight at the responsible service.

Reading reports at volume

A domain with a few senders produces a handful of files a day, and hand reading works. Above that, use an analyser. A typical analyser ingests the rua= mailbox, decompresses each file, and rolls the rows up by source, so you see "Microsoft 365: 12,400 messages, 100% aligned" rather than forty XML files. Free options exist, and FortifyNet's own scan will tell you whether a rua= tag is even present and syntactically correct.

Two habits matter more than the tool. First, watch policy_published after every DNS change: receivers cache DMARC records, so a report covering the day you changed p= may show the old policy, and RFC 9990 section 3.3 explicitly allows a mix. Second, keep reading after you reach p=reject. New SaaS tools, rotated DKIM keys and edited SPF records all show up as a new pattern 2, 4 or 5 row the next day, long before your customers notice bounces.

What RFC 9990 changed for readers

The May 2026 standard, which obsoletes the reporting parts of RFC 7489 from 2015, matters if you parse reports yourself or evaluate a vendor.

Field or rule	RFC 7489 (2015)	RFC 9990 (2026)
XML namespace	`http://dmarc.org/dmarc-xml/0.1`	`urn:ietf:params:xml:ns:dmarc-2.0`
DKIM `selector`	Optional	Required whenever a DKIM result is reported
`disposition` values	none, quarantine, reject	Adds `pass`
Override reasons	forwarded, sampled_out, trusted_forwarder, mailing_list, local_policy, other	local_policy, mailing_list, other, policy_test_mode, trusted_forwarder
`discovery_method`	Not present	Optional: `psl` or `treewalk`
`generator`	Not present	Optional name and version of the reporting software
`envelope_from`	Optional	Optional, may be empty for bounces with a null sender
Unknown elements	Undefined	Must be ignored, not treated as errors

Every major receiver still sends legacy-shaped reports in September 2026, and will for a long time. Read both formats the same way and never discard a report because it has a field you do not recognise.

FAQ

Why do I get DMARC reports for mail I never sent?
Because someone else is sending it. Aggregate reports cover every message that claimed your domain in the From header, including spoofed ones. A row with a high count, an unknown IP and failures on both SPF and DKIM is exactly the spoofing you set up DMARC to catch.

How many reports should I expect per day?
One per reporting receiver per day per domain, so typically 3 to 15 files for a small business. RFC 9990 sets the period to a single UTC day. Very large receivers may split a day into several files.

What does disposition none mean when I have p=quarantine?
Either the message passed DMARC, so no policy applied, or the receiver overrode your policy and the reason element says why. Check policy_evaluated: if both aligned results are pass, none is the correct disposition.

Do DMARC reports contain email content or personal data?
Aggregate reports contain sending IPs, counts and authentication results, nothing from the message body or headers beyond the From domain. Failure reports (RUF, defined in RFC 9991) can contain headers and are rarely sent by major providers.

Can I stop receiving reports?
Remove the rua= tag and receivers stop within a day. You lose all visibility into spoofing and misconfiguration when you do, so pointing rua= at an analyser is the better option.

Check whether your reports are even arriving

Before you spend an evening with XML, it helps to know whether your DMARC record asks for reports at all, whether the rua= address is authorised, and whether SPF and DKIM are set up on the senders you already know about. FortifyNet's free scan reads your DMARC, SPF and DKIM records and flags what is missing in about 60 seconds, with no signup. Run a free scan at FortifyNet.

Originally published at fortifynet.com/blog/how-to-read-dmarc-reports. I'm the founder of FortifyNet, a website security scanner; this article comes from our blog, so factor in that founder bias when you read any tool recommendations here.

How to Renew an SSL Certificate (2026 Guide) | FortifyNet

Håkan Fägnell — Sat, 05 Sep 2026 04:46:45 +0000

How to Renew an SSL Certificate: Step-by-Step Guide for 2026

To renew an SSL certificate, you generate a fresh certificate for the same domain before the old one expires, install it on your server or platform, and confirm the new expiry date. If you use Let's Encrypt, one command (certbot renew) does all of it and a timer runs it for you twice a day. If you bought a certificate from a commercial CA, you create a new CSR, complete domain validation again, download the new files and swap them in. This guide covers both paths, plus hosting panels and CDNs, and shows how to verify the renewal worked.

The stakes are rising. Since 15 March 2026 no public CA may issue a certificate valid for more than 200 days, and the cap drops to 47 days in 2029 (CA/Browser Forum ballot SC-081v3, approved April 2025). Renewal is no longer a once-a-year chore. It is becoming a continuous process, and the only realistic way to keep up is automation.

Why SSL certificate renewal matters more in 2026

An expired certificate does not degrade gracefully. Browsers block the page with a full-screen warning (NET::ERR_CERT_DATE_INVALID in Chrome), API clients fail their TLS handshake, and email and monitoring integrations start throwing errors. A single forgotten renewal took down Microsoft Teams for roughly three hours on 3 February 2020 (TechCrunch), and an expired certificate in Ericsson equipment knocked out mobile data for millions of O2 and SoftBank customers on 6 December 2018 (The Register).

Shorter lifetimes multiply the number of renewals you have to get right. The table below shows the industry schedule that every public CA must follow.

Effective date	Maximum certificate validity	Maximum domain-validation reuse	Source
Before 15 March 2026	398 days	398 days	CA/B Forum Baseline Requirements
15 March 2026 (in force now)	200 days	200 days	SC-081v3
15 March 2027	100 days	100 days	SC-081v3
15 March 2029	47 days	10 days	SC-081v3

Let's Encrypt, which reported serving more than 700 million websites and issuing over ten million certificates on a single day in late 2025 (Let's Encrypt, 9 December 2025), is moving faster than the mandate: its default profile switches from 90-day to 64-day certificates on 10 February 2027 and to 45-day certificates on 16 February 2028 (Let's Encrypt, 2 December 2025).

Renewals per year for one certificate at each maximum lifetime (365 divided by the lifetime in days). Sources: CA/Browser Forum SC-081v3; Let's Encrypt, 2 December 2025. A site with ten certificates on 47-day lifetimes needs about 78 successful renewals a year.

Step 1: Find out how your certificate was issued

The renewal method depends entirely on where the certificate came from. Run this on the server to see the issuer and expiry date:

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

The issuer line tells you which path to follow.

Issuer shown	Typical setup	How you renew
Let's Encrypt (R10, R11, E5, E6 etc.)	Certbot, acme.sh, Caddy, Traefik	Automated via ACME; check the timer, never renew by hand
DigiCert, Sectigo, GlobalSign, GoDaddy	Purchased DV/OV/EV certificate	New CSR, re-validate domain, install new files
cPanel, Inc. or Sectigo via AutoSSL	Shared hosting with cPanel	Automatic; check the SSL/TLS Status page
Cloudflare, Google Trust Services, Amazon	CDN or cloud edge certificate	Managed by the platform; confirm DNS or CNAME validation still resolves
Your own company name	Internal CA	Reissue from your PKI; not covered here

Step 2a: Renew a Let's Encrypt certificate with Certbot

Let's Encrypt certificates are valid for 90 days today and Certbot's packaged timer tries to renew them twice a day, renewing only when fewer than 30 days remain (Certbot documentation). If a site is showing an expired Let's Encrypt certificate, the automation has been failing for at least a month.

First list what Certbot knows about:

sudo certbot certificates

Then test a renewal without touching anything:

sudo certbot renew --dry-run

If the dry run passes, run the real renewal and reload your web server:

sudo certbot renew
sudo systemctl reload nginx

Certbot will say "Cert not yet due for renewal" if more than 30 days remain; that is normal. To renew early regardless (for example after changing the key size), add --force-renewal to a single certificate with certbot renew --cert-name example.com --force-renewal, but never leave it in a cron job, because Let's Encrypt rate-limits duplicate certificates to 5 per week.

Check that the timer is active so this keeps happening without you:

systemctl list-timers | grep certbot

Two changes since 2025 matter here. Let's Encrypt stopped sending expiry-warning emails on 4 June 2025 and deleted the addresses it held (Let's Encrypt, 26 June 2025), so nobody will nudge you. And modern ACME clients can ask the CA for a suggested renewal window through ACME Renewal Information (ARI, RFC 9773), which Certbot uses from version 2.9 onward. Keep the client updated so that it follows ARI rather than a hard-coded interval; Let's Encrypt explicitly warns that renewing at a fixed 60 days will not survive the move to 45-day certificates.

Step 2b: Renew a purchased certificate (DigiCert, Sectigo, GoDaddy and others)

Commercial certificates cannot be "extended". Renewal means the CA issues a brand-new certificate, so the process mirrors the original order.

Generate a new private key and CSR on the server. Reusing the old key is allowed but weakens the security benefit of renewing.

openssl req -new -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csr -subj "/CN=example.com"

Submit the CSR in the CA portal under Renew or Reissue. Most CAs let you start 30 to 90 days early and carry the remaining days over.
Complete domain validation again. Since 15 March 2026 a validation can only be reused for 200 days, so expect an email, HTTP file or DNS TXT challenge on almost every renewal. OV and EV certificates also need organisation checks; start those two weeks ahead.
Download the certificate and the intermediate chain. Missing intermediates cause ERR_CERT_AUTHORITY_INVALID on some devices even when the leaf certificate is fine.
Install and reload. Replace the certificate and chain files referenced in your server config, keep the new key alongside, and reload the service. On nginx that is ssl_certificate and ssl_certificate_key; on Apache, SSLCertificateFile and SSLCertificateKeyFile.
Update every copy. Load balancers, mail servers, CDN origins and monitoring probes often hold their own copy of the same certificate.

Step 2c: Renew on hosting panels, CDNs and cloud platforms

Platform	What renews it	What can break renewal	Where to check
cPanel AutoSSL	Daily cron on the host	Domain not pointing at the server, .htaccess blocking /.well-known/	SSL/TLS Status in cPanel
Plesk (Let's Encrypt extension)	Built-in scheduled task	Same as above; expired domain	Websites and Domains, SSL/TLS Certificates
Cloudflare Universal SSL	Cloudflare, automatically	Proxy turned off (grey cloud); CAA record excluding Cloudflare's CAs	SSL/TLS, Edge Certificates
AWS Certificate Manager	ACM, automatically for DNS-validated certs	Validation CNAME removed from Route 53	ACM console, certificate status
Kubernetes cert-manager	Controller, renews at two thirds of lifetime by default	Ingress class mismatch; solver pod cannot be reached	`kubectl describe certificate`
Caddy / Traefik	Built-in ACME client	Port 80 or 443 unreachable from the internet	Server logs

Step 3: Verify the renewal actually worked

Renewing and deploying are two different things. A renewed file sitting on disk does nothing until the server process has loaded it. Confirm from the outside:

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

The notAfter date must be the new one and the serial number must differ from the old certificate. Then check the full chain and every host name (www and bare domain, API subdomains, mail hosts). A free FortifyNet scan checks the chain, expiry date, protocol versions and HSTS in one pass, which is faster than testing each host by hand.

Common SSL renewal errors and fixes

Error or symptom	Likely cause	Fix
Certbot: "Some challenges have failed" (HTTP-01)	Port 80 blocked, redirect loop, or DNS pointing elsewhere	Allow port 80 inbound, keep /.well-known/acme-challenge/ reachable over plain HTTP
Certbot: "too many certificates already issued"	Forced renewals in a loop	Remove `--force-renewal` from scheduled jobs, wait for the weekly window
DNS-01 "no TXT record found"	Propagation delay or wrong zone	Add a propagation wait, confirm the API token has zone edit rights
Browser still shows the old expiry after renewal	Service not reloaded, or CDN caching the old cert	Reload nginx/Apache; purge or re-upload at the CDN
`ERR_CERT_AUTHORITY_INVALID` after install	Intermediate chain missing	Install the full chain file the CA provides, not only the leaf
Certificate renewed but mail clients complain	Mail server uses its own copy	Deploy the same files to Postfix/Dovecot/Exchange and restart
CAA lookup failure	CAA record lists other CAs only	Add `0 issue "letsencrypt.org"` (or your CA) to the CAA record

Set a renewal policy you can actually keep

With 200-day certificates now and 47-day certificates by 2029, a renewal policy should be boring and automatic. Renew at roughly two thirds of the certificate's lifetime, exactly the behaviour Let's Encrypt recommends for clients that lack ARI. Run a monitoring check that alerts at 14 and 7 days before expiry, independent of the renewal tool, because the failure you need to catch is the automation silently stopping. Keep an inventory of every host name that terminates TLS, including internal ones. And test the dry run after every server migration, PHP upgrade or firewall change, since those are the moments the ACME challenge stops working.

Related guides

FAQ

How early can I renew an SSL certificate?
Let's Encrypt allows renewal at any time, and Certbot does it automatically 30 days before expiry. Commercial CAs typically open renewal 30 to 90 days early and add the unused days to the new certificate.

Does renewing an SSL certificate cause downtime?
No, if you reload rather than restart the web server. nginx and Apache both load the new certificate on a reload without dropping existing connections.

Do I need a new private key to renew?
Not strictly, but generating a new key is best practice. Certbot creates a new key on every renewal by default.

Can I renew a certificate after it has expired?
Yes. Renewal after expiry works the same way; the only difference is that visitors see warnings until the new certificate is installed.

How many times a year will I have to renew from 2029?
With the 47-day maximum, about eight times per certificate per year, which is why manual renewal is being phased out in practice.

Check your certificate before it becomes an incident

Run the free FortifyNet scan on your domain. In about 60 seconds it reports the certificate expiry date, chain validity, protocol versions, security headers, DNS and email authentication, so a failed renewal shows up before your visitors find it.

Originally published at fortifynet.com/blog/how-to-renew-ssl-certificate. I'm the founder of FortifyNet, a website security scanner; this article comes from our blog, so factor in that founder bias when you read any tool recommendations here.

Website Security Audit: Complete 2026 Guide | FortifyNet

Håkan Fägnell — Wed, 02 Sep 2026 04:47:19 +0000

A website security audit is a structured review of everything an attacker can see and reach from outside your organisation: your TLS certificate and cipher configuration, your DNS records, your email authentication (SPF, DKIM and DMARC), your HTTP security headers, the software versions you leak in responses, and any company credentials already circulating on the dark web. A good audit ends with a ranked list of findings, each with an owner and a concrete fix. The externally visible layer takes about sixty seconds to scan automatically. The full exercise, done properly, takes an afternoon.

This guide covers what an audit actually tests, the four levels of depth available to you, an eight step process you can run this week, and how often to repeat it.

Why the 2026 threat picture changed the maths

Verizon's 2026 Data Breach Investigations Report, published on 19 May 2026 and built on more than 31,000 security incidents and over 22,000 confirmed breaches across 145 countries, found that exploitation of vulnerabilities was the initial access vector in 31% of breaches. That is the first time in the report's nineteen editions that it has overtaken stolen credentials, which fell to 13%.

Two supporting figures from the same report explain why infrequent auditing is now expensive. Only 26% of the critical vulnerabilities listed in CISA's Known Exploited Vulnerabilities catalogue were fully remediated during 2025, down from 38% the year before. And the median time to fully remediate a vulnerability rose to 43 days. Attackers are moving faster while defenders are moving slower, so the gap you leave between audits is the gap they work in.

The certificate side changed too. Under CA/Browser Forum ballot SC-081v3, approved in April 2025 by a vote of 29 to 0, the maximum lifetime of a publicly trusted TLS certificate dropped from 398 days to 200 days on 15 March 2026. It falls to 100 days on 15 March 2027 and to 47 days on 15 March 2029. Domain validation reuse periods shrink on the same dates. Any renewal process that still relies on a person remembering a calendar entry will fail within this cycle, which makes certificate expiry a permanent audit item rather than an annual one.

What a website security audit actually checks

Layer	What the audit looks for	Usual owner	Sensible cadence
TLS and certificates	Expiry date, chain completeness, hostname match, protocol versions, weak ciphers	Ops or hosting provider	Continuous monitoring, review monthly
DNS	Dangling CNAME records, missing DNSSEC, open zone transfers, stale subdomains	DNS or platform team	Quarterly, plus after every migration
Email authentication	SPF record validity and lookup budget, DKIM selectors, DMARC policy and reporting	IT or email admin	Quarterly, plus after any provider change
HTTP security headers	HSTS, CSP, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy	Web or platform team	After every deployment
Application surface	Outdated CMS, plugins and libraries, exposed admin paths, verbose error pages	Development team	Monthly, automated
Data exposure	Company email addresses and credentials in known breach corpora	Security or IT lead	Continuous monitoring
Performance and availability	Core Web Vitals, uptime, response times under load	Web team	Weekly

The first four rows are the ones an external scanner can assess without any access to your systems, which is why they are the fastest place to start and usually where the first real findings appear.

What audits find missing most often

The HTTP Archive's Web Almanac 2025, which analyses millions of real websites, measured how many sites actually set each protective HTTP header. The answer is sobering: the single most widely adopted security header is present on roughly half of sites, and Content Security Policy on barely a fifth.

Adoption of key HTTP security headers on mobile pages. Source: HTTP Archive Web Almanac 2025, Security chapter. Figures for X-Content-Type-Options and X-Frame-Options are approximate as published.

Strict-Transport-Security reached 36% of pages in 2025, up six percentage points on 2024 and the strongest riser of the year. Content Security Policy grew from 18.5% to 21.9%. Newer controls such as Permissions-Policy and Cross-Origin-Opener-Policy remain below 10%. Even among sites that do deploy CSP, 92% still allow unsafe-inline in script-src and 77% allow unsafe-eval, which removes most of the protection the header is meant to provide. Adopting a header is not the same as configuring it well, and a real audit checks the value, not just the presence.

Transport encryption is in far better shape. TLS 1.3 now carries roughly 76% of page loads, TLS 1.2 is down to 13 to 15%, and HTTPS adoption exceeds 95% in every country the Almanac measures except Japan. If your audit still finds TLS 1.0 or 1.1 enabled, you are in a small and conspicuous minority.

Email authentication remains the widest gap of all. DMARCguard's State of Email Authentication 2026, a scan of 5,499,028 Tranco-ranked domains completed on 27 February 2026, found SPF on 56.0% of domains, DMARC on 30.4% and DKIM on just 22.7%.

The four levels of audit, and when each is worth it

Audit type	Typical duration	What it finds	What it misses	Good for
Automated external scan	Under 2 minutes	Certificate, DNS, email auth, header and exposure issues visible from outside	Business logic flaws, authenticated areas	Continuous baseline, every site, every month
Authenticated vulnerability assessment	1 to 5 days	Known CVEs in your stack, misconfigured services, weak access controls	Novel logic abuse, chained exploits	Regulated or transactional sites, annually
Penetration test	1 to 3 weeks	Chained and creative attacks, privilege escalation, real exploitability	Anything outside the agreed scope or time box	Before a major launch, or annually for high-risk systems
Manual code and architecture review	1 to 4 weeks	Design flaws, insecure defaults, supply chain risk in dependencies	Runtime and infrastructure issues	New products, or after an incident

Most organisations should treat the first row as always on and choose one of the other three per year based on risk. Running a penetration test on a site that still fails an automated scan wastes the test, because the tester spends the engagement reporting findings a free tool would have caught in a minute.

How to run a website security audit in eight steps

Inventory what you own. List every domain, subdomain and third-party service that renders under your brand. Audits fail most often because the vulnerable host was one nobody remembered owning.
Run an external scan first. Get the outside-in picture before you spend anyone's time. This tells you which of the seven layers above are already failing.
Verify certificates and renewal automation. Check expiry, chain and hostname coverage, then check that renewal is automated. Under the 200 day limit now in force, manual renewal is a scheduled outage.
Check DNS for orphans. Every CNAME pointing at a service you no longer use is a subdomain takeover waiting to happen. Remove stale records rather than leaving them.
Validate email authentication end to end. Confirm your SPF record stays within its ten DNS lookup budget, that DKIM signs all sending sources, and that DMARC has a policy stronger than p=none with a working reporting address.
Review header values, not just header presence. A CSP full of unsafe-inline and an HSTS max-age of 300 seconds both pass a naive checklist and protect nobody.
Patch by exploitability, not by CVSS score alone. Anything on the CISA Known Exploited Vulnerabilities catalogue that touches your stack goes first.
Write the findings down with an owner and a date. An audit that ends in a conversation instead of a ticket has not happened.

Mapping your findings to OWASP Top 10:2025

OWASP published the 2025 edition of its Top 10 in January 2026, after announcing it at Global AppSec in Washington DC in November 2025. Two categories are new, and both are relevant to what an audit should now cover.

Rank	Category	Change from 2021	Visible in an external audit?
A01	Broken Access Control	Stable at the top for four editions, now absorbs SSRF	Partly
A02	Security Misconfiguration	Up from A05	Yes
A03	Software Supply Chain Failures	New, expands the old A06	Partly
A04	Cryptographic Failures	Down from A02	Yes
A05	Injection	Down from A03	Partly
A06	Insecure Design	Down from A04	No
A07	Authentication Failures	Stable	Partly
A08	Software and Data Integrity Failures	Stable	Partly
A09	Security Logging and Alerting Failures	Renamed from Monitoring	No
A10	Mishandling of Exceptional Conditions	New, replaces SSRF as a standalone entry	Partly

The promotion of Security Misconfiguration to second place is the single most useful signal here for anyone planning an audit. It is the category most fully addressed by external scanning, and the category most often left to whoever set the server up years ago.

How often should you audit?

Continuously for anything automatable, quarterly for anything requiring judgement, and immediately after any of these events: a platform or hosting migration, a change of email provider, a new subdomain going live, a dependency major version bump, or a staff departure with administrative access. The Verizon figure that third parties now feature in 48% of breaches, a 60% increase year on year, means a supplier change deserves the same treatment as a change of your own.

Frequently asked questions

How long does a website security audit take?
An automated external scan of certificates, DNS, email authentication, headers and exposure completes in about a minute. A thorough internal review of the findings, with fixes assigned, typically takes half a day for a small site.

Do I need a penetration test, or is a scan enough?
A scan is the right and sufficient starting point for every site, and the only sensible thing to run continuously. A penetration test adds value once your automated findings are clean and you have authenticated functionality, payments or personal data worth attacking.

Can an audit be done without access to my server?
Most of the highest-value checks can. TLS configuration, certificate validity, DNS hygiene, SPF, DKIM, DMARC, security headers and dark web exposure are all assessable from the public internet. Code review and authenticated testing are the parts that need access.

What is the first thing to fix after an audit?
Anything on the CISA Known Exploited Vulnerabilities catalogue, then an expiring or misconfigured certificate, then a DMARC policy of p=none. These three account for a disproportionate share of real-world compromise relative to the effort of fixing them.

Start with the sixty second version

You cannot fix what you have not measured, and the outside-in layer of a website security audit is free to measure. FortifyNet's scanner checks your SSL and TLS configuration, DNS records, SPF, DKIM and DMARC, HTTP security headers, dark web exposure and performance in about sixty seconds, and returns a prioritised list rather than a wall of raw output. Run it on your domain, fix what it finds, then decide whether you need the deeper levels.

Related guides

Originally published at fortifynet.com/blog/website-security-audit. I'm the founder of FortifyNet, a website security scanner; this article comes from our blog, so factor in that founder bias when you read any tool recommendations here.

SSL Certificate Expired: What Happens and How to Fix It

Håkan Fägnell — Tue, 01 Sep 2026 04:46:08 +0000

An expired SSL certificate means the certificate that proves your website's identity has passed its expiry date, so browsers stop trusting it on the spot. Visitors see a full-screen warning such as NET::ERR_CERT_DATE_INVALID instead of your content, API clients and mobile apps fail outright, and traffic collapses until the certificate is replaced. The fix is to renew or reissue the certificate, install the new full chain on every server that terminates TLS, and reload those services; with an automated ACME setup that takes minutes. This guide shows you how to check your expiry date, fix an expired certificate step by step, and make sure it never happens again.

What visitors see when your SSL certificate expires

Browsers do not politely mention the problem in a corner. They replace your entire page with a warning screen, and the visitor has to dig through an "Advanced" menu to proceed at all. The wording differs by browser:

Browser	Warning screen	Error code
Chrome	"Your connection is not private"	NET::ERR_CERT_DATE_INVALID
Edge	"Your connection isn't private"	NET::ERR_CERT_DATE_INVALID
Firefox	"Warning: Potential Security Risk Ahead"	SEC_ERROR_EXPIRED_CERTIFICATE
Safari	"This Connection Is Not Private"	Shown without a code on the first screen

These warnings are common enough to be measured at scale. In the largest published study of browser certificate warnings, Google and Carnegie Mellon researchers analysed more than 300 million Chrome warning reports and attributed 4.23% of warnings on Windows to certificate date errors (Acer et al., ACM CCS 2017). Expired certificates are the routine failure mode of HTTPS, and the warning screen itself is often the first sign an owner gets.

More than your homepage breaks

The browser warning is only the visible part. The quiet failures usually cost more:

APIs and webhooks fail hard. Machine clients do not have an "Advanced" button. Payment callbacks, mobile apps, partner integrations and monitoring agents simply refuse the connection the second the certificate expires.
HSTS removes the escape hatch. If your site sends the HSTS header, browsers hide the "proceed anyway" link entirely. Visitors cannot click through even if they want to.
Email and internal tools stop. TLS on SMTP, IMAP and admin panels fails just as hard, and those certificates are the ones nobody watches.
Trust erodes fastest. A business with an expired certificate on its own site is a contradiction visitors remember. Search engines also see the warning state, and conversion-focused pages lose their traffic for as long as the warning stands.

Three famous outages caused by one expired certificate

Certificate expiry is not a small-company problem. Some of the most expensive outages of the past decade were caused by exactly this:

Date	Company	What expired	Impact
6 Dec 2018	Ericsson (O2, SoftBank)	Certificate in core mobile network software	About 32 million O2 subscribers in the UK lost data for most of the day; tens of millions of SoftBank customers in Japan were cut off for hours (The Register)
3 Feb 2020	Microsoft Teams	Authentication certificate	Roughly three hours of global downtime for a service with 20 million daily users (TechCrunch)
19 Aug 2020	Spotify	Wildcard TLS certificate (*.wg.spotify.com)	Around one hour of global outage across players and APIs (Data Center Dynamics)

The lesson is uncomfortable: these companies employ world-class engineers, and the certificate still expired. Renewal is a process problem, not a skill problem, and a calendar reminder in someone's inbox is not a process.

How to check when your certificate expires

Three ways, from quickest to most thorough:

1. In the browser. Click the padlock or tune icon in the address bar, open "Connection is secure", then "Certificate is valid". The details panel shows the exact validity period.

2. From the command line. Query the live certificate with OpenSSL:

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

The output prints notBefore and notAfter; the second line is your deadline.

3. Check the whole chain, not just your own certificate. Intermediate and root certificates expire too. When the AddTrust External CA Root expired on 30 May 2020, services with perfectly valid leaf certificates failed worldwide, including Roku devices and several payment platforms. An external scan that validates the full chain catches what a glance at your own certificate misses.

How to fix an expired SSL certificate, step by step

Step 1: confirm expiry is really the cause. Run the OpenSSL command above and read notAfter. If the certificate is actually valid, the visitor's device clock is wrong, and nothing on your server needs fixing.

Step 2: renew or reissue. With Let's Encrypt or any other ACME client the renewal is one command (sudo certbot renew), and a dry run (sudo certbot renew --dry-run) tells you in advance whether validation will succeed. With a commercial CA, generate a fresh CSR in your control panel and complete validation there.

Step 3: install the full chain everywhere TLS terminates. The new certificate has to reach every endpoint that speaks TLS for the domain: origin servers, load balancers and the CDN edge. Deploy fullchain.pem (leaf plus intermediates), not the leaf alone, or you trade a date error for a chain error.

Step 4: reload the service. A renewed file on disk changes nothing until the server re-reads it. Run sudo systemctl reload nginx (or the equivalent for Apache, HAProxy or your platform). This is the single most common failure in "automated" setups: the renewal cron works perfectly, the reload hook was never configured, and the server keeps serving the old certificate from memory.

Step 5: verify from the outside. Check from a phone on mobile data, a fresh browser profile, or an external scanner. There is no propagation delay with certificates: the moment the server is reloaded, every new connection receives the new certificate.

Renewal is about to get relentless

If renewal feels manageable today, the schedule is changing under your feet. Under CA/Browser Forum ballot SC-081v3, adopted in April 2025 by a unanimous 29-0 vote, the maximum lifetime of a public TLS certificate dropped from 398 to 200 days on 15 March 2026, falls to 100 days on 15 March 2027, and lands at 47 days on 15 March 2029 (CA/Browser Forum). Let's Encrypt has gone further already: it announced in December 2025 that its default lifetime will drop from 90 to 45 days, and its six-day short-lived certificates became generally available on 15 January 2026.

Certificate lifetimes available and permitted in 2026. Sources: CA/Browser Forum ballot SC-081v3; Let's Encrypt.

The direction is one-way: renewals that used to happen once a year will soon happen every six to seven weeks, and for short-lived certificates every few days. Manual renewal does not survive that schedule. Automation stops being a nice-to-have and becomes the only way to keep a certificate valid.

How to never let a certificate expire again

Automate issuance and renewal with ACME, and configure the deploy hook that reloads your web server after each renewal.
Monitor expiry from outside. An external check catches every certificate a renewal script silently skipped. Alert at 30, 14 and 7 days before expiry.
Inventory every certificate, not just the main site: API subdomains, mail servers, staging hosts and internal panels expire on their own schedules.
Treat renewal as a deployment. It changes what production serves, so it deserves the same verification step as a code release.

Related guides

SSL/TLS certificate security: the complete guide to an A+ rating covers protocols, chains and configuration beyond expiry.
"Your connection is not private": what it means and how to fix it explains the warning screen your visitors are seeing right now.
ERR_CERT_AUTHORITY_INVALID: what causes it and how to fix it handles the chain errors that often appear right after a rushed renewal.
What is HSTS? explains why some visitors cannot bypass certificate warnings at all.

FAQ

Can visitors still open my site while the certificate is expired?
In most browsers they can click through an "Advanced" menu, but the majority will not, and if your site sends HSTS the browser removes that option entirely. API clients and apps refuse the connection outright.

Does an expired SSL certificate hurt SEO?
Indirectly, yes. Crawlers see the same invalid certificate, visitors bounce off the warning page, and HTTPS is a confirmed ranking signal. The longer the warning stands, the more traffic and trust you lose.

How long does the fix take?
With ACME automation in place, minutes: renew, reload, verify. There is no propagation period, because the new certificate is served to every new connection immediately after the reload.

Why did my certificate expire even though auto-renewal was on?
The usual causes: the renewal ran but no reload hook was configured, so the old certificate stayed in memory; validation silently failed after a DNS or firewall change; or the renewal covered one hostname but not the certificate that actually expired.

Do expired certificates on internal tools matter?
Yes. Internal and API certificates fail the same way public ones do, and they are watched less. Many of the incidents in this article started with a certificate nobody had inventoried.

Check your certificates before your visitors do

An expiry date never negotiates. Run a free FortifyNet scan to see your certificate's exact expiry date, the full chain, protocol configuration, security headers, DNS and email authentication in about 60 seconds. No signup required.

Sources: CA/Browser Forum, Ballot SC-081v3; Let's Encrypt, Certificate Lifetimes; Let's Encrypt, 6-day certificates GA; The Register on the Ericsson outage; TechCrunch on the Teams outage; Data Center Dynamics on the Spotify outage; Acer et al., "Where the Wild Warnings Are", ACM CCS 2017.

Originally published at fortifynet.com/blog/ssl-certificate-expired. I'm the founder of FortifyNet, a website security scanner; this article comes from our blog, so factor in that founder bias when you read any tool recommendations here.

SPF, DKIM & DMARC Rollout Guide: Zero to p=reject Step by Step

Håkan Fägnell — Mon, 31 Aug 2026 04:46:55 +0000

Email remains the single most abused entry point into organizations. According to the Verizon Data Breach Investigations Report, phishing and pretexting are involved in the majority of social-engineering breaches, and most of those start with a spoofed sender address. The three DNS-based authentication standards - SPF, DKIM and DMARC - exist to make spoofing your domain technically detectable and, at full enforcement, rejectable.

This guide is written for IT managers who need to take a real organization - with newsletters, a CRM, a helpdesk, invoicing software and a marketing platform all sending mail "from" the company domain - from zero email authentication to an enforced DMARC policy of p=reject, without losing a single legitimate message on the way. Expect the full rollout to take 6–10 weeks of calendar time, with only a few hours of hands-on work per week.

How the three protocols fit together

Before touching DNS, make sure the mental model is right, because most failed rollouts come from misunderstanding alignment.

SPF (RFC 7208) publishes, in DNS, the list of IP addresses allowed to send mail using your domain in the SMTP envelope (MAIL FROM).
DKIM (RFC 6376) cryptographically signs each message with a private key; the public key is published in DNS. Receivers verify the signature to confirm the message was not altered and was authorized by the signing domain.
DMARC (RFC 7489) ties both together. It tells receivers: "if a message claims to be from my domain in the visible From: header, it must pass SPF or DKIM in alignment with that domain - and here is what to do if it does not, and here is where to send reports."

The verification flow at the receiving mail server looks like this:

            Incoming message claiming From: billing@example.com
                                 |
              +------------------+------------------+
              |                                     |
        SPF check                              DKIM check
   Is sending IP listed in               Does the d= signature
   example.com's SPF record              verify against the DNS
   for the envelope sender?              public key?
              |                                     |
              +------------------+------------------+
                                 |
                          DMARC alignment
        Does the domain that passed (envelope domain for SPF,
        d= domain for DKIM) match the visible From: domain?
                                 |
              +------------------+------------------+
              |                                     |
         PASS: deliver                    FAIL: apply policy
                                          p=none  -> deliver, report
                                          p=quarantine -> spam folder
                                          p=reject -> refuse message

The crucial detail: a message can pass SPF and DKIM for some domain and still fail DMARC, because DMARC requires the passing domain to align with the From: header domain your users actually see. This is exactly what stops a phisher who signs mail with their own domain's DKIM key.

Phase 0 - Inventory every legitimate sender (week 1)

The number one cause of lost mail during DMARC rollouts is a forgotten sending service. Before publishing anything, build a sender inventory. Interview the marketing, sales, finance and HR teams, and check DNS for existing include: mechanisms.

Typical inventory for a 50-person company:

Sending service	What it sends	Envelope domain	DKIM capable?
Google Workspace / M365	Day-to-day corporate mail	example.com	Yes
Mailchimp / Brevo	Newsletters	mail.example.com	Yes (CNAME)
HubSpot / Pipedrive	Sales sequences	example.com	Yes
Zendesk / Freshdesk	Support replies	example.com	Yes
Fortnox / QuickBooks	Invoices	often their own domain	Varies
Website contact form	Notifications	web server IP	Usually no
Monitoring/CI (cron, Jenkins)	Alerts	server hostname	Usually no

Two rules of thumb from this phase:

Anything that cannot do DKIM should be migrated to send through an authenticated relay (e.g. your Workspace SMTP relay or a transactional provider such as Postmark or SES) rather than directly from a web server.
Do not guess. The DMARC monitoring phase below will catch what interviews miss - that is what it is for.

Phase 1 - Publish a correct SPF record (week 1–2)

SPF is one TXT record on the root of your domain. Collect the include mechanisms from each provider's documentation and merge them into a single record - a domain must have exactly one SPF record; two records cause a permanent error (permerror) and effectively disable SPF.

example.com.  IN TXT  "v=spf1 include:_spf.google.com include:servers.mcsv.net include:_spf.hubspot.com ip4:203.0.113.25 ~all"

Key decisions:

End with ~all (softfail), not -all, during rollout. DMARC does not need -all to work, and -all combined with an incomplete inventory bounces legitimate mail immediately. You can tighten to -all after monitoring confirms the inventory is complete.
Stay under 10 DNS lookups. Every include, a, mx and redirect mechanism costs a lookup; exceeding ten is a permerror per RFC 7208 §4.6.4. Count the nested lookups inside each include (Google's include alone costs three). If you are near the limit, use SPF flattening cautiously or move bulk senders to a subdomain.
Use ip4:/ip6: for servers you control instead of a: mechanisms - they cost no lookups.

Validate with a checker (FortifyNet's MX & email security tool shows SPF, DKIM and DMARC in one pass) and with dig:

dig +short TXT example.com | grep spf1

Phase 2 - Enable DKIM everywhere (week 2–3)

DKIM setup is per-provider, but always follows the same shape: the provider generates a key pair, you publish the public key at selector._domainkey.example.com, and the provider starts signing.

Google Workspace: Admin console → Apps → Gmail → Authenticate email. Generate a 2048-bit key (1024-bit keys are considered weak; NIST and M3AAWG both recommend 2048). Publish the TXT record, wait for DNS propagation, click "Start authentication".
Microsoft 365: Defender portal → Email authentication settings → DKIM. Microsoft uses two CNAME records (selector1, selector2) that enable automatic key rotation.
Mailchimp, HubSpot, Zendesk etc.: each has an "authenticate your domain" wizard that gives you 2–4 CNAME records.

Verify each selector after publishing:

dig +short TXT google._domainkey.example.com
dig +short CNAME selector1._domainkey.example.com

Then send a test message to a Gmail address, open "Show original", and confirm you see DKIM: PASS with domain example.com - the "with domain" part is the alignment that DMARC will check.

Plan for key rotation every 6–12 months. Providers with CNAME-based setups rotate for you; for manually published keys, put a recurring calendar item on the security calendar now, because nobody remembers later.

Phase 3 - DMARC in monitoring mode (week 3–4)

Publish a DMARC record at _dmarc.example.com with policy p=none. This changes nothing about delivery - it only turns on reporting.

_dmarc.example.com.  IN TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; fo=1; adkim=r; aspf=r"

What each tag does:

Tag	Value	Meaning
p	none	Take no action on failures yet - just report
rua	mailto:…	Where daily aggregate (XML) reports are sent
fo	1	Generate a failure report if any mechanism fails
adkim / aspf	r	Relaxed alignment: subdomains of example.com count as aligned
sp	(unset)	Subdomain policy - inherit p for now

Practical notes:

Use a dedicated mailbox or, far better, a DMARC report processor - raw reports are gzipped XML and arrive from every large receiver daily. Free tiers of common analyzers are enough for a single domain.
If the report address is on a different domain than the one being monitored, the report domain must publish an external destination verification record (RFC 7489 §7.1).
Let monitoring run at least two full weeks, ideally four, so monthly jobs (invoice runs, board reports) appear in the data.

Phase 4 - Read the reports and fix what fails (week 4–6)

Aggregate reports answer three questions for every sending IP: how much mail, did SPF align, did DKIM align. Triage into three buckets:

Aligned pass (SPF or DKIM): healthy. The bulk of your Workspace/M365 mail should be here from day one.
Your service, failing alignment: e.g. the CRM passes DKIM but signs with d=crm-provider.com. Fix by completing that provider's domain authentication wizard so it signs with your domain. This bucket is your Phase 4 work queue.
Unknown IPs failing everything: this is spoofing (or forwarding). You do not fix this - enforcement will neutralize it. Its presence is the business case for this whole project.

One legitimate source will keep failing no matter what you do: mailing lists and some forwarders break SPF (new sending IP) and sometimes DKIM (footer added). ARC (RFC 8617) helps at large receivers, but the honest answer is that a small residual failure rate (well under 1%) is normal and acceptable at enforcement.

Phase 5 - Ramp to enforcement (week 6–10)

Never jump from p=none straight to p=reject. Use the pct tag to ramp:

Step	Record change	Hold time	Rollback trigger
1	p=quarantine; pct=10	1 week	any report of legitimate mail in spam
2	p=quarantine; pct=50	1 week	same
3	p=quarantine (pct=100)	2 weeks	same
4	p=reject	permanent	aligned-pass rate drops below ~98%

At each step, watch two signals: the aggregate reports (aligned-pass percentage for known senders should stay flat) and the helpdesk (tickets about "customer says my mail bounced"). Rollback is a single DNS change back to the previous step and takes effect within the record's TTL - set the TTL to 3600 seconds during the ramp so mistakes are cheap.

When you reach p=reject, finish the job:

Add an explicit subdomain policy: sp=reject, unless a subdomain intentionally sends with looser rules.
Protect parked domains you own but never send from: give each v=spf1 -all, an empty DKIM policy, and v=DMARC1; p=reject. Parked domains are the spoofer's favourite target.
Consider BIMI (brand logo in inboxes) - it requires enforced DMARC, so you have just unlocked it.

Troubleshooting quick reference

Symptom	Likely cause	Fix
permerror in reports	two SPF records, or >10 lookups	merge records; reduce includes
DKIM fail only at one receiver	DNS propagation or truncated TXT	re-check record; split 2048-bit key correctly across strings
Newsletter fails alignment	ESP signs with own domain	complete ESP domain authentication (CNAMEs)
Own web server mail rejected	form mail sent directly from web host	route through authenticated SMTP relay
Forwarded mail quarantined	forwarding breaks SPF	expected; rely on DKIM surviving, accept residual

The rollout at a glance

Week	Activity	Deliverable
1	Sender inventory interviews	signed-off sender table
1–2	SPF published and validated	one record, under 10 lookups
2–3	DKIM per provider, 2048-bit	PASS with aligned domain at Gmail test
3–4	DMARC p=none + report processor	reports flowing
4–6	Report triage, fix alignment gaps	bucket 2 empty
6–10	Ramp: q10 → q50 → q100 → reject	p=reject live, sp=reject set

Print this table into the project ticket; each row is a natural weekly status update for management, and the deliverable column keeps the project honest about what "done" means at each step.

Beyond DMARC - MTA-STS and TLS-RPT

DMARC authenticates who sent a message; it says nothing about whether the message travelled encrypted. SMTP still falls back to plaintext when TLS negotiation fails, and an active attacker on the network path can force exactly that failure. Two companion standards close the gap, and since you are already in the DNS console this is the right week to deploy them.

MTA-STS (RFC 8461) lets your domain declare "only deliver mail to me over authenticated TLS". It consists of a DNS record and a small policy file served over HTTPS:

\`
_mta-sts.example.com. IN TXT "v=STSv1; id=20260828T000000"

https://mta-sts.example.com/.well-known/mta-sts.txt:
version: STSv1
mode: testing
mx: mail.example.com
max_age: 86400
`\

Run mode: testing for two weeks, then switch to mode: enforce and raise max_age to 604800. The mx lines must match your real MX hostnames exactly - a typo here silently drops inbound mail in enforce mode, which is why the testing stage exists.

TLS-RPT (RFC 8460) is the reporting channel for MTA-STS, exactly as rua reporting is for DMARC:

\_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com" \\

Senders that fail to deliver over TLS tell you why, daily, in machine-readable JSON. In practice the reports are quiet - which is precisely the confirmation you want before enforcing.

Reading an aggregate report by hand

Even with an analyzer, read one raw report once so the data stops being a black box. Inside the gzipped XML each record block contains three things that matter:

\<record> <row> <source_ip>198.51.100.7</source_ip> <count>412</count> <policy_evaluated> <disposition>none</disposition> <dkim>fail</dkim> <spf>pass</spf> </policy_evaluated> </row> <identifiers> <header_from>example.com</header_from> </identifiers> </record> \\

Read it as a sentence: "198.51.100.7 sent 412 messages claiming to be example.com; SPF aligned, DKIM did not; under the current policy nothing was done." Look the IP up (reverse DNS plus the sender's published ranges) and you know whether this row is bucket 1, 2 or 3 from Phase 4. Ten minutes with one report teaches more than any dashboard tour.

Governance - keeping it enforced

Email authentication is not a project with an end date; it is a small standing capability. Bake these into normal operations before closing the ticket:

Change control on DNS: every new SaaS tool that "just needs to send email as us" goes through you, gets DKIM set up properly, and is added to the inventory table. The alternative is that marketing signs up for a tool in November and its mail silently lands in spam under your p=reject.
Quarterly report review: fifteen minutes per quarter scanning the analyzer for new failing sources. Calendar it.
Monitoring the records themselves: SPF, DKIM and DMARC records can be broken by an innocent DNS migration. External monitoring that alerts on any change to these records - FortifyNet's domain monitoring does this continuously - turns a silent regression into a same-day fix.
Offboarding: when a sending service is cancelled, remove its include and DKIM records the same week. Stale includes are both a lookup-budget leak and a supply-chain risk: if the provider's IP space is re-assigned, whoever inherits it can send authenticated mail as you.

Final checklist

[ ] Sender inventory reviewed by marketing, finance, support
[ ] Exactly one SPF record, under 10 lookups, ends ~all (then -all)
[ ] DKIM 2048-bit, verified per selector, rotation scheduled
[ ] DMARC p=none with rua reporting, 2–4 weeks of data reviewed
[ ] All legitimate senders aligned (bucket 2 empty)
[ ] Ramp: quarantine 10% → 50% → 100% → reject, one week+ per step
[ ] sp=reject set; parked domains locked down
[ ] Run a full FortifyNet scan to confirm the records grade cleanly

Sources

Originally published at fortifynet.com/blog/guide-email-authentication-rollout. I'm the founder of FortifyNet, a website security scanner; this article comes from our blog, so factor in that founder bias when you read any tool recommendations here.

HTTP Security Headers Hardening Guide: HSTS, CSP & More Step by Step

Håkan Fägnell — Sun, 30 Aug 2026 04:45:49 +0000

HTTP security headers are the cheapest security control you will ever deploy: a handful of response headers, set once at the web server or CDN, that instruct every visiting browser to refuse whole classes of attack - clickjacking, protocol downgrade, MIME sniffing, cross-site data leaks and large parts of cross-site scripting. Yet the majority of websites still ship without them, or with values copied from a blog post that silently break functionality.

This guide walks an IT manager through a complete, staged hardening of a production website's headers: what each header does, the exact values to deploy, how to roll out Content-Security-Policy without breaking the site, web-server configuration for nginx and Apache, and how to verify the result. Budget one working day of effort spread over two to three weeks of calendar time (the CSP report-only period accounts for most of it).

How headers protect users

Every header in this guide is an instruction from your server to the visitor's browser. The browser enforces it locally - no appliance, agent or code change required:

   Your server                          Visitor's browser
   -----------                          -----------------
   HTTP/1.1 200 OK
   Strict-Transport-Security  ------>   "Never load this site over HTTP again"
   Content-Security-Policy    ------>   "Only run scripts from these origins"
   X-Frame-Options            ------>   "Refuse to render this site in an iframe"
   X-Content-Type-Options     ------>   "Never guess file types"
   Referrer-Policy            ------>   "Don't leak full URLs to other sites"
   Permissions-Policy         ------>   "This site may not use camera/mic/location"

Because enforcement happens in the browser, headers protect your users even when the attack does not touch your server at all - for example a phishing page framing your login form, or an injected ad script exfiltrating form data.

Step 1 - Baseline: measure before you change anything

Run your site through a header scanner - FortifyNet's free security headers checker grades each header and shows a one-line fix, and securityheaders.com is a good second opinion. Save the result. A typical unhardened site scores an F with only Server and X-Powered-By present - both of which leak information rather than protect anything.

Also inventory what the site actually loads. Open the browser dev tools Network tab on your five most important pages and note every third-party origin: analytics, fonts, tag managers, chat widgets, payment iframes, video embeds. This list becomes your CSP allowlist in Step 4.

Step 2 - Deploy the five safe headers immediately

Five headers are effectively risk-free for almost every site and should go out in the first change window.

Strict-Transport-Security (HSTS)

Forces HTTPS for every future visit, defeating SSL-stripping attacks on public Wi-Fi.

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

Start with max-age=31536000 (one year) only if all subdomains already serve HTTPS; otherwise begin with max-age=86400 and includeSubDomains omitted, then expand. Once stable, consider HSTS preload - being hard-coded into browsers removes even the first-visit window, but is effectively irreversible, so treat preload as a one-way door.

X-Content-Type-Options

X-Content-Type-Options: nosniff

Stops browsers from "sniffing" file types, which prevents a user-uploaded file served as text from being executed as script. There is no legitimate reason to omit this.

X-Frame-Options

X-Frame-Options: DENY

Blocks clickjacking - an attacker overlaying your real, framed site with invisible buttons. Use SAMEORIGIN instead if your own site legitimately frames itself (some admin panels and preview features do). Modern CSP frame-ancestors supersedes this header, but keep both for older browsers.

Referrer-Policy

Referrer-Policy: strict-origin-when-cross-origin

Ensures links to external sites reveal only your origin (https://example.com) rather than the full URL - which may contain search terms, account paths or reset tokens. This value is also the modern browser default, but setting it explicitly guarantees it everywhere.

Permissions-Policy

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()

Declares which powerful browser features the site (and any injected script) may use. Deny everything you do not use; a compromised third-party script then cannot silently request the camera. Add features back (e.g. payment=(self "https://js.stripe.com")) only where genuinely needed.

Step 3 - Remove headers that leak

While editing configuration, strip the chatty defaults: Server version strings and X-Powered-By. They provide zero function and hand attackers your exact software versions for CVE matching. In nginx: server_tokens off;. In Apache: ServerTokens Prod and ServerSignature Off. For PHP: expose_php = Off.

Step 4 - Content-Security-Policy, the staged way

CSP is the most powerful header - and the only one that can break your site if deployed carelessly. Never copy a CSP from another site. Follow this three-stage process instead.

Stage A: Report-Only (1–2 weeks)

Deploy the policy in Content-Security-Policy-Report-Only mode. Browsers evaluate it and report violations, but block nothing:

Content-Security-Policy-Report-Only: default-src 'self';
  script-src 'self' https://www.googletagmanager.com https://js.stripe.com;
  style-src 'self' 'unsafe-inline' https://fonts.googleapis.com;
  font-src 'self' https://fonts.gstatic.com;
  img-src 'self' data: https:;
  frame-src https://js.stripe.com https://www.youtube-nocookie.com;
  connect-src 'self' https://www.google-analytics.com;
  frame-ancestors 'none';
  report-uri /csp-report

Build the allowlist from your Step 1 inventory. Point report-uri at a small endpoint (or a hosted service) and let real traffic exercise every page, including the checkout and the rarely-visited account pages, for at least a week.

Stage B: Fix the violations

Review the reports and dev-tools console. The usual findings:

Violation	Cause	Fix
inline script blocked	onclick= handlers, inline script tags	move to external files, or add per-response nonces
eval blocked	old libraries, some tag managers	upgrade library; avoid 'unsafe-eval'
unknown origin	a script loading a script	add the origin, or drop the widget
data: font	icon fonts embedded in CSS	allow font-src data: or switch to SVG icons

The gold standard for scripts is nonces: the server generates a random value per response, adds it to the header (script-src 'nonce-R4nd0m') and to each legitimate script tag. Injected scripts lack the nonce and die. 'strict-dynamic' (CSP Level 3) then lets a nonce-approved script load its own dependencies - this is Google's recommended pattern and dramatically shrinks the allowlist.

Accept 'unsafe-inline' for styles if removing it is disproportionate work - the practical risk of inline CSS is far lower than inline JS. Do not accept 'unsafe-inline' for scripts; it disables the header's main value.

Stage C: Enforce

Rename the header to Content-Security-Policy, keep the reporting endpoint active permanently, and watch the first 48 hours. Any regression is one config line away from rollback to Report-Only.

Step 5 - Web-server configuration

Set headers in one central place - the web server or CDN - not per-application, so every response (including error pages and static assets) is covered.

nginx (inside the server block; always is required so headers also attach to 4xx/5xx responses):

server_tokens off;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "DENY" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Content-Security-Policy "default-src 'self'; ..." always;

Beware the classic nginx trap: add_header directives are not inherited if a location block declares its own add_header. Keep them all at server level, or repeat the full set.

Apache (in the vhost or .htaccess, with mod_headers enabled):

ServerTokens Prod
ServerSignature Off
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "DENY"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
Header always set Content-Security-Policy "default-src 'self'; ..."

On CDNs (Cloudflare, CloudFront, Vercel, Netlify) use their response-header transforms so the edge applies the same set to cached responses.

Step 6 - Verify and keep verifying

After each change: hard-refresh with dev tools open and read the actual response headers; then re-run the headers checker and compare against the Step 1 baseline. A well-hardened site reaches grade A.

Headers rot. A redesign adds a widget that CSP blocks; a migration to a new load balancer silently drops the whole set. Put verification on a schedule - FortifyNet's continuous monitoring re-checks headers and alerts on any change, which is exactly the "config drift" failure mode that manual processes miss.

Cookie hardening - the forgotten response headers

Session cookies are set by response headers too, and a hardened header set is incomplete without them. Three attributes on every Set-Cookie:

\Set-Cookie: session=abc123; Secure; HttpOnly; SameSite=Lax; Path=/ \\

Secure - the cookie is never sent over plain HTTP. With HSTS in place this closes the loop entirely.
HttpOnly - JavaScript cannot read the cookie, so even a successful XSS cannot exfiltrate the session token directly.
SameSite=Lax (or Strict) - the browser withholds the cookie on cross-site requests, neutralizing most CSRF attacks at zero code cost. Use SameSite=None; Secure only for cookies that genuinely must travel cross-site (embedded widgets, SSO flows).

Consider cookie prefixes for defense in depth: a cookie named __Host-session is only accepted by browsers if it is Secure, has no Domain attribute and Path=/ - making it impossible for a compromised subdomain to overwrite it.

Cross-origin isolation - COOP, CORP and CORS sanity

Three newer headers control how your site interacts with other origins at the browser level:

Header	Recommended value	What it prevents
Cross-Origin-Opener-Policy	same-origin	other sites holding a scriptable reference to your window (tabnabbing, XS-Leaks)
Cross-Origin-Resource-Policy	same-origin (or same-site)	other origins embedding your resources (data theft via inclusion)
Cross-Origin-Embedder-Policy	require-corp (advanced)	loading cross-origin resources that haven't opted in

COOP: same-origin and CORP: same-origin are safe for most sites and worth deploying in the same change as Step 2. COEP is stricter - it breaks any cross-origin image or script that does not send CORP headers itself - so deploy it only if you need cross-origin isolation (e.g. for SharedArrayBuffer) and test in Report-Only first (Cross-Origin-Embedder-Policy-Report-Only exists for exactly this).

While here, sanity-check CORS: Access-Control-Allow-Origin: * on an API that uses cookies or returns user data is a real vulnerability, not a convenience. Allow specific origins, and never reflect the request's Origin header back unvalidated.

Caching sensitive responses

Header hardening includes making sure private data is not stored where you cannot delete it. For any authenticated or personal-data response:

\Cache-Control: no-store \\

no-store beats the older Pragma and Expires combinations and prevents both browser and intermediary caching. The classic failure: a logout button that works, but the back button still shows the account page from browser cache - no-store on authenticated pages fixes it. Keep long-lived caching (Cache-Control: public, max-age=31536000, immutable) for fingerprinted static assets; the two policies coexist per-route.

Notes for SPAs and frameworks

Single-page applications change the CSP calculus slightly:

The HTML shell is served once, so nonces must be generated per response at the edge or server - a static site generator that bakes one nonce into the build has zero security value. If the site is fully static, use hashes (sha256-…) of the specific inline scripts instead of nonces.
Hydration frameworks (Next.js, Nuxt) inline state as script tags; both support nonce propagation from middleware - use the framework's documented CSP integration rather than fighting it.
connect-src is the SPA's most active directive: every API origin, websocket endpoint and telemetry sink must be listed. Missing entries fail silently for users (requests blocked, features dead) - another reason the Report-Only stage is non-negotiable.
For APIs consumed by browsers, apply the same base headers to API responses: nosniff, no-store where relevant, and a restrictive CSP (default-src 'none') on any endpoint that could ever be opened directly in a browser tab.

Verifying from the command line

Scanners are convenient, but you should also be able to verify headers directly - especially when debugging why a header is present on one route but missing on another (the nginx inheritance trap, a CDN transform applied to only one path pattern, or an application framework overriding the server). Use curl with the head-request flag (uppercase I), or the Network panel in the browser's developer tools, and read the raw response headers for three URLs: the homepage, an authenticated-area route, and a page that does not exist. A healthy response looks like this:

\HTTP/2 200 content-security-policy: default-src 'self'; ... permissions-policy: camera=(), microphone=(), geolocation=() referrer-policy: strict-origin-when-cross-origin strict-transport-security: max-age=31536000; includeSubDomains x-content-type-options: nosniff x-frame-options: DENY \\

Check all three cases: the homepage, an authenticated-area route, and a 404. Repeat the check over both HTTP and HTTPS, and on the www and bare-domain variants if both are served - redirects frequently come from a different configuration block that carries none of the hardening, and an SSL-stripping attack begins at exactly that unprotected first hop. The error page is the other classic gap - frameworks often serve error responses through a different code path that skips middleware, and an attacker probing your site sees mostly error pages. If the 404 lacks headers that the homepage has, the set is not applied centrally enough; move it to the server or edge layer.

Two more habits worth automating:

CI check: a five-line script in the deployment pipeline that curls the staging URL and fails the build if an expected header is missing. This catches the "new load balancer dropped everything" regression before production does.
Change alerting in production: external monitoring that re-reads the live header set on a schedule and alerts on any difference - this is part of FortifyNet's continuous monitoring, and it is how you learn about the regression that CI could not see, such as a CDN configuration edit made directly in the provider's dashboard.

Common myths and mistakes

"We have a WAF, headers are redundant." A WAF inspects traffic to your server; headers control what the browser does with your pages, including attacks that never touch your infrastructure. They are complementary layers.
"X-XSS-Protection should be enabled." No - the header is deprecated; the auditor that flags its absence is out of date. Modern browsers removed the XSS auditor it controlled, and in old browsers it introduced vulnerabilities. Set it to 0 or omit it entirely; CSP is its replacement.
"CSP broke the site once, so we removed it." The failure was skipping Report-Only, not CSP itself. Re-run the staged process.
"Grade A means secure." Headers are one layer. An A-grade site with an unpatched CMS is still one plugin CVE from compromise - which is why the header scan is one test among several in a full FortifyNet audit.

Rollout checklist

[ ] Baseline scan saved; third-party origin inventory complete
[ ] HSTS, nosniff, X-Frame-Options, Referrer-Policy, Permissions-Policy deployed
[ ] Server/X-Powered-By version leakage removed
[ ] CSP running in Report-Only with reporting endpoint
[ ] Violations triaged; nonces used for scripts; no 'unsafe-inline' for script-src
[ ] CSP enforced; frame-ancestors set; reporting kept on
[ ] Headers set centrally (server/CDN), always/Header always used
[ ] Re-scan shows grade A; continuous monitoring enabled

Sources

Originally published at fortifynet.com/blog/guide-security-headers-hardening. I'm the founder of FortifyNet, a website security scanner; this article comes from our blog, so factor in that founder bias when you read any tool recommendations here.

Website Incident Response Playbook: NIST-Based Plan for Small IT Teams

Håkan Fägnell — Sat, 29 Aug 2026 04:45:29 +0000

When a company website is defaced, starts serving malware, or quietly leaks its customer database, the difference between a bad day and an existential event is rarely technical skill - it is whether anyone wrote down, before the incident, who decides what, in which order, with which accesses. This guide gives IT managers at small and mid-sized organizations a complete, practical incident response plan for website and web-application incidents, built on the structure of NIST SP 800-61 and adapted to teams of one to five people rather than a 24/7 SOC.

Work through it once in calm conditions (roughly one working day), and you will have a printed playbook, a contact card, and tested backups - the three artifacts that consistently separate quick recoveries from week-long outages.

The incident lifecycle

Every credible framework uses some version of the same loop. Print this; it is the spine of the whole plan:

   +--------------+     +-----------------+     +--------------+
   | 1. PREPARE   | --> | 2. DETECT &     | --> | 3. CONTAIN   |
   |  plan, roles |     |    ANALYZE      |     |  stop spread |
   |  backups     |     |  triage, scope  |     |  preserve    |
   +--------------+     +-----------------+     |  evidence    |
          ^                                     +------+-------+
          |                                            |
   +------+-------+     +-----------------+     +------v-------+
   | 6. LEARN     | <-- | 5. RECOVER      | <-- | 4. ERADICATE |
   |  post-mortem |     |  restore,       |     |  remove      |
   |  fix causes  |     |  monitor,       |     |  cause,      |
   +--------------+     |  notify         |     |  patch       |
                        +-----------------+     +--------------+

Phase 1 - Preparation (do this now, not during the fire)

1.1 Define severity levels and who decides

Ambiguity about "how bad is this" wastes the first critical hour. Adopt three levels:

Level	Definition	Examples	Who is woken up
SEV-1	Confirmed compromise or data breach	defacement, malware served, database exfiltrated, ransomware	IT lead + CEO immediately
SEV-2	Strong indicators, no confirmed damage	credential stuffing spike, vulnerable component actively probed, admin login from unknown country	IT lead, business hours+
SEV-3	Suspicious but likely benign	single phishing report, scanner noise, one-off WAF block	logged, reviewed weekly

Name an Incident Commander (IC) - the person who coordinates, decides and communicates - and one deputy for vacations. In a small company the IC is usually the IT manager; the point is that it is one named person, not "the team".

1.2 Build the contact card

During an incident you will not have time to search for logins. Prepare a one-page card (printed and in a shared password manager) with:

Hosting provider: support phone/portal, account number, who holds admin access
Domain registrar and DNS provider: same
CMS/platform admin accounts and where their credentials live
CDN/WAF provider (Cloudflare etc.) access
Cyber-insurance policy number and 24h hotline, if insured
External IR/forensics firm you would call for a SEV-1 (pick one now; retainers are cheap compared to emergency onboarding)
Data protection authority contact (for Sweden: IMY; EU-wide list at the EDPB)
Internal: CEO, communications owner, legal counsel

1.3 Backups you have actually restored

A backup that has never been test-restored is a hope, not a control. Requirements:

3-2-1 rule: three copies, two media, one off-site - and the off-site copy must be offline or immutable (object-lock / snapshot), because modern ransomware deletes reachable backups first.
Backup scope: web root, database, server configuration (nginx/Apache, cron), TLS certificates and - often forgotten - the environment variables/secrets the app needs to boot.
Quarterly restore drill: restore to a scratch VM, boot the site, log in. Time it. That number is your realistic Recovery Time Objective, not the one in the policy document.

1.4 Detection you will actually notice

Small teams do not watch dashboards; alerts must come to them. Minimum set: uptime monitoring with alerting, file-integrity or defacement detection on the web root, admin-login notifications from the CMS, and external monitoring of your domain's security posture and certificate/DNS changes - FortifyNet's continuous monitoring covers the external half and emails you on change, which is precisely how defacements and expired certificates are usually caught late.

Phase 2 - Detection & analysis (the first hour)

When an alert or report arrives, the IC runs triage - in writing, in a dedicated channel (create #incident-YYYYMMDD), because the timeline you write now is the post-mortem and possibly the legal record later.

Triage questions, in order:

Is it real? Reproduce the symptom from an outside network (mobile hotspot) - CDN caches and split DNS often fool internal checks.
What is the scope? One page or entire site? Web server only, or database too? Are customer credentials or personal data plausibly involved? (This answer starts the GDPR clock - see Phase 5.)
Is it ongoing? Live traffic from the attacker, or the residue of a past event?
Assign severity from the 1.1 table and notify accordingly.

Evidence rule from the first minute: copy logs off the affected server immediately (access logs, error logs, auth logs, CMS audit trail). Attackers commonly delete logs; hosting providers rotate them within days. Do not power off a server you may need forensics from - isolate it instead (see below); powering off destroys memory-resident evidence.

Phase 3 - Containment

Containment stops the bleeding without destroying evidence. Choose the least destructive action that stops ongoing harm:

Site serving malware/defacement: put the site into maintenance mode at the CDN/load-balancer level, or geo-block/challenge all traffic. Users see a clean holding page; the compromised origin stays intact for analysis.
Compromised admin account: disable that account and rotate all admin credentials and API keys - assume the attacker harvested the credential store. Enforce MFA in the same change.
Server-level compromise: isolate at the network level (security group/firewall: block all inbound except your management IP). Take a disk snapshot before changing anything if your host supports it.
Database exfiltration: rotate database credentials, revoke external access, and preserve query logs.

Two containment mistakes to brief the team on in advance: (1) restoring from backup before understanding the entry point - you restore the vulnerability with the data and get re-compromised within hours; (2) communicating on potentially compromised infrastructure - if the mail server may be affected, coordinate on phones/Signal.

Phase 4 - Eradication

Find and remove the root cause, not just the symptom:

Establish the entry point from the evidence: unpatched CMS/plugin (the majority of small-business web incidents), stolen credentials, exposed admin panel, vulnerable upload form, or a hosting-level breach.
Rebuild rather than clean. For any server-level compromise, deploy a fresh server from a known-good image and migrate verified data into it. Cleaning a rooted box is unreliable; webshells hide in innocuous files and cron entries.
Patch the entry point everywhere it exists (staging too), update all components, and re-scan.
Rotate every secret the compromised system could read: DB passwords, API keys, OAuth secrets, TLS private keys if key material could have been read.

Phase 5 - Recovery and notification

Technical recovery

Restore service progressively: bring the rebuilt site up behind the CDN, run an external scan to confirm nothing malicious is served, watch error rates and logs at elevated attention for 72 hours, and keep the tightened firewall rules. If the site was flagged by Google Safe Browsing, request review via Search Console - delisting typically takes hours to a couple of days after cleanup.

Legal notification - the 72-hour rule

Under GDPR Article 33, a personal-data breach must be reported to the supervisory authority within 72 hours of becoming aware of it, unless the breach is unlikely to risk individuals' rights. Article 34 additionally requires notifying the affected individuals when the risk is high (e.g. leaked passwords or payment data). Practical points:

The clock starts at awareness, not at full understanding. A partial report ("we have confirmed unauthorized access, scope under investigation") within 72 hours is compliant; silence is not.
Document the assessment even when you decide not to notify - the reasoning is itself required.
Organizations under NIS2 obligations have a faster track: early warning to the CSIRT within 24 hours, incident notification within 72 hours.

Communication

One voice: the IC or the designated communications owner. Internally, short factual updates at a fixed cadence (even "no change"). Externally, honesty beats spin - state what happened, what data was involved, what users should do (password reset), and what you have changed. Companies are rarely punished by customers for having an incident; they are punished for hiding it.

Phase 6 - Post-incident review

Within two weeks, run a blameless post-mortem (one hour, IC facilitates): timeline, root cause, what worked, what was slow, and 3–5 concrete actions with owners and dates - e.g. "enable auto-updates for plugins", "move backups to immutable storage", "add file-integrity monitoring". Feed the actions into the normal work backlog; an unassigned lesson is a lesson not learned.

Finally, schedule a tabletop exercise twice a year: pick a scenario (defacement discovered by a customer on Friday 17:30 is a classic), walk the team through this playbook verbally, and note every point where someone says "hmm, I'm not sure who…". Those pauses are the plan's bugs - fix them on paper before an attacker finds them in production.

Worked example - the Friday-evening defacement

Theory sticks better with a timeline. Here is how the playbook runs for the most common SMB scenario: a customer emails at 17:42 on a Friday saying your homepage "looks strange".

17:45 - Detect. The on-call IT manager (IC by default) opens the site from a phone on mobile data: the homepage shows an attacker's banner. Screenshot taken. #incident-20260828 channel created; SEV-1 declared (confirmed compromise); CEO texted per the severity table.
17:55 - Evidence. Before touching anything: access and error logs from the past 14 days copied off the server to local storage; CMS audit log exported; disk snapshot triggered at the hosting provider.
18:05 - Contain. Site switched to maintenance mode at the CDN. Customers now see a neutral "back shortly" page. All CMS admin passwords rotated from a known-clean laptop; MFA enforced; the one unfamiliar admin account found in the user list is disabled, not deleted (it is evidence).
18:40 - Analyze. The CMS audit log shows the rogue admin was created Tuesday 03:14 via a vulnerable gallery plugin (version three releases behind). Database tables for customers appear untouched per query logs - noted, with reasoning, in the channel for the GDPR assessment.
19:30 - Eradicate. Fresh server deployed from the host's stock image; latest clean backup (Monday) restored to it; CMS core and all plugins updated; the gallery plugin deleted outright; secrets rotated.
21:10 - Recover. DNS/CDN pointed at the new origin. External scan confirms clean content and headers. Maintenance mode lifted. Elevated log-watching agreed for the weekend, split between IC and deputy.
Monday - Notify & learn. GDPR assessment concluded: no personal data accessed, documented, no Article 33 report required. Post-mortem Wednesday produces three actions: auto-updates on, plugin inventory quarterly, file-integrity monitoring installed.

Total customer-visible downtime: about three hours, on a Friday night, with two people. That outcome is bought almost entirely in Phase 1 - the snapshot capability, the CDN maintenance switch, the tested backup and the severity table were all decided before 17:42.

Working with external parties

Three relationships determine how much help you get under pressure:

Hosting provider. Know in advance what they can do in an emergency: snapshots on demand? network isolation? log retention period? Their emergency response is often faster through the paid support tier - decide before the incident whether that tier is worth it (it usually is).
Forensics / IR firm. For any SEV-1 involving suspected data theft, ransomware or legal exposure, bring professionals in early - evidence handling mistakes in the first hours are irreversible. A named firm on a light retainer answers in hours; a cold call during a national ransomware wave may answer in weeks.
Cyber insurance. Read the policy now: most require notification within a fixed window and some require using the insurer's approved IR panel - engaging your own firm first can void coverage. Put both facts on the contact card.

If extortion enters the picture

If the incident comes with a ransom demand - for decryption, or for not publishing stolen data - slow down before anyone replies. Do not communicate with the attacker from personal or corporate accounts; involve legal counsel and, for significant demands, the police (in Sweden via polisen.se; many EU countries have national cybercrime reporting routes) before any contact. Paying is legal in most jurisdictions but funds the next attack, offers no guarantee, and may be sanctioned if the group is on a sanctions list - a check your legal counsel or insurer must make. Whatever is decided, decide it once, at management level, documented; extortion pressure is designed to force fast individual decisions, and the playbook's job is to prevent exactly that.

Measuring the capability

Two numbers, reviewed twice a year, tell you if the capability is improving:

MTTD (mean time to detect): time from compromise to awareness. The defacement example above had an MTTD of three days - the attacker got in Tuesday, you learned Friday. File-integrity monitoring would have cut it to minutes; that is the argument for the post-mortem action.
MTTR (mean time to recover): time from detection to restored service. Driven almost entirely by preparation quality: tested backups, pre-agreed containment switches, and a named decision-maker.

Tabletop exercises produce these numbers safely: time the walkthrough, note where the team stalls, and treat every "I'd have to look that up" as a finding.

Customer notification template

Have a draft ready so legal review is the only delay. Keep it factual, short and free of adjectives:

\`
Subject: Security incident affecting [service] - what happened and what we're doing

On [date] we detected unauthorized access to [system]. We took the
affected service offline within [X minutes/hours], removed the cause,
and restored service on [date/time].

What was affected: [specific data categories, or "no customer data,
based on our log analysis"].

What you should do: [reset your password / no action is required].

We have reported the incident to [authority] and engaged [external
experts] to verify our findings. We will update this page as the
investigation concludes: [status page URL].

Contact: security@yourcompany.com
`\

The one-page checklist

[ ] Severity table adopted; Incident Commander + deputy named
[ ] Contact card printed and stored in the password manager
[ ] 3-2-1 backups with an offline/immutable copy; restore drill done this quarter
[ ] Uptime, defacement and external posture monitoring alerting to phones
[ ] Evidence rule known: copy logs first, isolate - don't power off
[ ] Containment options pre-agreed with hosting/CDN provider
[ ] Rebuild-not-clean policy for server compromise
[ ] GDPR 72h / NIS2 24h notification duties mapped to your organization
[ ] Blameless post-mortem template ready; tabletop exercise scheduled

Sources

Originally published at fortifynet.com/blog/guide-website-incident-response. I'm the founder of FortifyNet, a website security scanner; this article comes from our blog, so factor in that founder bias when you read any tool recommendations here.

DMARC Monitoring: How to Read Your Reports | FortifyNet

Håkan Fägnell — Thu, 27 Aug 2026 04:45:30 +0000

DMARC monitoring means collecting and reading the aggregate reports that mail receivers send back to your domain every day, so you can see exactly who is sending email as you before you switch your policy to quarantine or reject. You turn it on by adding a rua=mailto: tag to your DMARC record. Within 24 to 48 hours, providers such as Google, Microsoft 365 and Yahoo start mailing you compressed XML files summarising every message that claimed your domain. Those files are the only evidence you get, and without them, moving to enforcement is guesswork.

What DMARC monitoring actually is

DMARC (Domain-based Message Authentication, Reporting and Conformance) does two jobs. The policy half tells receivers what to do with mail that fails authentication. The reporting half tells you what receivers are seeing. Monitoring is that second half, and it is the part most domain owners skip.

The mechanism is straightforward. When a receiving provider evaluates mail claiming your From domain, it counts the results. At the end of each UTC day it packages those counts into an XML file and emails it to the address in your rua= tag. RFC 9990 section 3.1.1.4 specifies that the reporting period covers a single UTC day beginning at 0000 UTC, which is why your first report arrives 24 to 48 hours after you publish the tag rather than immediately.

Reports are gzip compressed and small. Measured per-provider file sizes ran between 3.6 KB and 4.8 KB (Google 3,962 bytes, Yahoo 4,626, Fastmail 4,839) in the dataset published by Ashiq et al. at USENIX Security 2023. Storage is never the constraint. Volume is: a busy domain can receive hundreds of files a day, which is why almost nobody reads them by hand.

More than half of DMARC domains fly blind

DMARC policy distribution across the 1,670,975 domains that publish a record. Source: DMARCguard, State of Email Authentication 2026, scan of 5,499,028 Tranco domains, 27 February 2026.

That same scan found only 894,057 of those 1,670,975 domains (53.5%) publish a rua= tag. The other 776,918 have a policy and no telemetry at all.

The consequence shows up in the policy split above. 57.9% of DMARC domains, 967,474 of them, sit at p=none. Monitoring-only mode is meant to be a staging area, not a destination, and the reason so many domains never leave it is simple: without reports there is nothing to base the decision on.

The stakes are not theoretical. The FBI's Internet Crime Complaint Center recorded $2.77 billion in Business Email Compromise losses across 21,442 complaints in its 2024 annual report. On the other side of the ledger, after Google and Yahoo enforced bulk-sender authentication requirements in February 2024, Gmail reported 265 billion fewer unauthenticated messages that year (Neil Kumaran, Group Product Manager, Gmail Security and Trust, October 2024).

Turning reporting on

Add a rua= tag to the TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; fo=1

Check what is currently published with a DNS lookup:

dig +short TXT _dmarc.yourdomain.com

Three rules worth knowing before you edit DNS:

One record only. RFC 9989 requires exactly one DMARC TXT record per domain. Publish two and receivers apply no policy at all, silently disabling DMARC.
No rua= means no reports. Receivers must not generate aggregate feedback without the tag. There is no opt-in anywhere else.
Coverage is partial by design. Microsoft's own documentation, updated 14 May 2026, states that not all receivers send reports and that coverage is typically 70 to 90 percent of total mail volume. Apple iCloud and Proton are not documented as report senders at all.

Sending reports to a different domain

If your rua= address sits on a different organisational domain than the policy, that receiving domain has to authorise it. RFC 9990 section 4 requires a TXT record at <your-domain>._report._dmarc.<reporting-domain> containing v=DMARC1;. Without it, receivers silently stop sending. This is the single most common reason a correctly written rua= tag produces no reports at all.

Aggregate reports versus failure reports

	Aggregate reports (RUA)	Failure reports (RUF)
Specification	RFC 9990	RFC 9991
Cadence	Once per UTC day, per provider	Near real time, per message
Content	Counts per source IP with SPF and DKIM alignment plus the applied disposition	Details of one failing message, potentially including headers and body
Privacy	Aggregated counts, no message content	RFC 9991 states reports may contain personally identifiable information
Provider support	Broad: Google, Microsoft 365, Yahoo, Mail.ru, Fastmail, Zoho	Rare. Microsoft 365 does not send them even with a valid `ruf=`
Best used for	Building the sender inventory and deciding when to enforce	Diagnosing one specific failure you can reproduce

Start with RUA. Almost everything you need to reach p=reject safely is in the aggregate data, and it carries none of the privacy baggage of failure reports.

Reading a report: the four outcomes that matter

Each <record> block in the XML pairs a source IP with a message count, the raw SPF and DKIM results, and a policy_evaluated verdict. What matters is alignment, not raw authentication. SPF or DKIM has to pass and match your From domain for DMARC to pass.

SPF aligned	DKIM aligned	What it means	What to do
Pass	Pass	Healthy. Your own infrastructure, correctly configured	Nothing. This is the target state for every legitimate sender
Pass	Fail	The sender is authorised but is not signing, or is signing with its own domain	Enable DKIM at that service and align the `d=` domain to yours
Fail	Pass	Almost always forwarding or a mailing list. DMARC still passes	Safe. Do not add the forwarder to your SPF record
Fail	Fail	Either a legitimate sender you forgot about, or spoofing	Identify the IP. Authorise it, or leave it to be blocked at enforcement

The third row is the one people get wrong most often. Forwarding breaks SPF by design, because the envelope sender changes at the forwarding hop. That is precisely why DKIM matters as a fallback, and why the 43.0% of DMARC domains that rely on SPF alignment alone (DMARCguard, February 2026) are more fragile than they look.

What changed in 2026: RFC 9989, 9990 and 9991

In May 2026 the IETF published RFC 9989, RFC 9990 and RFC 9991. Together they obsolete RFC 7489 and move DMARC onto the Standards Track as a Proposed Standard for the first time since 2015, with reporting split into its own documents.

Item	RFC 7489 (2015)	RFC 9989 / 9990 (2026)	What you should do
`pct` tag	Supported, for partial rollout	Removed	Stop relying on it. Use the new `t=y` testing mode
`rf` and `ri` tags	Defined	Removed	Delete them at your next DNS edit
Organisational domain discovery	Public Suffix List	DNS tree walk	Nothing. This is a receiver-side change
Report XML namespace	`http://dmarc.org/dmarc-xml/0.1`	`urn:ietf:params:xml:ns:dmarc-2.0`	Any parser you run must accept both
DKIM `selector` in reports	Optional	Required	Fix generators or parsers that drop the field
`disposition` values	none, quarantine, reject	Adds `pass`	Handle the new value instead of rejecting the file
Unknown elements	Undefined	Ignore and continue (RFC 9990 section 5)	Never reject a report you do not fully understand

Your existing record keeps working. The v=, p=, sp=, rua=, ruf=, adkim=, aspf= and fo= tags all retain their meaning. In practice every major provider still emits legacy-shaped XML today, so expect a mixed window lasting years and parse tolerantly rather than strictly.

A safe four-stage rollout to p=reject

Weeks 1 to 2. Publish p=none with rua=. Change nothing else. Collect reports and build a list of every IP and service sending as you.
Weeks 3 to 6. Fix alignment. Add missing senders to SPF, enable DKIM everywhere, and confirm each third-party service signs with your domain rather than its own.
Weeks 7 to 8. Move to p=quarantine, optionally starting on a subdomain via sp=. Watch the reports for a full week for any legitimate sender you missed.
Week 9 onward. Move to p=reject, and keep rua= in place permanently. Monitoring is not scaffolding you take down after the build.

Rushing stage one is the classic failure. A quarterly invoice run or an annual campaign will not appear in two weeks of data, and it will bounce on the day you enforce.

FAQ

How often are DMARC reports sent?
Once per UTC day per reporting provider, covering a window that begins at 0000 UTC (RFC 9990 section 3.1.1.4). Your first report typically arrives 24 to 48 hours after you publish rua=.

Why am I not receiving any reports?
Most often the rua= address is on a different domain and the required authorisation record at <your-domain>._report._dmarc.<reporting-domain> is missing. Other causes: a syntax error in the DMARC record, two DMARC records published at once, or simply no mail claiming your domain during the window.

Is the DMARC report in my inbox legitimate?
Almost certainly. Genuine reports use the subject pattern Report Domain: <domain> Submitter: <reporter> Report-ID: <id> and attach compressed XML with a bang-separated filename. Real reports contain no links to click, no payment demands and no credential requests.

Do I still need monitoring after reaching p=reject?
Yes. New services get added, DNS gets edited, DKIM keys get rotated. Reports are how you find out something broke before your customers do.

Can I just delete the reports?
You can remove rua= to stop them, but that trades a cluttered inbox for zero visibility into who is spoofing you. Pointing rua= at an analyser is the better answer.

Check your setup in 60 seconds

Before you touch DNS, it helps to know exactly where you stand. FortifyNet's free scan reads your DMARC, SPF and DKIM records and tells you whether reporting is actually configured, whether your policy is at enforcement, and what is missing. It takes about a minute and needs no signup. Run a free scan at FortifyNet.

Originally published at fortifynet.com/blog/dmarc-monitoring. I'm the founder of FortifyNet, a website security scanner; this article comes from our blog, so factor in that founder bias when you read any tool recommendations here.

SPF Record Syntax: Mechanisms & Limits | FortifyNet

Håkan Fägnell — Sun, 23 Aug 2026 04:45:29 +0000

An SPF record is a single DNS TXT record, published at your domain's apex, that begins with v=spf1, lists the mail servers authorized to send on your behalf, and ends with an all mechanism telling receivers what to do with everything else. v=spf1 include:_spf.google.com ~all is a complete, valid record. Every other piece of SPF record syntax is a variation on those three parts - plus a set of hard limits that silently break records which otherwise look correct.

Those limits matter more than most people expect. In a scan of 5,499,028 domains from the Tranco list carried out on 27 February 2026, DMARCguard found that 56.0% publish an SPF record - ahead of DMARC (30.4%) and DKIM (22.7%) - but that 4.8% of those SPF records, 148,655 domains, exceed the 10-lookup ceiling set by RFC 7208 and therefore fail evaluation outright.

The three parts of every SPF record

Every valid record breaks down the same way:

v=spf1  ip4:203.0.113.10  include:_spf.google.com  -all
  |            |                    |               |
version    mechanism            mechanism      catch-all

The version tag. v=spf1 must be the first term and must match exactly. Anything else means the record is not an SPF record at all.
Mechanisms. Evaluated strictly left to right. The first mechanism that matches the connecting IP decides the result and evaluation stops immediately - order is not cosmetic.
The catch-all. An all mechanism as the final term. Anything published after all is ignored.

One thing worth being precise about: SPF checks the envelope sender used in the SMTP MAIL FROM command (the Return-Path) and the HELO identity. It does not check the From: header your recipient actually sees. Closing that gap is the job of DMARC, which is why the two are always deployed together. If you are still mapping out the wider setup, our DNS security configuration guide covers how SPF, DKIM, DMARC and DNSSEC fit together.

SPF once had a dedicated DNS record type (type 99). RFC 7208 §3.1 retired it in April 2014 - publish SPF as a TXT record only.

SPF mechanisms: the full reference

Mechanism	Matches when the sending IP…	DNS lookups	Notes
`all`	always matches	0	Must be the last term
`ip4:`	falls inside the given IPv4 address or CIDR range	0	`ip4:203.0.113.0/24` - costs nothing against the lookup limit
`ip6:`	falls inside the given IPv6 address or prefix	0	`ip6:2001:db8::/32`
`a`	matches an A or AAAA record of the domain	1	Bare `a` means the current domain; `a:mail.example.com` names another
`mx`	matches an address record of one of the domain's MX hosts	1	Each MX host must not resolve to more than 10 address records
`include:`	passes the included domain's own SPF evaluation	1, plus whatever the included record itself spends	The most-used mechanism and the usual cause of lookup blowouts
`exists:`	the expanded domain name has any A record	1	Used with macros for per-sender rules; rare in ordinary records
`ptr`	reverse DNS for the IP resolves back into the domain	1	RFC 7208 §5.5 states plainly: "This mechanism SHOULD NOT be published." Remove it

A subtlety that trips people up: include: is not a textual paste. It runs a full, separate SPF evaluation against the included domain and matches only if that evaluation returns pass. A -all inside an included record does not reject your mail - it simply makes the include: not match, and evaluation continues to your next mechanism.

Qualifiers: four characters that decide the verdict

Any mechanism can carry a qualifier prefix. RFC 7208 §4.6.2 defines exactly four, and the default is +.

Qualifier	Result	What it asks the receiver to do	When to use it
`+` (default)	pass	Treat the sender as authorized	Implicit - `+mx` and `mx` are identical
`~`	softfail	Accept, but mark as suspicious	`~all` during rollout, or where forwarding is common
`-`	fail	Treat as unauthorized; reject or bin	`-all` once every legitimate sender is listed
`?`	neutral	Make no statement either way	Practically the same as publishing nothing

Never publish +all. It authorizes the entire internet to send as your domain and is strictly worse than having no SPF record.

Modifiers: redirect and exp

Modifiers are name/value pairs rather than mechanisms, and they may appear only once each.

redirect=example.com replaces your record's result wholesale with the target domain's SPF result. It costs one DNS lookup and is ignored entirely if an all mechanism is present, so the two should not appear together.
exp=explain.example.com points at a TXT record supplying a human-readable explanation string returned on a fail. It costs no lookup at evaluation time.

The limits that break otherwise-valid records

This is where most real-world SPF failures live. All of the following come straight from RFC 7208 §3.4 and §4.6.4:

10 DNS-querying terms. The include, a, mx, ptr and exists mechanisms and the redirect modifier each consume one. Exceeding 10 MUST return permerror - a hard failure, not a warning. all, ip4, ip6 and exp are free.
2 void lookups. A query returning NXDOMAIN or an empty answer is a "void lookup". Implementations should cap these at two; exceeding the cap also produces permerror. Stale include: entries for services you no longer use are the usual culprit.
10 address records per mx or ptr. Beyond the overall budget, each individual MX host is capped at 10 A/AAAA records.
One record per domain. If a lookup returns more than one v=spf1 record, the result is permerror. Merge them into a single record; never publish two.
255 characters per string, 450 octets recommended overall. A TXT record can hold multiple quoted strings, concatenated without spaces. RFC 7208 §3.4 recommends keeping the whole DNS answer under 450 octets so it fits in a UDP packet.
A 20-second evaluation budget. Receivers should allow at least 20 seconds and return temperror past that.

Where your ten lookups actually go

Each third-party sender you add spends at least one lookup, and some spend more because their own records nest further includes.

Sender	Typical `include:`	Lookups consumed
Google Workspace	`_spf.google.com`	1
Microsoft 365	`spf.protection.outlook.com`	1
Mailchimp	`servers.mcsv.net`	1
SendGrid	`sendgrid.net`	1
Amazon SES	`amazonses.com`	1
Zendesk	`mail.zendesk.com`	1
Salesforce	`exacttarget.com`	2

Six or seven services and you are at the ceiling. The fixes, in order of preference: remove includes for services you have retired, move senders onto dedicated subdomains with their own SPF records, and only then consider flattening includes into literal ip4: ranges - flattening removes lookups but means you must track your providers' IP changes yourself.

Share of domains publishing an SPF record, by top-level domain. Source: DMARCguard, "State of Email Authentication 2026", scan of 5,499,028 Tranco domains, 27 February 2026.

Five syntax mistakes that cause PermError

Two v=spf1 records on the same name. Common after a migration. Merge, do not stack.
A qualifier on all that contradicts intent - ?all looks cautious but tells receivers nothing, so spoofed mail sails through.
Terms after all. Everything to the right of all is dead text.
Leftover ptr. Deprecated since 2014, slow, and it burns a lookup for no benefit.
Includes for retired vendors. They cost a lookup each and can turn into void lookups when the vendor removes the record.

How to check your own record

Read your record straight from DNS with a single query:

dig +short TXT example.com

On Windows, the equivalent is nslookup -type=TXT example.com. Look for exactly one string starting with v=spf1, then count the lookup-consuming terms by hand - and remember to count the ones hidden inside each include:.

Since February 2024, Google and Yahoo have required bulk senders (roughly 5,000 messages a day or more) to authenticate with both SPF and DKIM and to publish a DMARC record of at least p=none. A permerror from a broken SPF record puts that compliance at risk, so it is worth verifying rather than assuming.

Run a free 60-second FortifyNet scan and we will check your SPF record alongside DKIM, DMARC, your TLS configuration, security headers and dark-web exposure - no signup needed.

Frequently asked questions

Can a domain have two SPF records?
No. If a lookup returns more than one v=spf1 record, RFC 7208 §4.5 requires receivers to return permerror, which fails SPF entirely. Combine the mechanisms into one record.

Should I use -all or ~all?
Start with ~all while you confirm every legitimate sender is listed, then move to -all. -all is the stronger anti-spoofing signal, but only once your inventory of senders is genuinely complete.

Do ip4: entries count toward the 10-lookup limit?
No. ip4:, ip6:, all and exp cause no DNS queries at evaluation time and are exempt. Only include, a, mx, ptr, exists and redirect count.

Does SPF on its own stop spoofing?
No. SPF validates the envelope sender, not the From: header a recipient reads. An attacker can pass SPF on a domain they control while displaying yours. DMARC ties the two identities together, which is what actually closes the gap.

How long can an SPF record be?
Each individual string in a TXT record is capped at 255 characters, though multiple strings are concatenated. RFC 7208 recommends keeping the whole DNS answer under 450 octets so it survives in a UDP packet.

Related guides

Sources: RFC 7208, Sender Policy Framework (SPF) version 1, IETF, April 2014 (§3.1, §3.4, §4.5, §4.6.2, §4.6.4, §5.5, §6.1, §6.2) · DMARCguard, "State of Email Authentication 2026", scan of 5,499,028 Tranco domains, 27 February 2026 · Google and Yahoo bulk sender requirements, effective February 2024.

Originally published at fortifynet.com/blog/spf-record-syntax. I'm the founder of FortifyNet, a website security scanner; this article comes from our blog, so factor in that founder bias when you read any tool recommendations here.

ERR_CERT_COMMON_NAME_INVALID: Causes and Fixes | FortifyNet

Håkan Fägnell — Sat, 22 Aug 2026 04:45:29 +0000

ERR_CERT_COMMON_NAME_INVALID: What It Means and How to Fix It

ERR_CERT_COMMON_NAME_INVALID means the website presented a real, unexpired certificate, but that certificate was issued for a different name than the one in your address bar. Chrome compares the domain you requested against the hostnames listed in the certificate's Subject Alternative Name (SAN) field. If none of them match, Chrome blocks the page with this error. The fix depends on who you are: as a visitor you can usually resolve or safely judge it in minutes, while as a site owner you need to reissue or reconfigure a certificate. This guide covers both, with data on how common each cause really is.

What the error actually means

Every public HTTPS certificate carries a list of hostnames it is valid for, stored in the SAN extension. Browsers historically also accepted the certificate's Common Name (CN) field, which is where this error got its name. That fallback is long gone:

RFC 2818 deprecated CN matching for HTTPS back in the year 2000.
Chrome 58 removed CN matching entirely in April 2017 and has required SAN entries ever since (source: Chrome for Developers, "Deprecations and Removals in Chrome 58"). At the time, only about 0.1% of all certificate validations still relied on the CN fallback (Chromium security-dev, 2017).
RFC 9525 (November 2023), which replaced RFC 6125, made it formal across the industry: clients must check the SAN extension only and must not match domain names against the CN.

So despite its name, this error really means "SAN mismatch": nothing in the certificate's name list covers the host you asked for.

It is also remarkably common. In Google's study of over 300 million real-world Chrome certificate warnings (Acer et al., "Where the Wild Warnings Are", ACM CCS 2017), name mismatch was the single largest server-side cause of certificate warnings on desktop: 11.7% of all warning reports on Windows and 11.6% on Mac, ahead of untrusted authorities and expired certificates.

Server-side causes of Chrome certificate warnings as a share of all warning reports on Windows. Data: Acer et al., "Where the Wild Warnings Are", ACM CCS 2017.

The 7 common causes, and who can fix them

#	Cause	What is happening	Who fixes it
1	www mismatch	The certificate covers `www.example.com` but not `example.com`, or the reverse	Site owner
2	Subdomain outside wildcard scope	`*.example.com` does not cover `app.eu.example.com`	Site owner
3	Wrong or default server certificate	Shared hosting or a misconfigured server (SNI) answers with another site's certificate	Site owner
4	Stale DNS or a moved domain	The domain still points at a server that no longer hosts it, so a stranger's certificate answers	Site owner
5	CN-only certificate	A legacy or internal certificate has the right CN but no SAN entries; Chrome has rejected these since version 58 (April 2017)	Site owner / IT
6	Captive portal	Hotel or airport Wi-Fi intercepts your first request to show its login page	Visitor
7	HTTPS inspection	Antivirus or a corporate proxy re-signs traffic with its own certificate	Visitor / IT

Within name mismatches, subdomain mistakes stand out. In the same Google dataset, 13.2% of server name-mismatch errors were requests for subdomains outside a wildcard's scope, and 3.7% were plain www mismatches (Acer et al., CCS 2017). A further 3.8% of name mismatch errors matched known captive portal patterns, which means the network, not the website, caused them.

If you are a visitor: 5 quick checks

Try the other form of the address. If example.com fails, try www.example.com, or the reverse. If one works, the site has a www mismatch and you can tell the owner exactly that.
Look at who the certificate was issued to. Click the padlock or "Not secure" chip, open certificate details, and read the SAN list. A certificate for a hosting company's placeholder domain or a completely unrelated site explains the block instantly.
On public Wi-Fi, trigger the login page first. Captive portals intercept your first HTTPS request and answer with their own certificate. Open any plain HTTP page (for example a router status page or neverssl.com), complete the portal login, then retry.
Test with HTTPS inspection off. Some antivirus suites and corporate proxies re-sign TLS traffic. Temporarily disable HTTPS scanning or try another network; if the error disappears, the interception software is the cause.
Do not click through on sites that matter. For banking, email, or anything with a login, treat a name mismatch as a hard stop. The generic version of this warning is covered in our guide to the "Your connection is not private" error.

If you own the site: diagnose, then fix

Start by reading exactly which names your certificate covers. From any terminal with OpenSSL installed:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -ext subjectAltName

Run it twice, once with your apex domain and once with www, and compare the SAN output against every hostname your users actually visit. Then fix the cause you find:

Cover the apex and www together. Issue one certificate that lists both names. Let's Encrypt includes up to 100 hostnames per certificate at no cost (Let's Encrypt rate limit documentation), and every commercial CA sells multi-domain SAN certificates.
Mind wildcard scope. A wildcard matches exactly one label, per RFC 9525:

Name requested	Covered by `*.example.com`?
`app.example.com`	Yes
`example.com`	No, the apex needs its own SAN entry
`eu.app.example.com`	No, wildcards match one label only
`app.example.net`	No, different domain

Fix SNI and the default virtual host. If your server hosts several sites, make sure each hostname is tied to its own certificate and that the default (fallback) virtual host does not answer with the wrong one for clients or bots that omit SNI.
Check both ends of your CDN. With a CDN or reverse proxy in front, the edge certificate must cover your public hostname and the origin certificate must cover the origin hostname the CDN connects to. A mismatch on either leg triggers errors.
Do not rely on redirects. TLS is negotiated before any HTTP redirect is sent. Even if example.com immediately redirects to www.example.com, the certificate served on example.com must still cover that name.

One more reason to automate: under CA/Browser Forum ballot SC-081v3 (adopted April 2025), the maximum public certificate lifetime dropped from 398 to 200 days on March 15, 2026, falls to 100 days in March 2027, and reaches 47 days in March 2029. Renewals are becoming far more frequent, and every renewal is a fresh chance for a SAN list to silently lose a name. Use ACME automation and monitor your coverage instead of trusting memory.

FAQ

Is it safe to click "Proceed anyway"?
Only when you positively know why the mismatch exists, for example your own test server reached by IP address. On any site where you would type a password or payment details, do not proceed.

Does this error mean the site was hacked?
Almost never. It usually means a configuration mistake: a renamed domain, a forgotten www entry, or a wildcard that does not stretch as far as the owner thought. Attacks exist, which is exactly why browsers refuse to guess.

Why is it called "common name" if browsers ignore the CN field?
The name is historical. Browsers matched the CN field until RFC 2818 (2000) deprecated it and Chrome 58 (April 2017) removed it. Today only the SAN list counts, per RFC 9525 (November 2023), but the error identifier was never renamed.

Do I need a separate certificate for every subdomain?
No. One certificate can list many SAN entries, and a wildcard covers all direct subdomains at one level. You only need extra planning for deeper levels like a.b.example.com, which a single-level wildcard does not cover.

Check your certificate coverage in 60 seconds

A name mismatch is invisible until someone hits the one hostname you forgot. FortifyNet's free scan reads your live certificate and reports which names it covers, alongside your TLS configuration, security headers, DNS, email authentication, and dark-web exposure. Run the free scan on your domain and check apex, www, and subdomains in one pass.

Related guides

Originally published at fortifynet.com/blog/err-cert-common-name-invalid. I'm the founder of FortifyNet, a website security scanner; this article comes from our blog, so factor in that founder bias when you read any tool recommendations here.

X-Frame-Options: How It Works and How to Set It | FortifyNet

Håkan Fägnell — Wed, 19 Aug 2026 04:45:29 +0000

X-Frame-Options: What It Does and How to Configure It Right

X-Frame-Options is an HTTP response header that tells the browser whether your page may be rendered inside a frame or iframe on another site. It has exactly two valid values: DENY (no framing at all) and SAMEORIGIN (framing allowed only from your own origin). Its purpose is to stop clickjacking, an attack where your site is loaded invisibly inside an attacker's page and your visitors are tricked into clicking things they cannot see. The modern replacement is the Content-Security-Policy directive frame-ancestors, and the 2026 best practice is to send both headers. This guide covers the correct setup for every major server, plus the mistakes that silently disable the protection.

What the X-Frame-Options header does

When a browser loads a page that another document has embedded through <iframe>, <frame>, <embed> or <object>, it checks the response headers of the embedded page before rendering it. If the response carries X-Frame-Options: DENY, the browser refuses to draw the page inside the embedding document. With SAMEORIGIN, it renders the page only if the embedding chain comes from the same origin (same scheme, host and port). Modern browsers evaluate the entire chain of ancestor frames, not just the top window.

The header was formalized in RFC 7034 in October 2013, after browsers had already shipped it. It remains one of the most widely deployed security headers: the HTTP Archive Web Almanac 2025 security chapter measures X-Frame-Options on roughly 35% of mobile sites, making it a top three security header behind X-Content-Type-Options (close to 50%).

Clickjacking in 60 seconds

Clickjacking was named by security researchers Robert Hansen and Jeremiah Grossman in 2008. The attack is simple: an attacker's page loads your site in an iframe, makes the iframe fully transparent with CSS, and positions it over harmless looking buttons. The visitor believes they are clicking "Play video", but the click actually lands on your site's "Delete account", "Confirm payment" or "Authorize app" button, using the victim's logged-in session. OWASP documents variants ranging from Facebook "likejacking" to hijacked one-click purchases.

Framing control is the defense. If the browser refuses to render your page inside an attacker's frame, the overlay trick collapses.

The two valid values, and the ones to avoid

Value	Effect	Status in 2026
`DENY`	No site may frame the page, including your own	Valid, supported by all browsers
`SAMEORIGIN`	Only pages from the same origin may frame it	Valid, supported by all browsers
`ALLOW-FROM uri`	Was meant to allow one named origin	Obsolete: Firefox removed it in version 70 (October 2019), Chrome and Safari never supported it
`ALLOWALL`	Never part of any spec	Invalid: browsers ignore the header entirely, leaving no protection

The dangerous part is how browsers handle invalid values: they ignore the whole header. A site sending ALLOW-FROM or ALLOWALL believes it is protected while browsers treat it as if no header were set. As the Web Almanac 2025 puts it, these values "may have been set by developers expecting protections to be active due to them setting the header."

What real-world data shows

Across millions of sites measured by HTTP Archive in 2025, the header's values break down like this:

Source: HTTP Archive Web Almanac 2025, security chapter, figure 9.30 (mobile dataset).

About 72.1% of sites that send the header choose SAMEORIGIN and 24.6% choose DENY. Roughly 3% send values that do nothing, which on the scale of the web is hundreds of thousands of sites with imaginary protection. Checking what your server actually sends takes less than a minute.

X-Frame-Options vs CSP frame-ancestors

The W3C Content Security Policy Level 2 specification (a W3C Recommendation since December 2016) introduced the frame-ancestors directive and formally obsoleted X-Frame-Options. Where XFO is a blunt on/off switch, frame-ancestors is a full allowlist:

Capability	X-Frame-Options	CSP frame-ancestors
Block all framing	`DENY`	`frame-ancestors 'none'`
Allow own origin only	`SAMEORIGIN`	`frame-ancestors 'self'`
Allow named partner origins	Not possible (ALLOW-FROM is dead)	`frame-ancestors 'self' https://partner.example.com`
Wildcard subdomains	Not possible	`frame-ancestors https://*.example.com`
Spec status	Informational RFC 7034 (2013), obsoleted	W3C CSP Level 2 (2016), current standard
When both headers are present	Ignored by CSP2-capable browsers	Takes precedence

Two details worth knowing. First, MDN notes that frame-ancestors does not inherit from default-src: a policy of default-src 'none' still allows anyone to frame the page, so you must declare the directive explicitly. Second, all current versions of Chrome, Edge, Firefox and Safari support frame-ancestors, so the only reason to keep sending X-Frame-Options is defense in depth for very old clients. That costs one line, so keep it.

How to configure it on your server

Send the header on every HTML response, exactly once. The examples below set SAMEORIGIN plus the equivalent CSP directive.

nginx (inside server or location):

add_header X-Frame-Options "SAMEORIGIN" always;
add_header Content-Security-Policy "frame-ancestors 'self';" always;

Apache 2.4 (httpd.conf or .htaccess, mod_headers enabled):

Header always set X-Frame-Options "SAMEORIGIN"
Header always set Content-Security-Policy "frame-ancestors 'self';"

IIS (web.config):

<system.webServer>
  <httpProtocol>
    <customHeaders>
      <add name="X-Frame-Options" value="SAMEORIGIN" />
      <add name="Content-Security-Policy" value="frame-ancestors 'self';" />
    </customHeaders>
  </httpProtocol>
</system.webServer>

Node.js with Express and Helmet:

const helmet = require("helmet");
app.use(helmet.frameguard({ action: "sameorigin" }));
app.use(helmet.contentSecurityPolicy({
  directives: { frameAncestors: ["'self'"] }
}));

Behind a CDN such as Cloudflare you can also inject both headers with a response header transform rule, which is useful when you cannot touch the origin server. If a partner site legitimately needs to embed you, keep XFO at SAMEORIGIN and express the allowlist in CSP: frame-ancestors 'self' https://partner.example.com.

Mistakes that silently disable the protection

Using ALLOW-FROM in 2026. Every current browser ignores it, and with it the whole header.
Setting the header in a meta tag. X-Frame-Options only works as an HTTP header, and frame-ancestors is explicitly forbidden inside <meta http-equiv="Content-Security-Policy">. Both must come from the server.
Sending the header twice. Duplicate or comma-joined values such as SAMEORIGIN, SAMEORIGIN (0.28% of sites in the Almanac 2025 data) can be rejected as invalid. Set it in one place only, either the app or the web server, not both.
Using DENY on pages you embed yourself. If your own checkout, widget or preview runs in an iframe, DENY breaks it. Use SAMEORIGIN or an explicit frame-ancestors allowlist.
Assuming default-src covers framing. It does not. Declare frame-ancestors explicitly.

How to test your configuration

Open your browser's developer tools, load your page, and inspect the response headers on the main document: you should see exactly one X-Frame-Options and a Content-Security-Policy containing frame-ancestors. For the full picture, the free FortifyNet scan checks your framing protection together with the rest of your security header set, SSL/TLS, DNS and email authentication in about 60 seconds, and tells you exactly which header to add where. No signup needed.

Related guides

FAQ

Is X-Frame-Options deprecated?
Formally yes: W3C CSP Level 2 obsoleted it in favor of frame-ancestors back in 2016. In practice every browser still honors it, and OWASP recommends sending both headers for defense in depth. The one thing you must not do is rely on ALLOW-FROM.

Should I use DENY or SAMEORIGIN?
Use DENY if nothing on your site is ever shown in a frame, which is the strongest setting. Use SAMEORIGIN if your own pages embed each other, for example dashboards, previews or internal widgets. In the 2025 Web Almanac data, 72.1% of sites choose SAMEORIGIN.

How do I allow one specific partner site to embed my pages?
X-Frame-Options cannot do this anymore. Use Content-Security-Policy: frame-ancestors 'self' https://partner.example.com and list each allowed origin explicitly.

What happens if I send both X-Frame-Options and frame-ancestors?
Browsers that support CSP Level 2, which is all modern ones, enforce frame-ancestors and ignore X-Frame-Options. Older clients fall back to X-Frame-Options. That fallback chain is exactly why sending both is the recommended setup.

Can I set X-Frame-Options with a meta tag?
No. Browsers only honor it as a real HTTP response header. If you cannot change server configuration, set it through your hosting panel, CDN rules or application middleware.

Originally published at fortifynet.com/blog/x-frame-options. I'm the founder of FortifyNet, a website security scanner; this article comes from our blog, so factor in that founder bias when you read any tool recommendations here.