In November 2026, a client was presented with a comprehensive security audit from one of their very large customers. The report was an effort to improve security practices throughout their supply chain. The report covered all sorts of items including DNS records, email deliverability and website issues. This post covers standard security tasks any WordPress site can apply, including CSP headers, DKIM tightening and 2FA login.
Group the security report’s items
It can be daunting to start tackling an audit report that touches multiple systems. Rather than work through the report top-to-bottom, it helps to group the items first.
Email deliverability and spoofing
Looking at the report, it’s clear that the industry was trying to make it harder for bad actors to spoof emails. That makes sense, given that a lot of large hacks seem to begin with phishing attacks as hackers try to blag access to private resources. There’s been a big push by Google and Microsoft recently to require SPF, DKIM and DMARC for email deliverability. It’s one thing to set those up, but it’s another to configure them to be strict.
DNS housekeeping
When a company has owned a domain name for years, it’s amazing how much cruft can end up in the DNS zone. When adding or editing DNS records, it’s all to easy to leave old records as they are so as not to break anything. But housekeeping is important here. If a DNS record looks old or unusual, consider deleting it. If something breaks, you can always put it back.
Website headers and security
As a WordPress hosting provider, this one should be easy for me to sort out. The report wanted CSP headers and tighter HTTP response headers. The gains with these are slight, but worth grabbing.
Strengthen email with DKIM and a strict DMARC policy
This is the big one because it should slash the risk of a company’s email domain being spoofed. The goal is to set the DMARC record to p=reject. That means a server receiving an email claiming to be from your domain will reject it if it passes neither SPF nor DKIM with the domain aligned.
Switching DMARC to p=reject has to be done after we’ve set up the SPF and DKIM DNS records. As part of this move, I installed my WP Mail DKIM Signing plugin on their website. This lets the website sign outgoing emails, even though our email server doesn’t handle emails for their domain. That’s important when you consider the website sends password-reset emails and contact form submissions. Exactly the sort of thing that a bad actor might try to spoof.
Once I’d set up the website to add DKIM email headers, we fixed and checked DKIM signing for their main email system (that was for their IT people to do, but we helped verify the changes).
Then it was a case of removing some cruft from their SPF record, and testing everything with MX Toolbox. Once we confirmed that DKIM and SPF were good for the website and the client’s main email system, we flicked the DMARC policy to p=reject and tested everything again.
Tight emails… done
WordPress security
The first easy win was to install a 2FA plugin. My Quick 2FA plugin verifies by email, which is why we had to do the DKIM stuff first (otherwise users wouldn’t receive their 2FA login emails). It wasn’t actually on the security audit, because they had no way of knowing if a 2FA plugin was installed or not. But it was an easy win, so why not.
Then on to the HTTP response headers:
- Referrer-Policy
- Strict-Transport-Security
- X-Content-Type-Options
- X-Frame-Options
We already had most of these in place, but I wanted to refine and tighten things a bit. I implemented these on our web server fleet and tested with MDN’s Observatory tool.
Then I used my Easy CSP Headers plugin to add CSP headers to the site. That has to be done in WordPress so the script nonces can align with the HTTP headers.
Tidying up the DNS
The final leg of the project involved removing old DNS records, left over from old hosting providers, various experiments and old remote-access records.
Don’t forget to prune your SPF record too. It’s too easy to look at ip:123.123.123.123 in an SPF record and think, “I’d better not touch that, I don’t know what it is”. But that’s exactly the sort of record that needs to either be accounted for, or removed.
We re-tested email sending again, checked the client could receive their website 2FA emails, and rescanned the website headers (HTTP & HTML) with MDN.
MX Toolbox shows SPF, DKIM and DMARC passing for the domain. Emails are being delivered with a tight DMARC policy, and the website is in good health (CSP headers haven’t broken the page rendering). My client was able to feed back a positive result to their customer, and to the security auditors.