DEV Community: Pro Gineous

Why Your SPF Record Fails With Too Many DNS Lookups, and How to Get Back Under 10

Pro Gineous — Sat, 31 Oct 2026 09:05:02 +0000

Your SPF record can look perfect, list every service that sends mail for you, and still fail on every single message. If a DMARC report or a bounce shows spf=permerror, the usual reason is that the record needs more than 10 DNS lookups to evaluate, and receivers stop counting at 10.

The limit comes from RFC 7208, the SPF standard. It exists so that checking one email can't turn into hundreds of DNS queries. The catch is that you don't only pay for the lookups in your own record. Every include pulls in the vendor's record, and that record can have includes of its own. Here's how to count what yours really costs and how to trim it without breaking mail from the services you still use.

Where the error shows up

SPF too many DNS lookups is a quiet failure. Mail doesn't bounce on the spot. Instead you see some of these:

spf=permerror in the Authentication-Results header of a message you sent to an outside mailbox
DMARC aggregate reports where SPF fails for your own mail servers, even though their IPs are clearly listed
An online checker saying "too many DNS lookups" or "PermError"
Mail that started landing in spam right after you added a new tool to the record

A permerror isn't a pass, so as far as DMARC is concerned SPF failed. If DKIM still passes and is aligned, DMARC passes anyway, which is why the problem can sit there for months. Once you tighten DMARC, or DKIM breaks for one sender, those messages start getting rejected. If you're not sure how to read those reports, start with our guide on reading DMARC reports.

What counts toward the 10

Only terms that make the receiver ask DNS something count. That's include, a, mx, ptr, exists and the redirect modifier. Each costs one lookup, and every one of those inside an included record costs one too.

These are free: ip4, ip6, all and exp. You can list fifty IP ranges and pay nothing.

Two more rules sit next to the main one. An mx term can't point at a name with more than 10 MX hosts. And there's a limit of two "void" lookups, meaning queries that come back with no answer at all. A typo in an include, or an old vendor domain that no longer publishes SPF, eats one of those, and the record also fails with a permerror on its own, because an include must point at a real SPF record.

Receivers usually evaluate the record from left to right and stop at the first match, so in theory a sender listed early never hits the limit. Don't plan around that. Mail from a server that isn't in your record, including every forged message, walks the whole thing, and you want those to get a clean fail rather than a permerror.

Count it by hand once

It's worth doing this once with dig so the number makes sense. Start with your own record:

dig +short TXT example.com | grep spf1

Then follow each include. This is real output for one popular sending service:

$ dig +short TXT sendgrid.net
"v=spf1 ip4:167.89.0.0/17 ip4:208.117.48.0/20 ip4:50.31.32.0/19 ip4:198.37.144.0/20 ip4:198.21.0.0/21 ip4:192.254.112.0/20 ip4:168.245.0.0/17 ip4:149.72.0.0/16 ip4:159.183.0.0/16 ip4:134.128.64.0/18 ip4:159.26.176.0/20 include:ab.sendgrid.net ~all"

Eleven ranges are free, but the include:ab.sendgrid.net at the end isn't. So include:sendgrid.net in your record costs two lookups, not one. Repeat that for every include and add it up. If dig's output format is unfamiliar, our walkthrough on reading dig output explains each part.

One detail that trips people up: a long TXT record comes back as several quoted strings, like "...ip4:62.253.2" "27.114...". Receivers glue those together with no space in between, so that's one address, 62.253.227.114, not two broken ones.

Count it with one command

Doing that by hand for eight vendors gets old fast, so we wrote a small read-only script that walks the whole tree the way a receiver does. It prints every lookup with a running total, the cost of each term in your record, and the void lookup count.

./email/spf-lookup-count.sh example.com
./email/spf-lookup-count.sh --doh example.com          # ask 1.1.1.1 over HTTPS
./email/spf-lookup-count.sh --record "v=spf1 ..." example.com   # test a draft

Here's a real run against a draft record for a business that sends through a mailbox provider, a transactional mail service, a newsletter tool, a CRM, a help desk and its web host:

Twelve lookups for eight terms. The web host's include alone costs three, because it includes two relays of its own. Nothing in that record is wrong on its face, and every term looks like one lookup when you read it. That's exactly why this error is so common.

Getting back under 10

Work through these in order. The first ones are free and safe, the last one needs care.

Remove senders you no longer use. Old newsletter tools and trial CRMs stay in SPF for years. Ask around before deleting, but each dead include is pure cost.

Check which domain SPF is checked against. SPF looks at the envelope sender, the Return-Path, not the From address people see. Many bulk senders use their own bounce domain, or a subdomain of yours like bounces.example.com with its own SPF record. If that's the case for a service, its include on your root record does nothing. Open a message it sent, look at Return-Path and the spf= result, and only then remove it.

Swap a and mx for addresses. a and mx each cost a lookup just to say "the web server" and "the mail server". If those servers have fixed IPs, write ip4:192.0.2.10 instead. And if your outgoing mail already goes through the mailbox provider's include, mx is often redundant, because the MX hosts receive mail and don't send it.

Move a heavy sender to a subdomain. Marketing mail from news.example.com gets its own SPF record with its own budget of 10.

Flatten as a last resort. Flattening means replacing an include with the IP ranges it resolves to. It works today and breaks quietly the day the vendor adds a new range, so only do it with a tool that refreshes the list on a schedule, and never for a large provider that changes ranges often.

In the draft above, replacing a and mx with the server's IP and dropping the newsletter include (say it sends with its own Return-Path) brings the count to 9. That's legal, but close. One more vendor and it's back over.

Test before you publish

Because --record counts a draft without touching DNS, you can try a change first and publish only the version that passes. When you do publish, keep one SPF record per name. Two v=spf1 TXT records on the same name is its own permerror, and it's the most common mistake when a new vendor's setup guide says "add this record". Merge their include into the existing one instead. Our guide on keeping email out of spam covers the rest of the record set.

After the change, send a message to an outside mailbox and check that the header now says spf=pass. Lookups are cached, so give it the record's TTL before you judge.

The script also has a -q flag that prints one line, so you can run it from cron and catch the day a vendor adds a nested include and pushes you over. It's free in our server toolkit on GitLab: email/spf-lookup-count.sh. If you're setting up a new site and mailbox anyway, Pro Gineous has shared hosting at $29 for the first year with the code new-2026, valid until December 1, 2026.

Originally published on the Pro Gineous blog.

Why Your Site Loads on www but Not on the Bare Domain (and How to Fix It)

Pro Gineous — Fri, 30 Oct 2026 09:07:40 +0000

Someone types your domain without the www and gets an error page, a certificate warning or a browser that spins until it gives up. Type it with www and the site is fine. Or the exact reverse.

The cause is almost always simple: example.com and www.example.com are two separate names, and each one needs its own DNS record, its own spot on the certificate and its own line in the web server config. Miss any one of those for one name and you get a domain not working without www (or with it). Here's how to find which piece is missing, layer by layer.

Four addresses, one site

Add http and https to the two names and a visitor can reach your site four different ways. All four should end on the same URL, through a single 301 redirect at most.

Pick the one you want people to see and treat the other three as doors that redirect to it. The checks below follow the order a browser hits them: DNS, the server, the certificate, then the redirects.

Layer 1: does each name have a record?

Ask for both names directly:

dig +short example.com A
dig +short www.example.com A
dig +short example.com AAAA
dig +short www.example.com AAAA

An empty answer for one name is often the whole problem: the apex got an A record at launch and www never did, or the reverse after a move. If you want the full picture of what dig is telling you, we have a separate guide on reading dig output.

A common healthy setup is an A record on the apex and a CNAME on www pointing at it. This is real output from a domain set up that way:

$ dig www.github.com +noall +answer
www.github.com.     3210  IN  CNAME  github.com.
github.com.         20    IN  A      20.29.134.23

The CNAME on www means it follows whatever address the apex has, so you only maintain one A record. Our walkthrough on how to add a CNAME record covers the panel side.

Why the apex can't be a CNAME

The reverse doesn't work. A CNAME can't share a name with any other record, and the apex always carries SOA and NS records, plus MX and TXT for most domains. So example.com CNAME something.host.net is against the DNS rules. Most panels refuse it, and the ones that accept it can break mail and other records at the apex.

If your host gives you a hostname instead of an IP, look for a record type called ALIAS or ANAME, or a feature called CNAME flattening. Those resolve the target on the DNS server and answer with plain A and AAAA records at the apex, so it works without breaking the rules. If your DNS host has none of those, ask the host for a fixed IP to use on the apex and keep the CNAME on www.

The AAAA record nobody remembers

Sometimes the A records were updated during a move, but the old AAAA record still points at the previous server. Visitors on IPv4 get the new site. Visitors on IPv6, which today means a lot of mobile networks, may get the old server, an empty default page or a timeout. Browsers do fall back to IPv4 when IPv6 fails to connect, but if the old address still answers, there's nothing to fall back from.

If one name has an AAAA and the other doesn't, or the AAAA doesn't belong to your current server, update it or delete it. Then test it on its own:

curl -6 -sI https://example.com/

Layer 2: is the server answering for that name?

DNS can be perfect and the server can still serve the wrong thing. A web server picks the site by the hostname in the request, so if the config only lists example.com, a request for www.example.com lands on the default site. That's the classic "www shows the hosting company's welcome page" situation.

Check the first response for all four:

curl -sI http://example.com/  | grep -iE '^(HTTP|location)'
curl -sI http://www.example.com/  | grep -iE '^(HTTP|location)'
curl -sI https://example.com/ | grep -iE '^(HTTP|location)'
curl -sI https://www.example.com/ | grep -iE '^(HTTP|location)'

You want one 200 (on your canonical URL) and three 301s whose location is that same URL. A 200 on two of them means two copies of the site. In Nginx, check that both names appear in a server_name line somewhere; in Apache, look for ServerAlias.

Layer 3: does the certificate cover both names?

This one is easy to miss, because DNS and the server are fine and the browser just shows a scary warning page. A certificate lists the names it's valid for, and a request for any other name gets a browser warning, even if the next step would have redirected away.

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

Run it once with each name after -servername. Both names need to be in the list. Note that a wildcard like *.example.com covers www but not the bare example.com, so a wildcard certificate usually lists the apex as well. With Certbot, ask for both names in one certificate:

certbot --nginx -d example.com -d www.example.com

If you just renewed and still see the old name list, the server may be holding the old file in memory. Our guide to checking SSL certificate expiry shows how to spot a renewed certificate that never got loaded.

Layer 4: redirects that go in circles

A redirect loop shows up as "too many redirects" in the browser. Follow the chain and the loop prints itself:

curl -sIL --max-redirs 5 https://www.example.com/ | grep -iE '^(HTTP|location)'

The usual causes:

The server redirects www to the bare name while the app (in WordPress, the Site Address under Settings > General) redirects the bare name back to www. Make both agree.
A proxy or CDN in front talks to your server over plain HTTP, and your server redirects every HTTP request to HTTPS. The proxy asks again over HTTP, forever. Switch the proxy to full HTTPS to the origin, or redirect based on the forwarded protocol header.
Two rules, one in the server config and one in .htaccess, each "fixing" the other.

Pick one name and 301 the rest

Once DNS, certificate and server all cover both names, send everything to one place. For a bare canonical name in Nginx:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}
server {
    listen 443 ssl;
    server_name www.example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    return 301 https://example.com$request_uri;
}

The real site then lives in a third server block with listen 443 ssl and server_name example.com. On Apache or shared hosting, the same thing in .htaccess:

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [L,R=301]

Two habits save a lot of pain. Test with a 302 first and switch to 301 once it works, because browsers cache a 301 and keep following a wrong one even after you fix the server. And keep $request_uri (or %{REQUEST_URI}) in the target so deep links land on the same page instead of the home page.

Check all four in one go

Running those commands for every variant gets tedious, so we wrote a read-only script that does it. It looks up A, AAAA and CNAME for both names, requests all four variants pinned to the address DNS returned, follows the redirects, reads the certificate each name serves and tells you whether every variant ends on the same URL.

./dns/www-apex-check.sh example.com
./dns/www-apex-check.sh --doh example.com   # ask 1.1.1.1 over HTTPS instead of the local resolver

That run is against our own domain. Every variant ends on https://progineous.com/ and the certificate covers both names, but http://www takes two hops (to https www, then to the bare name). A single rule straight to the final URL would save a round trip. When something is wrong, the script ends with FAIL or WARN lines that name the problem, such as a CNAME at the apex, a certificate that only covers one name or a redirect loop, and exits with 1 or 2 so you can use it in monitoring.

The script is free in our server toolkit on GitLab: dns/www-apex-check.sh. If you're setting up a new site anyway, Pro Gineous has shared hosting at $29 for the first year with the code new-2026 (valid until December 1, 2026) and VPS plans from $6.96/mo.

Quick answers

Should you use www or the bare domain?

Either works. The bare name is shorter to type, while www makes CDNs and cookie scoping a little easier on big setups. What matters is picking one and redirecting the other three variants to it.

Domain not working without www, but DNS looks right?

Then check the certificate and the server config next. Run the openssl command above with the bare name after -servername, and make sure that name is in server_name or ServerAlias.

How long until a fixed record works everywhere?

As long as the old record's TTL, which is often an hour or less but can be a day. A missing record can also be cached as "doesn't exist" for a while, based on the zone's SOA record.

Originally published on the Pro Gineous blog.

Is a Disk Dying in Your Dedicated Server? How to Check Disk Health on Linux

Pro Gineous — Thu, 29 Oct 2026 08:34:15 +0000

A dedicated server with two disks in RAID 1 can lose one of them and keep running as if nothing happened. That's the point of RAID, and it's also the trap. The site stays up, nobody gets an alert, and months later the second disk starts throwing errors while the first one has been dead the whole time.

Disks rarely die without warning. They remap bad sectors, fail self-tests and log errors for weeks before they give up, and Linux can read all of it. Here's how to check disk health on Linux with smartctl and mdadm, what the numbers mean, and what to do when one of them looks bad.

The quick check

If you only have a minute, run these three as root:

cat /proc/mdstat
smartctl -H /dev/sda
smartctl -A /dev/sda | grep -E 'Realloc|Pending|Offline_Unc|CRC'

The first shows whether every RAID array still has all its members, the second gives the drive's own verdict, and the third shows the four counters that matter most on a SATA drive. Repeat the last two for each disk.

Find the disks and install smartmontools

SMART data comes from the drive's firmware, and smartctl from the smartmontools package reads it:

sudo apt install smartmontools
lsblk -d -o NAME,MODEL,SIZE,ROTA,TRAN

ROTA is 1 for spinning disks and 0 for SSDs, and TRAN shows whether a disk is SATA, SAS or NVMe. If you see vda or xvda instead, you're on a virtual machine. Virtual disks have no SMART data, and the physical drives are the host's job. That's one of the real differences when you compare a cloud server with a dedicated one.

One big disk on a server that should have several usually means a hardware RAID controller. smartctl can still reach the drives behind most of them, for example smartctl -a -d megaraid,0 /dev/sda for the first disk on a MegaRAID card.

Why PASSED doesn't mean healthy

smartctl -H prints SMART overall-health self-assessment test result: PASSED on most drives, including plenty that are on their way out. The verdict only flips to FAILED when a normalized attribute value drops below the threshold the manufacturer set, and those thresholds are generous. Treat FAILED as an emergency and PASSED as "keep reading".

What you want is the raw values in smartctl -A, the last column of the attribute table. On a SATA drive, four of them do most of the work:

5 Reallocated_Sector_Ct: sectors the drive gave up on and replaced from its spare pool. A handful that never changes can live for years. A number that grows every week is a drive that's failing.
197 Current_Pending_Sector: sectors the drive couldn't read and hasn't remapped yet. These are reads that already failed. On a RAID member, mdadm usually rewrites them from the other disk, and they either get remapped or clear.
198 Offline_Uncorrectable: sectors that failed during the drive's own background scan. Read it together with 197.
199 UDMA_CRC_Error_Count: errors on the cable between disk and controller, not on the platters. If this climbs, reseat or replace the cable or backplane slot before you blame the drive.

Ideally all four are zero. Write down anything above zero with the date, so you can see next week whether it moved.

NVMe drives report different numbers

smartctl -a /dev/nvme0n1 shows a short health section instead of the attribute table. Watch Critical Warning (anything other than 0x00 is bad), Available Spare against Available Spare Threshold, Percentage Used (the share of the rated write endurance already used, and it can go past 100), and Media and Data Integrity Errors, which should stay at zero.

Ask the drive to test itself

Counters only change when the drive touches a bad area. A self-test makes it look on purpose:

smartctl -t short /dev/sda      # about two minutes
smartctl -t long /dev/sda       # hours on a large disk, runs in the background
smartctl -l selftest /dev/sda

Tests run inside the drive and leave your data alone, though a long test adds read load. The newest result is # 1. You want Completed without error. A line like Completed: read failure with an LBA next to it means the drive found a sector it can't read, and that disk should go on the replacement list.

Read the RAID state

/proc/mdstat is the fastest view of software RAID:

md2 : active raid1 sdb3[1] sda3[0]
      3902418944 blocks super 1.2 [2/2] [UU]

[2/2] [UU] means two members expected, two working. A degraded array shows [2/1] [U_], and a member marked (F) has been kicked out as failed. For the full picture, including which partition is missing, run mdadm --detail /dev/md2 and check the State line. clean is good, while degraded or recovering needs attention.

One script for all of it

Checking every disk and array by hand gets old fast, so we wrote a small read-only script for it. It runs smartctl -a on each disk, pulls out the counters above, adds the last self-test and the RAID state from /proc/mdstat, and ends with a verdict and an exit code you can use from cron.

sudo ./disk/disk-health-check.sh
sudo ./disk/disk-health-check.sh -q   # one line, for cron

In that run both arrays are still [UU], so nothing looks wrong from the outside. But sdb has 8 reallocated and 16 pending sectors and failed its last short test. That's the early warning RAID hides, and the moment to check your backups (here's how to back up a server and prove the restore works) and book a disk swap.

Replacing a failing disk in mdadm RAID 1

Before anything else, confirm the backup is recent. Then note the serial number of the bad disk with smartctl -i /dev/sdb, because that's how the data center tech finds the right drive in the chassis. Pulling the healthy one by mistake takes the server down.

Mark the old disk's partitions as failed and remove them from each array:

mdadm --manage /dev/md2 --fail /dev/sdb3 --remove /dev/sdb3
mdadm --manage /dev/md1 --fail /dev/sdb2 --remove /dev/sdb2

Once the new disk is in, check its name with lsblk, since it won't always come back as sdb. Copy the partition layout from the healthy disk to the new one. Get the direction right, because this overwrites the target's partition table:

sgdisk /dev/sda -R /dev/sdb     # copy sda's GPT layout onto sdb
sgdisk -G /dev/sdb              # give the copy new unique GUIDs
mdadm --manage /dev/md1 --add /dev/sdb2
mdadm --manage /dev/md2 --add /dev/sdb3
watch cat /proc/mdstat

On an MBR disk, use sfdisk -d /dev/sda | sfdisk /dev/sdb instead of sgdisk. Install the boot loader on the new disk too (grub-install /dev/sdb on BIOS systems), or the server won't boot if the other disk dies next. On UEFI, copy the EFI partition over as well. The rebuild can take hours, and the array stays usable meanwhile.

Make the server tell you

Two daemons that ship with these packages can email you instead of waiting for you to look. In /etc/smartd.conf, this line watches every disk and schedules a short test every night and a long one on Saturdays:

DEVICESCAN -a -o on -S on -s (S/../.././02|L/../../6/03) -m root

For RAID, set MAILADDR you@example.com in /etc/mdadm/mdadm.conf and send a test alert with mdadm --monitor --scan --test --oneshot. Both need working outgoing mail on the server. If your disks are filling up rather than wearing out, that's a different problem, and our guide on what's using the space on a full disk covers it.

The script is free on GitLab: disk-health-check.sh in our server toolkit, and a daily cron line for it is in its header. If you'd rather leave physical disks to someone else entirely, Pro Gineous has VPS plans from $6.96/mo.

FAQ

How often should you check disk health on Linux servers?

Let smartd and mdadm watch all the time, and look at the counters yourself about once a week. The trend matters most, so compare with the last reading.

Is a disk with a few reallocated sectors safe to keep?

A small number that stays flat for months is common on older drives. If it rises between checks, or pending sectors show up at the same time, plan the replacement.

Can smartctl check disks on a VPS?

No. A VPS sees virtual disks without SMART data, and the provider watches the physical drives.

Originally published on the Pro Gineous blog.

Moving Hosts? Test Every Page on the New Server Before You Change DNS

Pro Gineous — Wed, 28 Oct 2026 08:03:02 +0000

The scary part of moving a site to a new host isn't copying the files. It's the moment you change the DNS record and hope. If something on the new server is broken, visitors find it before you do, and rolling back takes as long as the TTL says it does.

You don't have to guess. Your own computer can talk to the new server under the real domain name while everyone else still sees the old one, so you can check pages, certificate, forms and redirects first and switch only when both copies match.

Lower the TTL a day or two early

The TTL on your A record decides how long resolvers keep the old answer after you change it. Check it first:

dig +noall +answer example.com A
dig +noall +answer example.com A @ns1.your-dns-host.com```
{% endraw %}
The first asks your normal resolver, where the TTL counts down as the cached copy ages. The second asks the authoritative server and shows the full value. If it says 86400 (one day) or 14400, lower it to 300 in your DNS panel, then wait at least the old TTL before you plan the switch. Resolvers that cached the record yesterday will hold it for the full old value, no matter what you set today. If you're unsure which line of {% raw %}`dig` output is which, we wrote a guide on [how to read dig output](https://blog.progineous.com/read-dig-output-dns/), and the reasons changes sometimes seem stuck are in [how long DNS changes take](https://blog.progineous.com/how-long-dns-changes-take/).

![Diagram of a host move in four steps: lower the A record TTL to 300 a day or two before, test the new server with site-compare.sh while only you can see it, change the A record on switch day and retire the old server a few days later, with two bars showing when the old and the new server serve visitors](https://blog.progineous.com/wp-content/uploads/2026/10/test-website-before-changing-dns-timeline.png)

## Test website before changing DNS, page by page

With the files and database copied over (the full order of steps is in our [step by step migration guide](https://blog.progineous.com/how-to-migrate-a-website/)), point your own machine at the new server. There are two ways, and you'll probably use both.

### One request at a time with curl --resolve

{% raw %}`curl --resolve`{% endraw %} tells curl which IP to use for a name, for that one command only. The URL, the SNI name and the Host header all stay the same, so you're testing the real virtual host:



```bash
curl -sI --resolve example.com:443:203.0.113.20 https://example.com/
curl -sI --resolve example.com:443:203.0.113.10 https://example.com/

Run it against the old IP and the new IP and compare the status line, the location header on redirects, and headers your app sets.

Clicking around with the hosts file

For a real browser session, add a line to your hosts file (/etc/hosts on Linux and macOS, C:\Windows\System32\drivers\etc\hosts on Windows):

203.0.113.20  example.com www.example.com

Now your browser loads the new server. Log in to the admin area (on WordPress that's /wp-login.php), open a few posts, run a search, try the cart. Put a test HTML comment on the new copy so you always know which server you're looking at, and remove the hosts line when you're done.

Check the certificate on the new IP

A page can load fine over HTTP and still fail for visitors because the new server has no valid certificate for your name yet. Ask the new IP for its certificate with the right server name:

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

Look for your domain in the subject and an expiry date well ahead. Without -servername many servers return a default certificate, which tells you nothing. One catch with Let's Encrypt: the usual HTTP challenge can't pass on the new server while DNS still points at the old one. You can copy the existing certificate across, use a DNS challenge, or plan to issue it right after the switch. Our post on checking certificate expiry from the command line covers reading that output.

Compare every URL, not just the home page

The home page is rarely what breaks. It's the old link that used to redirect, a contact page that throws an error, a category page that comes back half empty. To catch those, take every URL from the sitemap and request each one from both servers:

curl -s https://example.com/sitemap.xml | grep -o '<loc>[^<]*' | sed 's/<loc>//' > urls.txt
while read -r u; do
  o=$(curl -s -o /dev/null -w '%{http_code}' --resolve example.com:443:203.0.113.10 "$u")
  n=$(curl -s -o /dev/null -w '%{http_code}' --resolve example.com:443:203.0.113.20 "$u")
  [ "$o" = "$n" ] || echo "$o $n $u"
done < urls.txt

On WordPress the sitemap at /sitemap.xml is often an index that lists smaller sitemaps, so you may need to repeat the first step for each of those. Status codes alone miss pages that return 200 with the wrong content, so compare the title and response size too.

That's exactly what our site-compare script does. Give it the new IP, optionally the old one (otherwise it uses whatever public DNS returns), and a list of URLs as arguments, from a file with -f, or from a sitemap with --sitemap:

./site-compare.sh --old 203.0.113.10 --new 203.0.113.20 \
  --sitemap https://example.com/sitemap.xml https://example.com/wp-login.php

It reads the sitemap from the old side and follows a sitemap index one level down. For each URL it sends the same GET request to both servers with curl --resolve, does not follow redirects, and lines up status code, redirect target, page title and response size. Size differences above 15 percent get flagged (change that with -t). It checks the certificate once per host on each side first, and if one fails to verify it skips those pages unless you pass -k. The exit code is 0 when everything matches, 1 when it finds differences and 2 on errors, so it fits in a script too.

In that run the redirect from /old-pricing/ is gone on the new server, which usually means rewrite rules didn't come along (common when moving from Apache to nginx, which ignores .htaccess). The contact page returns 500, and the pricing page is 43 percent smaller, which on a real site points to a missing plugin, PHP extension or include. Each of those would have reached visitors on switch day.

The parts a page check won't see

Some things only show up when you test them on purpose:

Forms and outgoing email. Submit every form on the new server and confirm the message arrives. If the site sends mail itself, the new IP may need to be in your SPF record, or the mail goes to spam.
Cron jobs. Run crontab -l on the old server and recreate the jobs. On WordPress, check that WP-Cron or the system cron replacing it is running.
Hardcoded addresses. Search config files and the database for the old IP or paths.
Other DNS records. If you only change the A record, mail (MX) and other records stay put. If you move name servers too, recreate every record first and compare them with dig.
WordPress specifics. PHP version, file permissions on uploads, and caching plugins that stored the old server path are the usual suspects. Our guide on moving a WordPress site safely goes through them.

Switch, then keep the old server running

When the comparison comes back clean, change the A record (and www if it's a separate record). With a 300 second TTL most visitors move within minutes. Check from the outside with dig +short example.com against a couple of public resolvers, watch the access log on the new server fill up, and load the site with a plain curl -s https://example.com/ | grep for the test comment you left, so you know public DNS now lands on the new copy.

Keep the old server online for a few days. Some resolvers hold records longer than they should, and if something goes wrong, pointing the record back is a one line change. Once traffic on the old server drops to nothing, put the TTL back to a normal value like 3600 and shut the old server down.

The script is free and read only, it sends GET requests and changes nothing. You can grab site-compare.sh from our server toolkit on GitLab. And if you're still deciding where the site should live next, Pro Gineous has VPS plans from $6.96/mo.

FAQ

Can you test a site on a new server without editing the hosts file?

Yes. curl --resolve example.com:443:NEW_IP https://example.com/ sends one request to the new server under the real name. You only need the hosts file to click through the site in a browser.

How far ahead should you lower the TTL?

At least as long as the current TTL. If the record has a TTL of 86400, lower it to 300 a full day before the switch, so every cached copy has expired by the time you change the IP.

Why does the new server show the wrong certificate?

Usually it has no certificate for your name yet, or you connected without the server name. Test with openssl s_client -servername example.com. With Let's Encrypt, copy the current certificate or use a DNS challenge, since the HTTP challenge can't pass before the switch.

Originally published on the Pro Gineous blog.

Is Your Cloud Server Slow Because of CPU Steal? How to Check

Pro Gineous — Tue, 27 Oct 2026 08:04:26 +0000

Your cloud server feels slower than it did last month. Pages take longer, a cron job that used to finish in two minutes now needs five, and yet nothing changed in your code. Before you start tuning PHP or buying a bigger plan, check one number that a lot of people never look at: CPU steal time.

On a cloud server or VPS, your vCPUs are threads on a physical host that you share with other machines. Steal is the time your vCPU was ready to run but had to wait because the hypervisor gave the physical core to someone else. Your server can't use that time, and nothing inside it can get it back. The good news is that Linux counts it, so you can see it with tools that are already installed.

Where to see CPU steal time

Run top and look at the %Cpu(s) line. The last field, st, is steal. vmstat shows the same thing in its st column, and it's easier to watch over a few seconds:

top -bn1 | head -n 5
vmstat 2 5

Ignore the first vmstat line. It's an average since boot, not a current reading. The lines after it are 2-second samples, and in that output steal sits between 7 and 11 percent while the server is busy. Put differently, for roughly every ten seconds of CPU the server wanted, close to one went to another tenant.

If you want it per vCPU, mpstat from the sysstat package splits it out:

sudo apt install sysstat
mpstat -P ALL 2 5

The %steal column there is the same counter. All of these tools read it from the eighth number on the cpu line of /proc/stat, so they agree with each other, give or take when each one takes its sample.

When the number means something

CPU steal time only appears when your server asks for CPU. A machine that sits at 95% idle can show zero steal on a host that is completely overloaded, simply because it never asks for more than a sliver. So a quick look at 3 a.m. tells you very little. Measure while the site is busy, during a deploy, or while a heavy job runs.

As a rough guide, this is how we read it during busy periods:

Under 5%: normal on shared virtual hardware. Leave it alone.
5 to 15%: worth watching. Collect data at different hours before drawing conclusions.
Above 15% for long stretches: you'll feel it in response times, and it's worth raising with your provider.

One detail that confuses people: high steal also pushes up the load average. Your processes are still runnable while they wait for the host, so they count toward load even though the server isn't doing more work. A load of 3 on a 2 vCPU server with 12% steal is a different problem from a load of 3 with zero steal.

Also check what kind of virtualization you're on with systemd-detect-virt. On KVM and Xen the steal counter is filled in. Inside an LXC or OpenVZ container it often stays at zero no matter what the host is doing, so a zero there doesn't prove much.

Reading the pattern

A single reading tells you steal exists. The shape over a day tells you why.

Steal follows your own load. It climbs when your app gets busy and stays high after a long burst. That usually points to a CPU limit on the plan, or to a burstable plan that runs on CPU credits. When the credits run out, the throttling often shows up as steal. Check your plan's CPU terms and the credit balance in the provider panel, if there is one.

Steal rises at the same hours whatever you do. Your traffic is flat, but steal jumps every evening or every night at 2 a.m. That's the physical host being busy with other tenants. It's not something you can fix from inside the server.

Steal stays near zero, but the server is slow. Then the slowness is yours. Look at wa (waiting on disk), memory and swap, or the app itself. The disk full guide and the RAM sizing guide are good places to continue.

Keep a record with sar

The second pattern is hard to prove with one screenshot. sar, also from sysstat, saves CPU stats every ten minutes so you can look back. On Debian and Ubuntu the collection is off by default:

sudo sed -i 's/^ENABLED="false"/ENABLED="true"/' /etc/default/sysstat
sudo systemctl enable --now sysstat

After a day or two you can pull the history:

sar -u                              # today, one line per 10 minutes
sar -u -f /var/log/sysstat/sa24     # the 24th of this month

The %steal column, lined up against %user, shows which of the patterns you're dealing with. On RHEL-based systems the files live in /var/log/sa/ instead.

It also helps to have a simple benchmark you can repeat. Run the same fixed workload at a quiet hour and at a busy one and compare:

openssl speed -seconds 10 sha256     # about a minute, six block sizes

The numbers depend on the CPU model, so don't compare them across providers. Compare them on the same server over time. If the throughput drops at the same hours that sar shows steal going up, you have your answer in two places.

Doing it in one command

We put the sampling into a small script. It reads /proc/stat at a fixed interval, prints user, system, iowait, steal and idle for each sample, and ends with the average and peak steal plus the share since boot. Because steal only shows under load, --busy keeps every vCPU at 100% for the length of the sample. It asks before it starts and stops the load when it's done:

./performance/cpu-steal-check.sh --busy -n 10

With -q it prints a single line and returns a non-zero exit code on a warning, so it fits in cron and builds up a log you can send to support. You can get cpu-steal-check.sh from our server toolkit on GitLab; it's read-only apart from that optional load.

What to do about it

Once you have the data, the options are fairly short:

Send it to your provider. Times, sar output and the script log are far more useful than "the server feels slow". They can often move the VM to a quieter host.
Check the plan type. If steal follows your own load, you may be on a shared or burstable CPU plan that is doing exactly what it was sold to do. A plan with dedicated vCPUs, or a step up in size, fixes that. The guide to scaling a cloud server covers how to do it one step at a time.
Smooth out your own peaks. Move heavy cron jobs, backups and image processing away from your busiest hours, so you ask for less CPU at the moments it's hardest to get.
Consider dedicated hardware. If steal keeps coming back after a move and the workload is steady and heavy, a dedicated server takes the neighbors out of the picture entirely. The cloud vs dedicated comparison goes through the trade-offs.

If you're testing a new home for a workload anyway, the same checks work on a fresh Pro Gineous VPS: run the script under load at a few different hours before you move anything.

CPU steal time is one of the few performance problems you can't tune away from inside the server. What you can do is measure it properly, keep the numbers, and make the decision with data instead of a hunch.

How to Prepare a Domain Transfer So DNS and Email Keep Working

Pro Gineous — Sun, 25 Oct 2026 08:04:02 +0000

Moving a domain to a new registrar should be one of the dullest jobs in IT. You switch off the lock, copy a code, pay, and a few days later the renewal invoice comes from somewhere else. The website, the mailboxes and the DNS records don't have to notice anything.

When a transfer does go wrong, it is rarely the transfer itself. It's a lock nobody knew about, an approval email sent to an address that died years ago, or a nameserver change made in the same afternoon on a domain with DNSSEC. Those are all things you can see from a terminal before you start. So this is how we prepare a domain transfer, in the order it happens: two weeks before, the week before, on the day, during the wait, and after the name lands.

What actually moves

A registrar transfer changes one field at the registry: which registrar manages the name. Your nameservers, and therefore every DNS record, stay exactly as they are unless someone changes them. That's the whole reason a careful transfer causes no downtime.

So the plan is simple. Move the registration first. Leave DNS where it is. If you also want to move DNS hosting, do it as a separate change after the transfer is done.

Two weeks before: read the registry record

Start with what the registry says about the name. RDAP gives you that as JSON, no account needed:

curl -s https://rdap.verisign.com/com/v1/domain/example.com \
  | jq '{status, events: ([.events[] | {(.eventAction): .eventDate}] | add),
         dnssec: .secureDNS.delegationSigned}'
dig +short NS example.com
dig +noall +answer DS example.com

That RDAP server is the one for .com and .net. For other endings, the RDAP lookup guide shows how to find the right server from the IANA bootstrap file.

Three things to read in that output:

Status. client transfer prohibited is the normal registrar lock. You turn it off yourself in the registrar panel, and under ICANN's Transfer Policy the registrar has to remove it within five calendar days if it doesn't offer a switch. server transfer prohibited, any kind of hold, redemption period or pending delete are different. Those need a conversation with the current registrar before anything else.

Dates. If the name was registered or transferred in the last 60 days, the current registrar is allowed to refuse the transfer. Some registries also publish a transfer event, which tells you when the last move happened.

Expiry. Leave yourself a margin. If the name expires before the transfer goes through, the request can fail and you end up renewing under pressure anyway. When expiry is close, renew at the current registrar first. For gTLDs a completed transfer still adds a year on top, within the 10-year cap.

The 60-day rules, and what ICANN has changed

Today's rules come from the Transfer Policy updated in February 2024, which registrars had to apply by August 21, 2025. Two 60-day windows matter:

After registration or after a registrar transfer, the registrar may deny a new transfer for 60 days.
After a change of registrant, the registrar must apply a 60-day transfer lock, unless you opted out before the change. A change of registrant means a real change to the registrant name, organization or email address, not a typo fix.

That second one catches people. Fixing an old registrant email the week before a transfer can count as a change of registrant and lock the name for two months. If the email needs fixing, look for the opt-out first.

On June 7, 2026 the ICANN Board adopted the Transfer Policy Review recommendations. When they take effect, the lock after registration and after a transfer becomes a fixed 30 days, the auth code becomes a one-time Transfer Authorization Code (TAC) valid for 14 days, and the 60-day change-of-registrant lock goes away. As of today, ICANN has not published an effective date, so the current 60-day rules still apply. Country-code endings like .uk or .de follow their own registry's rules either way.

One week before: snapshot DNS and look at DNSSEC

Take a snapshot you can rebuild from

Even if you never plan to touch DNS, save what's published now. If a checkout page "helpfully" resets the nameservers, or you later move DNS hosting, this file is how you put everything back:

d=example.com
for t in SOA NS A AAAA MX TXT CAA; do dig +noall +answer "$d" "$t"; done > "$d-dns.txt"
for n in www mail autodiscover _dmarc; do
  for t in A AAAA CNAME MX TXT; do dig +noall +answer "$n.$d" "$t"; done
done >> "$d-dns.txt"

It asks for each type separately because many DNS providers answer ANY with almost nothing. DKIM keys sit under selector names you have to know, such as google._domainkey or selector1._domainkey, and they're easy to forget. If any of the output looks odd, the dig output guide walks through each section.

DNSSEC is where the outages come from

If the DS query returned a record, the domain is signed. The DS record at the registry is a fingerprint of the key your current DNS provider signs with. Validating resolvers check every answer against it.

As long as the nameservers stay the same, the transfer doesn't affect this at all. The trouble starts when the nameservers move to a provider that signs with different keys, or doesn't sign. The old DS no longer matches, and resolvers that validate DNSSEC return SERVFAIL. For those users the website and email simply disappear.

So the rule is: keep the nameservers through the transfer. If you're also moving DNS, do it afterwards in this order:

Remove the DS record at the registrar.
Wait at least the DS TTL (86400 seconds, one day, in the output above) so caches forget it.
Switch the nameservers.
Turn on DNSSEC at the new provider and add its new DS record at the registrar.

There are key rollover methods that keep the zone signed the whole time, but they need both DNS providers to cooperate. For most sites, a day or two unsigned is the simpler and safer trade.

Transfer day: lock off, code, approval email

Turn off the registrar lock, then request the auth code (some registrars call it the EPP code). Most registrars show it straight away, and one that has no self-service option has to send it within five calendar days. Treat it like a password: paste it into the new registrar's order and nowhere else.

Before you submit, check which email address the approval message will go to. Public RDAP usually redacts the registrant contact, so don't rely on it here. Look in the current registrar's account instead. If that inbox is on the same domain, make sure the mail is still working there.

At checkout, read the nameserver options. Some registrars offer to switch the name to their own nameservers. Say no for now.

The five days in between

Once the new registrar sends the request, the registry marks the name pending transfer. The current registrar sends a confirmation message within 24 hours. If it doesn't reject the request within five calendar days, the registry completes the transfer. Many registrars let you approve that message to finish early.

During this window, DNS keeps resolving as normal. Don't edit records, contacts or nameservers while the transfer is pending.

After it lands

Run the same RDAP and dig commands again and compare:

The registrar field shows the new registrar, and the new registrar's lock is on.
NS and DS match your snapshot exactly.
The expiry date moved forward a year.

Then send a test email to and from the domain. If you publish DMARC, the next few aggregate reports will confirm that SPF and DKIM still pass. Only after all of that, if moving DNS is part of the plan, start the DNSSEC steps above.

Doing it in one command

We wrapped all of these checks into a read-only script. It reads the RDAP status and dates, flags locks and holds, reports DS records, and writes a DNS snapshot including the DKIM selectors you pass in:

./domains/transfer-readiness.sh example.com --dkim google,selector1

It changes nothing at the registrar or in DNS, so it's safe to run before and after the move. You can grab transfer-readiness.sh from our server toolkit on GitLab along with the other domain scripts.

The same checks apply whichever registrar the name is heading to, Pro Gineous included. Ten minutes with them up front is a lot cheaper than a week of untangling afterwards.

How to Check SSL Certificate Expiry Before Browsers Start Warning

Pro Gineous — Fri, 23 Oct 2026 08:09:06 +0000

Most sites have had auto-renewing certificates for years, so an expired one feels like a thing of the past. Then a renewal fails quietly in August, nobody looks, and in October visitors get a full-page "Your connection is not private" warning while the checkout page loses every sale.

The renewal tool usually isn't the whole story. The certificate on disk can be fresh while the web server is still handing out the old one from memory. A firewall change can block the challenge. A new AAAA record can send the certificate authority to a server that no longer exists. None of that shows up until a browser complains.

So the habit worth building is simple: check SSL certificate expiry on what the server actually sends, not on what you think it has. Here is how we do it from a terminal, what the output means, and how to tell which part of the renewal broke.

Why "auto-renew is on" isn't enough anymore

Two changes make this more pressing than it used to be.

Certificates are getting shorter. Under the CA/Browser Forum rules, a public TLS certificate issued since March 15, 2026 can be valid for at most 200 days. That drops to 100 days in March 2027 and 47 days in March 2029. Let's Encrypt still issues 90-day certificates by default, moving to 64 days in February 2027 and 45 days in February 2028. Shorter lifetimes mean more renewals, and more chances for one to fail.

The reminder emails are gone too. Let's Encrypt stopped sending expiry notification emails on June 4, 2025. If you were relying on that "your certificate expires in 20 days" message as a safety net, it no longer exists. You need your own check.

The one command worth memorizing

Everything below builds on one small shell function. Put it in your ~/.bashrc:

cert() { echo | openssl s_client -connect "${2:-$1}:443" -servername "$1" 2>/dev/null; }

cert example.com opens a TLS connection and prints the certificate the server presents. The optional second argument lets you aim at a specific IP while still asking for the right name, which is handy before a migration or when you want to skip a CDN: cert example.com 203.0.113.10.

The -servername part matters. One IP often hosts many sites, and the server picks the certificate by the name the client sends (SNI). Recent OpenSSL sends the name by default when you connect to a hostname, but not when you connect to an IP, and older builds don't send it at all. Without it you may be looking at the server's default certificate and wondering why the dates are wrong.

Pipe the result into openssl x509 to read it:

cert example.com | openssl x509 -noout -subject -issuer -dates
cert example.com | openssl x509 -noout -ext subjectAltName
cert example.com | openssl x509 -noout -checkend $((21*86400))

notAfter is the line you care about, and it is always in GMT. -checkend takes seconds and answers one question: will this certificate still be valid that far from now? It prints "Certificate will not expire" and exits 0, or "Certificate will expire" and exits 1, which makes it easy to use in a script. If you prefer a number:

end=$(cert example.com | openssl x509 -noout -enddate | cut -d= -f2)
echo $(( ($(date -d "$end" +%s) - $(date +%s)) / 86400 )) days left

Reading the rest of the certificate

Dates are only one way a certificate can fail. Two more lines in that output are worth a glance every time.

The Subject Alternative Name list is what browsers match against. The old CN field is ignored for that. If www.example.com isn't in the list, anyone who types the www version gets a name error even though the certificate is valid.

The verify result tells you whether the chain is complete:

cert example.com | grep 'Verify return code'

You want 0 (ok). A result like 20 (unable to get local issuer certificate) usually means the server sends only the site certificate without the intermediate. Desktop browsers often paper over that, but curl, payment webhooks and older phones won't. With Let's Encrypt the fix is pointing the server at fullchain.pem instead of cert.pem.

Renewed, but the old one is still being served

This is the failure we see most on self-managed servers. Certbot renews on schedule and writes new files under /etc/letsencrypt/live/, but nginx, Apache, Postfix or a Node app read the certificate once at startup and keep it in memory. Until something reloads them, visitors get the old one.

The certbot nginx and Apache plugins reload the server for you. Certificates issued with certonly, --webroot or --standalone don't, and neither does anything outside the web server, like a mail server using the same certificate.

Comparing the file with the live connection makes it obvious:

The fix for today is a reload. The fix for next time is a deploy hook, which certbot runs only after a successful renewal:

sudo tee /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh >/dev/null <<'HOOK'
#!/bin/sh
systemctl reload nginx
HOOK
sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-nginx.sh

Add a line for every service that uses the certificate, such as systemctl reload postfix dovecot.

When the renewal itself is failing

If the file on disk is old too, the problem is earlier in the chain. Renewal is a short pipeline, and each stage has its own typical way of breaking:

Start with these four commands:

systemctl list-timers | grep -i certbot
sudo certbot certificates
sudo certbot renew --dry-run
sudo tail -n 50 /var/log/letsencrypt/letsencrypt.log

The first confirms the timer exists and ran recently (it's certbot.timer from the Debian and Ubuntu packages, snap.certbot.renew.timer from the snap). certbot certificates lists every certificate it manages with its expiry date, and --dry-run repeats the whole renewal against the staging servers without touching your real certificate.

The dry run's error message is usually clear. The causes we run into most:

Port 80 is closed. The HTTP challenge needs it, even if the site itself redirects everything to HTTPS. A firewall tightened after setup is the usual reason. If you followed our VPS security checklist, make sure ufw allow 80/tcp is still there.
DNS points somewhere else. The certificate authority connects to whatever A and AAAA records say. A stale AAAA record pointing at an old server is a classic, because your own machine may never use IPv6 and you never notice. Our guide to reading dig output walks through checking both record types.
The webroot moved. After a site restructure, --webroot -w can point at a folder the web server no longer serves.
The disk is full. Certbot can't write the new files, and the log says so plainly.

Quick reference: what you see and where to look

What you see	Likely cause	Check with
Browser says the date is invalid	Renewal failed, or it worked and nothing reloaded	`-dates` on the live connection and on the file
Name mismatch error, often only on www	Name missing from the certificate, or the wrong site answered	`-ext subjectAltName`, and test with `-servername`
Browser fine, curl or an API client fails	Intermediate certificate not sent	`Verify return code`
Correct on one network, old on another	An old IP still answers through an AAAA or A record	`cert name ip` against each address

Put it on a schedule

A check you run by hand is a check you forget. We wrapped everything above into one read-only script, ssl-expiry-check.sh, in our server toolkit on GitLab. It takes a list of hosts and reports days left, issuer, name match and chain status for each, and with --live-dir /etc/letsencrypt/live it also flags a served certificate that differs from the one on disk. It exits non-zero when something needs attention, so a daily cron entry with chronic only emails you on problems:

30 7 * * *  chronic /usr/local/bin/ssl-expiry-check.sh -f /etc/ssl-hosts.txt --live-dir /etc/letsencrypt/live

Set the warning at three weeks. With 90-day certificates renewing at 30 days left, a warning at 21 days means one renewal attempt has already been missed and you still have time to fix it calmly.

The same idea applies to the domain itself, which can expire just as quietly as the certificate. Whether your sites live on shared hosting or on a Pro Gineous VPS, a five-minute check like this beats finding out from a customer.

Originally published on the Pro Gineous blog.

How to Check Whether Your Server Is Patched Against PHP2Shell

Pro Gineous — Fri, 23 Oct 2026 02:27:07 +0000

Two PHP vulnerabilities, nicknamed PHP2Shell, were disclosed on October 21, 2026. They are tracked as CVE-2026-109618 and CVE-2026-109619, and both carry a CVSS v4.0 score of 9.2. If your site or app runs on PHP, there is one practical question to answer today: is the PHP on your server actually patched?

The answer is not always as obvious as reading a version number. This guide covers what was fixed, how to check your own setup in two commands, and what to do if the answer is no.

What PHP2Shell is and which versions are fixed

PHP2Shell is the name used for a pair of flaws in PHP itself, not in WordPress, a theme or a plugin. Public write-ups, including Cloudflare's, describe them as memory handling bugs that can allow remote code execution, among other impacts. Because the problem sits in the language runtime, updating your CMS does not fix it. Only a patched PHP does.

The PHP project released fixes in these versions:

PHP 8.5.12
PHP 8.4.27
PHP 8.3.36
PHP 8.2.35

PHP 8.1 and older are end of life and get no fix from the PHP project. If you are still on one of those branches, the real answer is to move to a supported version, not to wait for a patch that is not coming.

What we know about exploitation

Reports differ a little, so here is the careful version. AWS, watchTowr, SecurityWeek and Sophos reported exploitation attempts in the wild. CISA said on October 21 that it had not observed exploitation. Both statements can be true at the same time, since attempts and confirmed successful attacks are not the same thing. Either way, a critical flaw with public details is worth closing quickly rather than debating.

Why the version number can mislead you

Most people run php -v, see something like 8.3.x, and either panic or relax. Neither reaction is reliable. Linux distributions often backport a security fix into an older package and keep the same version number. A server can therefore be patched while still reporting a version that looks old, or look current while running a build from before the fix.

That is why the build date matters. A patched build should show a build date of October 21, 2026 or later.

How to check your PHP version and build date

Connect to your server over SSH and run these two commands:

php -v
php -i | grep -i "build date"

The first prints your PHP version. The second prints the build date. You can also create a temporary page that calls phpinfo() and read the same field in your browser, then delete the page right away so it does not stay public.

One catch: php -v reports the command line PHP. Your website may be served by a different binary, such as PHP-FPM or an Apache module, and some servers have several PHP versions installed side by side. If the CLI looks fine, check phpinfo() through the web server too, so you are looking at the PHP that actually handles your visitors.

If you use shared or managed hosting

You usually cannot update PHP yourself on these plans, and you do not need to. Your host manages the runtime. The right move is to check with your host, read their status page or announcement, and use the build date check above if they give you a way to view PHP info.

Several providers have published their own notices about PHP2Shell. We list them here as references so you can see what a host announcement looks like:

A WAF rule is a useful extra layer, but it is not a replacement for a patched PHP. Keep it enabled while you update, not instead of updating.

If you run your own VPS or server

On a self-managed server, nobody will patch PHP for you. The steps below are typical Debian and Ubuntu commands. Adjust them for your distribution and your setup.

sudo apt update && sudo apt upgrade

Then restart the PHP service so the new binaries are actually loaded. Replace 8.4 with the version you run:

sudo systemctl restart php8.4-fpm
sudo systemctl restart apache2

Use the PHP-FPM line if your web server talks to PHP-FPM, and the Apache line if you run PHP as an Apache module. If you use nginx with PHP-FPM, restarting PHP-FPM is the part that matters.

A few honest caveats. If your server uses a third party repository for PHP, such as Ondrej Sury's packages (the PPA on Ubuntu or packages.sury.org), the exact fixed versions may only arrive through that repository. Backported builds may keep the old version number, which is again why the build date is the check to trust. If you are on PHP 8.1 or older, plan an upgrade to a supported branch and test your application on it first.

A short checklist

Run php -v and note your version and whether it is on a supported branch.
Run php -i | grep -i "build date" and look for October 21, 2026 or later.
Update your packages, or ask your host to confirm they have done it.
Restart PHP-FPM or Apache so the update takes effect.
Check again, including phpinfo() for the PHP your website really uses.

How to confirm it worked

After the update and the restart, repeat the checks. You want to see the build date of October 21, 2026 or later, and a version that matches or exceeds the fixed releases for your branch where the package carries the upstream number. If the build date is still old, the update did not reach that binary. Look for a second PHP installation, a missing repository, or a service that was not restarted.

We have already updated PHP on our servers at Pro Gineous. If you run a self-managed VPS (plans start from $6.96/mo), PHP on that machine is yours to update, so the steps above apply to you.

Whatever your setup, the whole check takes a couple of minutes. Run the two commands, read the build date, and you will know where you stand.

Disk Full on a Linux VPS? How to Find What Is Using the Space

Pro Gineous — Thu, 22 Oct 2026 08:08:16 +0000

A full disk rarely announces itself. MySQL stops accepting writes, WordPress can't upload an image, apt fails halfway through an upgrade, or you get "No space left on device" from a command that worked yesterday. On a 20 or 30 GB VPS, one chatty log or a forgotten backup folder is enough.

The fix is almost never "delete random big things until it works". It's a short triage: confirm what kind of full you are, find where the space went, clear the parts that are safe to clear, and leave the rest alone. Below is the order we work through, with the commands and real output from a test server in the same state.

Step 0: buy a little room first

At 100%, some tools won't even start because they can't write a temp file. Two commands are safe on almost any Debian or Ubuntu server and usually free a few hundred megabytes:

sudo apt-get clean
sudo journalctl --vacuum-size=200M

The first removes downloaded .deb files, which apt can fetch again. The second trims old journal files down to 200 MB. Neither touches your site, database or config.

Step 1: is it space or inodes?

df -h /
df -i /

df -h shows blocks, which is what people usually mean by disk space. df -i shows inodes, one per file. A disk can run out of inodes while plenty of gigabytes are free, usually because something writes millions of tiny files: PHP sessions, a cache plugin, a stuck mail queue. If IUse% is the one near 100%, look for directories with huge file counts (du --inodes -x / | sort -n | tail) instead of big files.

Also notice that Size minus Used doesn't equal Avail. On ext4, 5% of the filesystem is reserved for root by default, so the system can still log in and write a few things after normal users hit zero. On the test server below that's about 1.5 GB of a 30 GB disk. You can lower it with tune2fs -m, but on a root filesystem that margin is what keeps a full server reachable.

Step 2: walk down from / with du

sudo du -xh --max-depth=1 / | sort -h

The -x flag keeps du on the root filesystem, so it skips /proc and other mounts. sort -h understands the K, M and G suffixes, so the biggest directory lands at the bottom. Then repeat one level deeper on whatever is biggest, usually /var or /home.

If ncdu is installed (apt install ncdu), sudo ncdu -x / does the same walk interactively with the arrow keys. Plain du works everywhere, though.

Step 3: look for single big files

Directories tell you where. A file search tells you what:

sudo find / -xdev -type f -size +500M -exec ls -lh {} +

On our test server that turned up the usual crowd: a 1.5 GB database dump in /root from before an upgrade, an old site zip, nine weekly backup archives at 1.2 GB each, a 940 MB nginx access log, and a 3.6 GB file deep inside /var/lib/docker/containers. That last one gets its own section below.

Step 4: check the usual suspects

The systemd journal. By default journald may use up to 10% of the filesystem, capped at 4 GB. Check it, trim it, then set a permanent limit with SystemMaxUse=500M in /etc/systemd/journald.conf and systemctl restart systemd-journald.

$ journalctl --disk-usage
Archived and active journals take up 1.3G in the file system.

Package cache and old kernels. du -sh /var/cache/apt/archives showed 205M here. apt-get clean handles that. On Ubuntu, old kernels add a few hundred megabytes each in /boot and /usr/lib/modules. sudo apt autoremove --purge removes the ones no longer needed and keeps the running one. Read the list before you type yes.

Docker. Start with docker system df:

TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          10        7         5.285GB   1.922GB (36%)
Containers      7         5         1.099kB   0B (0%)
Local Volumes   4         4         243.5MB   0B (0%)
Build Cache     0         0         0B        0B

Two things this table doesn't tell you. Old stopped containers keep their images "active", so check docker ps -a and remove the ones you really don't need before docker image prune -a. And container logs aren't counted at all. That 3.6 GB file was the JSON log of one busy worker container. Cap logs for new containers in /etc/docker/daemon.json:

{ "log-driver": "json-file", "log-opts": { "max-size": "50m", "max-file": "3" } }

Existing containers keep their old settings until you recreate them. And be careful with docker volume prune. Volumes are where your database lives.

Logs that never rotate. An access.log.1 the size of the current log means rotation runs but compression doesn't, or the app writes somewhere logrotate doesn't know about. sudo logrotate -d /etc/logrotate.conf does a dry run and shows what it would do for each file without changing anything.

Step 5: when df and du disagree

Look back at the first screenshot. du counts 27G, while df says 28G is used. When the gap is bigger than rounding, look for a file that was deleted while a process still had it open. The name is gone, but the blocks stay allocated until the process closes the file. The classic way to get there is rm on a big log an app is still writing to.

sudo lsof -nP +L1

+L1 lists open files with a link count below one, meaning deleted. Without lsof, ls -l /proc/*/fd 2>/dev/null | grep deleted finds the same thing.

Restarting the service that holds the file releases the space. If you can't restart it right now, empty the file through its descriptor, as in the screenshot. Next time, empty a live log with truncate -s 0 file instead of deleting it.

What not to delete

A few things look like junk and aren't:

Anything under /var/lib/mysql or /var/lib/postgresql. Binary logs and WAL files get big, but you clear them from inside the database (PURGE BINARY LOGS in MySQL, fixing a stuck replication slot in PostgreSQL), never with rm.
/var/lib/docker by hand. Use the docker commands. Deleting overlay2 folders directly breaks images and containers in ways that are painful to fix.
Files in /boot. Remove kernels with apt so the bootloader config is updated too.
Your only copy of a backup. Those weekly archives belong on another machine anyway. Copy them off the server first, check that the copy opens, then delete the old ones. Our guide on backing up a VPS and testing the restore covers where to send them.

Keep it from happening again

Once there's room, put the limits in place: SystemMaxUse for the journal, log-opts for Docker, and a logrotate entry for every app that writes its own log. Add a disk check to whatever monitoring you already run, alerting at 80% rather than 95%. If you set up the server with our 15-minute VPS security checklist, unattended-upgrades is already installing new kernels, so run apt autoremove --purge now and then.

We put the read-only checks from this article into one script, disk-usage-report.sh, in our server toolkit on GitLab. It prints suggested cleanup commands and deletes nothing.

And if the disk keeps filling because the site has simply grown, a bigger disk is cheaper than cleaning up every week. Pro Gineous VPS plans start at $6.96/mo.

Using RDAP to Check a Domain's Expiry Date and Lock Status

Pro Gineous — Wed, 21 Oct 2026 08:11:31 +0000

Every domain has a record at its registry that says when it expires, which locks are on it, which registrar controls it and which nameservers it hands visitors to. For years you read that record with whois, and every registry formatted the answer a little differently. That job now belongs to RDAP, the Registration Data Access Protocol. Since January 28, 2025, ICANN treats RDAP as the definitive source of registration data for generic TLDs, and most gTLD registries and registrars no longer have to run WHOIS at all (.com, .name and .post are the exceptions for now).

The nice part, if you look after more than a couple of domains: RDAP is plain HTTPS that returns JSON. You can query it with curl, filter it with jq, and turn it into an expiry check that runs from cron. Below is how to run an RDAP lookup from the terminal, read what comes back, make sense of the status values, and set up a small script that warns you before a renewal slips.

One RDAP lookup, nothing new to install

An RDAP server answers at a predictable path: its base URL, then domain/, then the name. For .com that server belongs to Verisign:

curl -s https://rdap.verisign.com/com/v1/domain/example.com | jq .

If you don't know which server handles a TLD, the public redirector at rdap.org looks it up and sends you there with a 302, so curl -sL https://rdap.org/domain/example.com works for any TLD it knows. ICANN offers the same lookup in a browser at lookup.icann.org.

The full reply is long and mostly notices and links. The parts you care about fit in one jq filter:

curl -s https://rdap.verisign.com/com/v1/domain/example.com | jq '{
  name: .ldhName,
  status,
  events: ([.events[] | {(.eventAction): .eventDate}] | add),
  nameservers: [.nameservers[].ldhName],
  dnssec: .secureDNS.delegationSigned
}'

Where the server address comes from

Hard-coding Verisign works for .com and .net. The proper way to find a server is the IANA bootstrap file at https://data.iana.org/rdap/dns.json, which maps each TLD to its RDAP base URL. It's the same file rdap.org and ICANN's lookup read:

curl -s https://data.iana.org/rdap/dns.json \
  | jq -r '.services[] | select(.[0] | index("com")) | .[1][0]'

That prints https://rdap.verisign.com/com/v1/. Every gTLD is in the file, plus a growing number of country-code TLDs, but not all of them. When we checked this week, .uk was listed while .de, .io and .co were not. Country-code registries aren't bound by ICANN's contracts, so for those you still use the registry's own WHOIS or web lookup.

Reading the reply

Take the fields in the order you'd check them when something has gone wrong.

events is a list of dated actions. registration is when the name was first created, expiration is the date the registry has on file, and last changed is the most recent update to the domain itself, such as new nameservers, a status change or a renewal. Every date is in UTC. last update of RDAP database only tells you how fresh the answer is.

status uses the same values registrars and registries exchange over EPP, written out in plain words. client transfer prohibited is the transfer lock your registrar sets, the one you toggle in its panel. The server ... versions come from the registry, and only the registry can lift them.

nameservers is the delegation, the servers the TLD sends resolvers to. If this list doesn't match your DNS provider, nothing you edit in that provider's zone will ever be seen. It's the same mismatch that dig +trace exposes, viewed from the registry's side.

secureDNS says whether a DS record is published. delegationSigned: true means resolvers will validate DNSSEC for the zone. If you're moving DNS to a new provider and this says true, sort out the DS record before you switch nameservers, or the domain fails validation the moment the change lands.

entities holds the registrar's name and IANA ID, plus an abuse contact. Registrant details are usually missing or marked as redacted. That's privacy policy at work, not a broken lookup.

Registry answer or registrar answer

For .com and .net the registry holds only part of the record. The rest sits with the registrar, and the registry reply points there with a link of type related:

curl -s https://rdap.verisign.com/com/v1/domain/example.com \
  | jq -r '.links[] | select(.rel == "related") | .href'

example.com is a reserved name held by IANA, so it has no such link, but a normally registered .com returns a URL on its registrar's own RDAP server. Query that one as well when you want the registrar's view.

It matters most around expiry. When a .com reaches its expiration date, the registry renews it automatically for a year, and the registrar then has a grace window of up to 45 days to keep it or delete it. So the registry's date can jump a year ahead even though nobody has paid. If the status list includes auto renew period, don't trust that date. Log in to your registrar account and check that the renewal really went through.

Status values worth a second look

Most domains show some mix of the three client ... prohibited values. That's the normal registrar lock, and it's what you want on a name you aren't moving. These are the ones that mean something is happening:

client hold or server hold: the domain is pulled from the zone and doesn't resolve at all. Registrars set it for things like an unpaid renewal or a registrant email that was never verified.
pending transfer: a move to another registrar is in progress. If nobody on your side asked for one, call your registrar today.
redemption period: the domain was deleted and can still be restored, usually for a much higher fee than a renewal.
pending delete: redemption is over. The name gets released within days and can't be renewed.
server ... prohibited on its own: a registry-level lock. It's either a paid registry lock or a name the registry is protecting, which is why example.org carries all three.
active: no statuses at all. Fine for a moment during a transfer, but on a name you're keeping it means only the auth code stands between the domain and a transfer request.

If you're about to move a domain, unlocking a domain before a transfer covers which of these you can clear yourself.

A small expiry check for cron

Registrars send renewal reminders, but they go to whatever email was on the account when it was opened. A script that reads the registry directly doesn't care about a dead mailbox. This one takes a file with one domain per line, finds each TLD's server in the bootstrap file, and prints the days left. It exits with 1 when anything needs a look, so it slots into cron or a monitoring check.

#!/usr/bin/env bash
# Usage: domain-expiry.sh domains.txt [warn_days]
# Needs curl, jq and GNU date.
list=$1; warn=${2:-30}; rc=0
boot=$(curl -fsS https://data.iana.org/rdap/dns.json) || exit 2

while read -r d; do
  [ -z "$d" ] && continue
  tld=${d##*.}
  base=$(jq -r --arg t "$tld" \
    'first(.services[] | select(.[0] | index($t)) | .[1][0]) // empty' <<<"$boot")
  if [ -z "$base" ]; then
    printf '%-22s no RDAP server for .%s, check by hand\n' "$d" "$tld"; continue
  fi

  json=$(curl -s -w '\n%{http_code}' "${base%/}/domain/$d")
  code=${json##*$'\n'}; json=${json%$'\n'*}
  if [ "$code" != 200 ]; then
    printf '%-22s lookup failed: HTTP %s\n' "$d" "$code"; rc=1; continue
  fi

  exp=$(jq -r 'first(.events[] | select(.eventAction=="expiration") | .eventDate) // empty' <<<"$json")
  flags=$(jq -r '[.status[] | select(test("hold|redemption|pending delete|auto renew period"))] | join(", ")' <<<"$json")
  if [ -z "$exp" ]; then
    printf '%-22s no expiration date in the RDAP reply\n' "$d"; rc=1; continue
  fi
  days=$(( ($(date -d "$exp" +%s) - $(date +%s)) / 86400 ))

  note=ok
  [ "$days" -lt "$warn" ] && { note="RENEW SOON"; rc=1; }
  [ -n "$flags" ] && { note="CHECK: $flags"; rc=1; }
  printf '%-22s expires %s  %4d days  %s\n' "$d" "${exp%%T*}" "$days" "$note"
  sleep 1
done < "$list"
exit $rc

A few notes on what it does and why:

It sleeps a second between lookups. Registries rate-limit RDAP, and a burst of queries can earn you HTTP 429 replies instead of data.
A 404 means the registry has no such name. In a list of domains you own, that's either a typo or a domain that's already gone. If it's gone, run a domain search right away to see whether you can register it again.
TLDs missing from the bootstrap file get reported, not skipped silently, so a .de name doesn't fall off your radar.
It uses GNU date -d. On macOS, install coreutils and swap in gdate.

To run it every Monday and only hear about problems, wrap it in chronic from the moreutils package, which stays quiet unless the command exits with an error:

MAILTO=ops@example.com
0 8 * * 1  chronic /usr/local/bin/domain-expiry.sh /etc/domains.txt 45

A 45-day threshold leaves room to fix a declined card or a dead login before anything breaks. Want to see the warning fire once? Pass a big number, such as 300, like the second run in the screenshot.

What RDAP can't tell you

RDAP shows what the registry knows. It can't tell you whether the card on file still works, whether auto-renew is switched on, or who at your company holds the registrar login. Those live in the registrar account, and they're covered in renewing a domain name before it expires. Keep the script running next to that checklist, not instead of it.

If the audit turns up names scattered across old registrar accounts, you can bring them under one login with a domain transfer to Pro Gineous, and every lookup above works the same afterwards.

How to Read DMARC Reports Before You Move to p=reject

Pro Gineous — Tue, 20 Oct 2026 08:12:55 +0000

Most domains that have DMARC at all are sitting on p=none. Someone added the record while setting up email, pointed rua= at a mailbox, and the reports have been arriving every day since: small zip and gzip attachments from Google, Outlook and other receivers, usually unopened.

Those files answer the one question you need settled before tightening the policy: who is sending mail with your domain in the From line, and would that mail survive p=quarantine or p=reject? Below is how to read them with nothing more than dig, unzip and a small XML tool, and how to move up the policy ladder without losing invoices or password resets on the way. If SPF and DKIM aren't set up yet, start with how to set up business email on your own domain and come back once those records exist.

First, confirm what you've published

Reports describe how receivers judged your mail against your DNS records, so read those records the way a receiver would. Three lookups cover it:

dig +short TXT _dmarc.example.com
dig +short TXT example.com
dig +short TXT s1._domainkey.example.com

The DMARC record lives at the _dmarc label, not on the domain itself. p=none means "report, but don't act", and rua= is where aggregate reports go. If that address is on a different domain, such as a reporting service, the other domain has to publish a small authorization record (example.com._report._dmarc.reports.example.net with the value v=DMARC1). Without it, receivers quietly skip sending.

On the domain itself, look for exactly one TXT record starting with v=spf1. Two of them make SPF return a permanent error, which counts as a fail for DMARC. Other TXT records, like site verification strings, can sit alongside it.

DKIM is the awkward one, because there's no way to list a domain's keys. You need the selector, which is the s= tag in the DKIM-Signature header of any message you've sent (use "show original" or "view source" in your mail client). Your mailbox provider uses one selector, and every other service that signs as your domain uses its own. A 2048-bit key is longer than the 255-character limit for a single TXT string, so dig prints it as two quoted chunks. That's normal. Receivers join them back together.

Open one report

Reports arrive as attachments named after the receiver, your domain and the time window they cover:

google.com!example.com!1792281600!1792367999.zip
enterprise.protection.outlook.com!example.com!1792281600!1792368000.xml.gz

The two long numbers are the start and end of the window in Unix time. date -u -d @1792281600 turns the first one into midnight UTC on October 18. Some receivers zip the file and others gzip it, so unzip or gunzip gets you to the XML. After a short header naming the reporter and repeating the policy it found, there's one <record> per combination of sending IP and result. This one deserves a close look:

<record>
  <row>
    <source_ip>198.51.100.24</source_ip>
    <count>212</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>mailer.example.net</domain>
      <result>pass</result>
      <selector>m1</selector>
    </dkim>
    <spf>
      <domain>bounces.mailer.example.net</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

Read it in this order:

source_ip and count: 212 messages from one IP, all showing example.com in the From header (header_from).
auth_results: the raw checks. DKIM passed and so did SPF. On their own, they look fine.
policy_evaluated: DMARC's verdict, and both say fail. DMARC only counts a pass when the domain that passed matches the From domain. DKIM was signed by mailer.example.net and SPF checked bounces.mailer.example.net. Neither is example.com, so neither is aligned.
disposition: what the receiver actually did. none, because that's what the policy asked for. Under p=reject, those 212 messages would have bounced.

Passing in auth_results but failing in policy_evaluated is the pattern you'll see most, and it's nearly always a legitimate service you forgot about, not an attacker. Reports that follow the updated aggregate reporting spec (RFC 9990) may add an xmlns attribute and a few extra fields, but the record layout is the same.

Turn a folder of reports into a sender list

One report is readable by eye. A month of them from a dozen receivers isn't, so pull out the useful columns with xmlstarlet (apt install xmlstarlet on Debian and Ubuntu, brew install xmlstarlet on a Mac):

unzip 'google.com!example.com!1792281600!1792367999.zip'
gunzip 'enterprise.protection.outlook.com!example.com!1792281600!1792368000.xml.gz'
xmlstarlet sel -t -m //record -v row/source_ip -o ' ' -v row/count \
  -o ' dkim=' -v row/policy_evaluated/dkim -o ' spf=' -v row/policy_evaluated/spf \
  -o ' signer=' -v auth_results/dkim/domain -n *.xml | sort -k2 -rn

Then ask DNS who each unfamiliar IP belongs to with a reverse lookup, for example dig +short -x 198.51.100.24.

Every row lands in one of four buckets, and each bucket has its own fix:

Your mailbox provider (192.0.2.25 here). DKIM and SPF are both aligned. Nothing to do.
A service sending on your behalf (198.51.100.24, which reverse-resolves to a newsletter platform). It passes, but for the wrong domain. Most of these services have a "domain authentication" or "custom sending domain" setting that hands you one or two CNAME records, such as m1._domainkey.example.com pointing at their key. Once they sign with d=example.com, DKIM aligns and DMARC passes. Aligning SPF too, with a custom return-path on a subdomain, is nice to have but not required. One aligned pass is enough.
Your own servers (203.0.113.80, the web server). A contact form or shop sending straight from PHP, with no DKIM signature and an IP that isn't in SPF. Resist the urge to just add the IP to SPF. Send that mail through your mailbox provider's SMTP submission port with a real account instead, so it gets the same aligned signature as everything else.
Nobody you recognize (203.0.113.199, no reverse DNS, nine messages). That's someone using your domain without permission, and it's exactly the mail p=reject exists to stop. Leave it failing.

Expect a fuzzy fifth group as well: forwarded mail and mailing lists. A list that adds a footer breaks the DKIM signature, and a forwarder's IP was never in your SPF, so a small trickle of failures from university or ISP ranges is normal and can't be fixed from your side. Some large receivers use ARC to give that mail the benefit of the doubt. Don't chase it.

When the volume outgrows a shell one-liner, open-source parsers like parsedmarc can load reports into a dashboard, and hosted report services do the same job. The four buckets stay the same.

Tighten in steps, not in one edit

Once every legitimate source in the last few weeks of reports is aligned, raise the policy one level at a time:

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

Older guides ramp up with pct=10, then pct=25, and so on. RFC 9989, the DMARC standard published in May 2026, retires pct because receivers applied the in-between values inconsistently. Its replacement is t=y, which asks receivers to apply one level below what you published, so p=reject; t=y behaves like quarantine at receivers that support it. Plain steps work everywhere: stay on quarantine for a couple of weeks, confirm that nothing legitimate shows up with a quarantine disposition, then move to reject.

A few habits keep each change uneventful:

Keep rua= for good. Reports are how you'll spot the next forgotten sender, like a helpdesk or billing tool someone signs up for next year.
Lower the TTL on the _dmarc record to 300 or 600 seconds before each change, so stepping back takes minutes rather than hours.
Decide on subdomains deliberately. sp= sets the policy for existing subdomains, which otherwise inherit p. Receivers that follow RFC 9989 also read np=reject, which covers subdomains that don't exist at all.
Lock down domains that never send mail. A parked domain can publish v=spf1 -all and v=DMARC1; p=reject on day one. There's nothing to monitor.

After each step, send a test message from every service in bucket two and check that the Authentication-Results header on the received copy shows dmarc=pass.

What reject actually buys you

At p=reject, receivers that honor DMARC refuse mail that claims to be from your domain and can't prove it. Phishing that copies your exact address stops reaching customers' inboxes, and your own mail stops sharing a reputation with whoever was spoofing it. Look-alike domains are a separate problem, and DMARC doesn't cover them.

None of this needs special software. A few weeks of reading the reports, fixing the senders you recognize, and reject becomes a short DNS edit instead of a gamble. If you're moving mailboxes as part of the cleanup, Pro Gineous business email gives each address a mailbox on your own domain, and every check above works the same there as with any other provider.

Why WordPress Missed Your Scheduled Post (and How to Fix WP-Cron)

Pro Gineous — Mon, 19 Oct 2026 08:38:46 +0000

You scheduled a post for 11:00, closed the laptop, and came back after lunch to find it still sitting in the Posts list with a red "Missed schedule" label where the publish date should be. Nothing crashed. No error email arrived. WordPress just never got around to it.

The cause is almost always WP-Cron, the scheduler built into WordPress. It makes one big assumption about your traffic, and when that assumption fails, scheduled posts, backups and digest emails all slip together. Here's how it works, how to confirm it's the culprit, and how to replace it with something that runs on time.

WP-Cron isn't a clock

When you click Schedule, WordPress doesn't set a timer anywhere. It saves the post with the status future and adds a one-off job called publish_future_post to a list stored in the database (the cron option in wp_options). Plugin chores like backups and update checks live in the same list.

Nothing watches that list on its own. Instead, on each page request WordPress checks whether anything on it is due. If something is, it fires a quick HTTP request at its own wp-cron.php (a loopback request) and carries on without waiting for the reply. That second request is what actually publishes your post.

So the default setup needs three things to line up: a visit that reaches PHP, a loopback request that gets through, and a server that lets the job finish. Take away any one of them and the schedule drifts.

Why the schedule slips

Nobody visited. A small site can go hours without one uncached request. The post is due at 11:00, the first real visit comes at 12:40, and that's when it goes live. Posts on a quiet site appearing late by a random amount is the classic pattern.

The visits never reached WordPress. Full-page caching (a caching plugin's static files, a server-level cache, or a CDN in front of the site) is great for speed, but a cached page is served without loading WordPress, so nothing checks the job list. A busy site behind a good cache can behave exactly like a site with no visitors.

The loopback request fails. The server has to be able to reach its own domain over HTTP. A staging password (HTTP basic auth) answers 401. A security plugin or firewall rule may block wp-cron.php. After a migration, the server can still resolve your domain to the old IP (DNS answers are cached, as covered in how long DNS changes take to show up) and send the request to a machine that no longer hosts the site. WordPress flags this in Tools > Site Health as "Your site could not complete a loopback request."

Cron was switched off and never replaced. Someone added define( 'DISABLE_WP_CRON', true ); to wp-config.php to stop cron running on page loads, which is a sensible thing to do, but the server cron job that's meant to take over was never created. Or it existed on the old server and didn't come along in the move, because it lives in the server's crontab, not in WordPress.

A heavy job ran out of time. Cron jobs run in a normal PHP request, so they're bound by the same time limit. A big backup or import that hits that limit gets killed mid-run, and whatever was queued after it waits for the next spawn.

Also rule out the time zone under Settings > General. If it's set to UTC while you think in local time, every post goes out "late" by the same few hours. That's a settings problem, not a scheduler one.

Ask WordPress what it thinks is due

If your hosting gives you SSH, WP-CLI answers this in three commands. Run them from the site's folder (often public_html):

wp post list --post_status=future --fields=ID,post_title,post_date
wp cron event list
wp cron test

The first command lists posts still waiting to publish, with the time they were due in the site's own time zone. In wp cron event list, the next_run_gmt column is in UTC, so on a site set to Cairo time (UTC+3) the 08:00:00 job is the 11:00 post. Any row whose next_run_relative says now is overdue: WordPress knows the job should run and nothing has run it. One overdue row could be bad luck. A column full of now, including core jobs like wp_version_check, means cron hasn't run for hours.

wp cron test makes the same loopback request WordPress would, but waits up to three seconds for the answer. Here's how to read the result:

Success: WP-Cron spawning is working as expected. The loopback path is fine, so look at traffic and caching instead.
cURL error 28 (a timeout, as in the screenshot) usually points at a firewall rule, a DNS answer pointing somewhere else, or a server that can't reach itself.
HTTP status code: 401 means a password sits in front of the site.
An error saying the DISABLE_WP_CRON constant is set means cron is switched off on purpose, so go and find the server cron job that should exist.

No SSH? The free WP Crontrol plugin shows the same event list inside wp-admin, and Site Health reports late scheduled events and failed loopback requests.

Hand the schedule to the server

The reliable fix is to stop depending on visits at all. Let the server's own scheduler run the queue every few minutes, and tell WordPress to stop trying on page loads.

Start by switching off the visit-triggered runner:

wp config set DISABLE_WP_CRON true --raw

That writes define( 'DISABLE_WP_CRON', true ); into wp-config.php. You can also add the line by hand, anywhere above the /* That's all, stop editing! */ comment.

Next, add a server cron job. Cron runs with a very short PATH, so find the full path to WP-CLI with which wp and use it in the line. With WP-CLI available, this is the cleanest version, because it runs due events directly in PHP instead of going through HTTP:

*/5 * * * * cd /home/exampleco/public_html && /usr/local/bin/wp cron event run --due-now --quiet

Without WP-CLI, request wp-cron.php over HTTP instead:

*/5 * * * * curl -s -o /dev/null "https://example.com/wp-cron.php?doing_wp_cron"

The HTTP version still depends on the server reaching itself, so if wp cron test failed earlier, fix that first or stick with WP-CLI. Over SSH, add the line with crontab -e. On cPanel hosting, the Cron Jobs page takes the same command and has a ready-made "Once Per Five Minutes" option. Five minutes is a good default: scheduled posts go out within a few minutes of their time, and the server barely notices.

Finally, clear the backlog once by hand with wp cron event run --due-now, then check the stuck post with wp post get 1482 --field=post_status. It should now say publish.

If you really can't add a cron job

Some plans offer neither cron nor SSH. One fallback is an external cron service that requests https://example.com/wp-cron.php?doing_wp_cron every few minutes, which works as long as that URL isn't blocked or cached. The other is define( 'ALTERNATE_WP_CRON', true );, which makes WordPress run cron by redirecting a visitor's own request instead of making a loopback call. It sidesteps a broken loopback but still needs visits, and visitors may see ?doing_wp_cron= in the address bar. Treat both as stopgaps.

Prove it the next day

The day after the change, check that it actually works:

Schedule a test post ten minutes out and stay off the site. If it goes live on time with no visits from you, the server cron is doing the work. (If new posts are shared to social media automatically, pause that first, then trash the test post.)
Run wp cron event list again. Recurring jobs like wp_version_check should show a future time, not now.
Add the cron line to your migration notes. The next time the site moves hosts, it's the one setting that won't move with the files and database, and if both old and new servers keep running cron against the same site during a cutover, scheduled emails can go out twice.

WP-Cron is a reasonable default for a site that gets steady, uncached traffic. For anything that publishes on a schedule or runs nightly backups, a five-minute server cron job is the boring, dependable choice. Pro Gineous shared hosting plans include cPanel, SSH and WP-CLI, so everything above can be set up from the control panel or the terminal in a few minutes.

DEV Community: Pro Gineous

Why Your SPF Record Fails With Too Many DNS Lookups, and How to Get Back Under 10

Where the error shows up

What counts toward the 10

Count it by hand once

Count it with one command

Getting back under 10

Test before you publish

Why Your Site Loads on www but Not on the Bare Domain (and How to Fix It)

Four addresses, one site

Layer 1: does each name have a record?

Why the apex can't be a CNAME

The AAAA record nobody remembers

Layer 2: is the server answering for that name?

Layer 3: does the certificate cover both names?

Layer 4: redirects that go in circles

Pick one name and 301 the rest

Check all four in one go

Quick answers

Should you use www or the bare domain?

Domain not working without www, but DNS looks right?

How long until a fixed record works everywhere?

Is a Disk Dying in Your Dedicated Server? How to Check Disk Health on Linux

The quick check

Find the disks and install smartmontools

Why PASSED doesn't mean healthy

NVMe drives report different numbers

Ask the drive to test itself

Read the RAID state

One script for all of it

Replacing a failing disk in mdadm RAID 1

Make the server tell you

FAQ

How often should you check disk health on Linux servers?

Is a disk with a few reallocated sectors safe to keep?

Can smartctl check disks on a VPS?

Moving Hosts? Test Every Page on the New Server Before You Change DNS

Lower the TTL a day or two early

Clicking around with the hosts file

Check the certificate on the new IP

Compare every URL, not just the home page

The parts a page check won't see

Switch, then keep the old server running

FAQ

Can you test a site on a new server without editing the hosts file?

How far ahead should you lower the TTL?

Why does the new server show the wrong certificate?

Is Your Cloud Server Slow Because of CPU Steal? How to Check

Where to see CPU steal time

When the number means something

Reading the pattern

Keep a record with sar

Doing it in one command

What to do about it

Related reading

How to Prepare a Domain Transfer So DNS and Email Keep Working

What actually moves

Two weeks before: read the registry record

The 60-day rules, and what ICANN has changed

One week before: snapshot DNS and look at DNSSEC

Take a snapshot you can rebuild from

DNSSEC is where the outages come from

Transfer day: lock off, code, approval email

The five days in between

After it lands

Doing it in one command

Related reading

How to Check SSL Certificate Expiry Before Browsers Start Warning

Why "auto-renew is on" isn't enough anymore

The one command worth memorizing

Reading the rest of the certificate

Renewed, but the old one is still being served

When the renewal itself is failing

Quick reference: what you see and where to look

Put it on a schedule

How to Check Whether Your Server Is Patched Against PHP2Shell

What PHP2Shell is and which versions are fixed

What we know about exploitation

Why the version number can mislead you

How to check your PHP version and build date