WordPress DNS Health Checks: SPF, DKIM, DMARC, and SSL Explained
A client’s password reset emails start landing in spam, or don’t arrive at all, and the WordPress install itself is completely innocent β the problem is sitting in DNS records nobody’s looked at since the domain was registered. WordPress DNS health checks catch exactly this class of problem: the ones that have nothing to do with plugins or themes and everything to do with whether the domain is configured the way mail servers and browsers expect.
Table of contents
- Why DNS health is a WordPress agency’s problem too
- SPF, DKIM, and DMARC, in plain terms
- Core DNS records worth checking beyond email
- SSL and HSTS: the browser-facing half
- Why propagation gets checked separately
- Reading a DNS health score without overreacting
- FAQ
Why DNS health is a WordPress agency’s problem too
DNS and email authentication live outside WordPress entirely, which is exactly why they’re easy to forget about once a site launches. Nobody logs into wp-admin to check an SPF record. But when a client complains that their contact-form notification emails aren’t arriving, or a hosting migration quietly drops a DKIM record nobody remembered configuring, the agency is the one who gets the call β whether or not the actual fix happens inside WordPress. Treating DNS as part of ongoing site health, not a one-time setup task at launch, is what DNS health monitoring is for.
SPF, DKIM, and DMARC, in plain terms
These three records exist to answer one question for every receiving mail server: is this email actually allowed to claim it’s from this domain?
- SPF lists which mail servers are allowed to send email on the domain’s behalf. Missing or misconfigured SPF is one of the most common reasons legitimate WordPress notification emails get marked as spam.
- DKIM attaches a cryptographic signature to outgoing mail so a receiving server can verify it wasn’t altered in transit and genuinely came from where it claims.
- DMARC tells receiving servers what to do when a message fails SPF or DKIM checks β ignore the failure, quarantine the message, or reject it outright β and can request a report back when that happens.
A DMARC policy set to reject failing mail is a stronger, more deliberate stance than one set to none, which mostly just monitors without enforcing anything β worth knowing which one a given domain actually has, since “DMARC exists” and “DMARC is doing something” aren’t the same claim.
Core DNS records worth checking beyond email
Email authentication is only part of the picture. A healthy domain also needs its A record actually resolving to the right server, an MX record correctly routing incoming mail, and at least two nameservers responding β a domain running on a single NS record is one host-side hiccup away from becoming completely unreachable. None of this is exotic, but it’s exactly the kind of configuration that’s set once during launch or migration and never checked again unless something breaks.
SSL and HSTS: the browser-facing half
DNS health isn’t only about mail. A valid SSL certificate that isn’t close to expiring, a working HTTP-to-HTTPS redirect, and an HSTS header telling browsers to always use HTTPS for the domain going forward all matter for the same reason SPF and DKIM do β they’re infrastructure-level settings that WordPress itself doesn’t manage or warn you about, but that directly affect whether visitors see a security warning instead of the site they came for.
Why propagation gets checked separately
DNS changes don’t take effect everywhere at once β different resolvers around the internet cache records for different lengths of time, so a record that looks correct from one location can still be stale somewhere else. Checking resolution against several independent public resolvers rather than just one is what actually confirms a DNS change has finished propagating everywhere, instead of just where you happened to check from.
Reading a DNS health score without overreacting
A single combined score is useful for triage across a fleet β sorting which of forty client domains need attention first β but it’s worth understanding roughly what it’s built from before treating a mid-range score as an emergency. SSL and email authentication typically carry the most weight, since those are the two categories most likely to visibly affect a real visitor or a real email landing in an inbox. A domain missing DKIM but otherwise clean will show a meaningfully lower score than one with every category in good shape β that’s the score doing its job, not a false alarm, but it’s still one specific fix (add the DKIM record) rather than a sign the whole domain is unhealthy.
Worth being direct about a real limitation: DKIM detection works by checking a handful of the most common selector names hosts and email providers actually use. A provider using a genuinely custom, non-standard selector may show as “not found” even if DKIM is technically configured β a good reason to treat a DKIM finding as a prompt to verify manually rather than the final word, the same way you’d double-check any automated scan before telling a client something is broken.
FAQ
Do I need to touch WordPress at all to fix a DNS issue?
No β DNS and email authentication records live at the domain registrar or DNS host, not inside wp-admin. WordPress plugins that handle outbound mail (an SMTP plugin, for instance) benefit from correct SPF/DKIM/DMARC records, but they don’t create or manage those records themselves.
How often do DNS records actually change unexpectedly?
More often than most agencies assume β a hosting migration, a switch to a new email provider, or a DNS host’s own interface change can all silently drop or alter a record nobody remembers touching. This is exactly why DNS health is worth checking on an ongoing basis rather than once at launch and never again.
Is a perfect DNS health score necessary for every client site?
Not universally β a brochure site that sends almost no outbound email has less riding on a strict DMARC reject policy than a client relying heavily on WordPress-triggered emails (order confirmations, lead notifications, password resets). Prioritize fixes on sites where broken email deliverability actually costs the client something.
Start a free 14-day trial and see your fleet’s real DNS health today, not just its WordPress health.