Setting up the WordPress plugin

Setup

The DomainWarn plugin adds the addresses of your WordPress site to monitoring and reports every 15 minutes what no outside check can see: versions, pending updates, the mail setup – and whether WP-Cron still runs.

In the WordPress admin go to Plugins → Add New, search for "DomainWarn", install and activate it.
Under Settings → DomainWarn click "Connect with DomainWarn". You confirm in DomainWarn, and the token lands on the site by itself – nothing to copy. A free account is enough.
"Add addresses" – done. Pick a client if you like; from then on the plugin reports every 15 minutes.

Prefer to do it by hand? Create a token with write scope in DomainWarn under Settings → API and paste it into the "API token" field. On the command line the same steps are wp domainwarn test, wp domainwarn sync and wp domainwarn report.

For the heartbeat to work, WP-Cron must run – which is exactly what it checks.

Requirements: WordPress 6.3 or newer, PHP 8.2 or newer and a DomainWarn account – the free one is enough.

What the plugin reports

WordPress and PHP version: The exact version instead of a guess. Whether it is outdated or no longer gets security updates is judged by DomainWarn from the current releases and the PHP support periods.
Pending updates: Plugins and themes with an available update, each with the installed and the available version.
Mail setup: Sender address and mail server. Together with the DNS records this yields the finding "your site sends through a server that is not in the SPF record" – which neither the site nor an outside check can reach on its own.
Maintenance mode: If maintenance mode stays on by accident after an update, the site is closed to visitors and search engines. DomainWarn points it out.
WP-Cron heartbeat: A scheduled run reports in every 15 minutes. If it stops, WP-Cron has stalled: the site still answers, but no mail goes out and nothing is processed. DomainWarn then opens an incident and sends it to your channels.

Data transferred

Transmitted are the addresses of the site, WordPress and PHP version, names and versions of installed plugins and themes, sender address and mail server, and the maintenance mode. Not transmitted are users, posts, comments, orders or any other content. The API token stays on the site and never reaches the browser; without a token the plugin stays idle and contacts nothing.

Hosting through the WordPress plugin and the Shopware extension

If the domain runs WordPress or Shopware 6, the security.txt needs no line in the web server: the plugin or extension serves the file itself. Switch on "Serve security.txt via DomainWarn" in its settings (default: off) – from then on the site fetches the file from DomainWarn and answers /.well-known/security.txt itself with 200 and text/plain, byte for byte and without a redirect. The file is kept for an hour; while DomainWarn cannot be reached, the last good copy is served as long as its Expires lies in the future. In Shopware this applies per sales channel domain.

It only serves where the file belongs: at the domain itself or with www in front of it (a site at blog.client.example serves nothing), only when the site sits at the domain root, and only from a file of the exact form https://domainwarn.com/security-txt/<token>/security.txt. That address comes from a stored status that the scheduled run refreshes every 15 minutes when due (GET /api/v1/orgs/<slug>/domains/<id>/hosting); a normal page view never contacts DomainWarn. Only content that looks like a security.txt is accepted (a Contact line, no HTML); without a usable file the site answers as it would without the plugin. If a security.txt already lies in the web root or another plugin answers the address, the settings page shows it as a conflict and serving stays off – nothing is overridden silently.

"Check security.txt" fetches the address like a researcher, compares the file byte for byte with the one at DomainWarn (Contact and Expires present) and shows the result of DomainWarn's own check next to it. If a cache still holds an older copy, the check says so.

MTA-STS cannot be served this way: RFC 8461 forbids sending mail servers to follow redirects when fetching the policy. The policy has to live at mta-sts.client.example itself – the CNAME to DomainWarn takes care of that. For MTA-STS and BIMI the plugin and the extension therefore only show the status (active, record missing, outdated, not set up), the records to copy and a button to the dashboard page where a connected DNS provider sets them with one click.

Frequently asked questions

Do I need a paid account?: No. The plugin is free and works with the free DomainWarn account. What is charged is the monitoring service, once more domains or shorter check intervals are needed.
Is content of my site transmitted?: No. Transmitted are addresses, versions, installed plugins and themes, sender address and mail server, and the maintenance mode. No users, posts, comments or orders.
Why does DomainWarn open an incident although my site is up?: Because the heartbeat stopped. Then WP-Cron has stalled: the site still answers, but it sends no mail and processes nothing.
Does the plugin work with a self-hosted DomainWarn?: Yes. The API address can be changed on the settings page under "Advanced".