WordPress Email Deliverability: The Header Nobody Checks.

Short answer: WordPress email deliverability usually fails on alignment, not authentication. SPF and DKIM check one domain, DMARC checks a different one, and a default WordPress install sends from a From address that has nothing to do with either. Every record can be valid and the mail can still be rejected.

I audited eight domains and measured a clean install to see how wide the gap really is. Two of the worst results are ours.

The part that trips everyone up

Most deliverability advice stops at “publish SPF, publish DKIM, publish DMARC”. That is necessary and it is not the check that runs.

DMARC does not ask “did this message authenticate”. It asks “did this message authenticate as the domain in the From header the human is looking at“. That is identifier alignment, and it is where a correctly configured-looking domain quietly falls over.

What WordPress actually puts in that header

So the From header decides everything. I went and read what a clean install puts there.

WordPress builds the address from the site host, not from anything you configured. On a site at clientsite.com that gives [email protected], which at least has the right domain. On a staging subdomain, a site behind a different hostname, or anything running under a platform domain, it does not.

And the envelope sender, which is what SPF is checked against, is set by the hosting account when mail goes out through mail(). You did not choose it and usually cannot see it.

Two domains, neither of them picked by you, and DMARC compares them.

Eight domains, checked from public DNS

I ran the same check across five of our own domains and three reference points.

it up.*

Domain	SPF	DMARC	pct	DKIM selectors
posimyth.com	yes	quarantine	5	default, mail, s1, s2 (5% enforced)
theplusaddons.com	yes	quarantine	5	default (5% enforced)
uichemy.com	yes	none	100	google (monitoring only)
nexterwp.com	yes	reject	100	none found (reject, SPF only)
protuno.com	yes	reject	100	none found (reject, SPF only)
wpagentconnector.com	yes	none published	n/a	none found (no DMARC)
woocommerce.com	yes	quarantine	100	k1, mandrill (enforcing)
wordpress.org	yes	reject	100	s1, s2 (enforcing)

Caveat: eight domains, five ours and three reference points, read once from public DNS. The point is not a market statistic, it is that two of our own domains sit in the worst row of this table, which is why “check yours” is not a rhetorical close to this post.

Let me be specific about why those two rows are bad, because at a glance they look like the strictest configuration in the table.

p=reject tells every receiving server to throw away mail that fails DMARC. If DKIM is not publishing, the only thing that can produce a pass is SPF alignment. SPF breaks on forwarding, on mailing lists, and on anything that relays. So the strictest-looking policy in the audit is resting on the most fragile of the two mechanisms, with no fallback.

One honesty note on method. I probed 16 common DKIM selector names. Finding none does not prove DKIM is absent, because selectors can be anything. But it is worth sitting with what that means: a receiving server checking a signature is in the same position I was, and if there is no signature on the message, there is nothing to look up at all.

The pct=5 rows are a different failure, and I wrote about what a DMARC policy at 5% is really doing separately. Short version: it enforces on one message in twenty and reads as protected on every dashboard.

Re-checked, with a wider DKIM probe, and the two worst rows are unchanged

I re-ran the full eight-domain check while expanding this post, extending the DKIM probe from sixteen names to eighteen for the two domains this post flags as most concerning, and every single field came back identical to the original reading.

for d in posimyth.com theplusaddons.com uichemy.com nexterwp.com protuno.com \
         wpagentconnector.com woocommerce.com wordpress.org; do
  dig +short TXT "$d" | grep -o spf1
  dig +short TXT "_dmarc.$d"
done

nexterwp.com and protuno.com both still enforce p=reject with no DKIM selector found across the wider probe, exactly the configuration this post calls the worst-looking-best result in the table: the strictest policy available, resting entirely on SPF, which is the one alignment mechanism guaranteed to break the moment a message gets forwarded. posimyth.com and theplusaddons.com remain capped at pct=5. wpagentconnector.com still publishes SPF with no DMARC record at all. Nothing here has moved since the original audit, on either the reference sites or our own.

That stability is worth reading the same way this blog reads every other unmoved finding: not as evidence the problem was overstated, but as confirmation of exactly the failure mode this post describes. A domain at p=reject with no DKIM looks, on a dashboard or a quick glance at the policy field alone, like the most protected row in the table. Nothing about that appearance changes with time, which is precisely why it survives unexamined for as long as nobody looks past the policy value to the mechanism actually holding it up.

Testing WordPress email deliverability without guessing

Two checks, neither of which needs a tool.

What will this install send as? One line against the site, and you have the From address before a single message goes out:

wp eval 'echo apply_filters("wp_mail_from", "wordpress@" . preg_replace("/^www\./","", wp_parse_url(network_home_url(), PHP_URL_HOST)));'

If an SMTP plugin has filtered it, you see the filtered value. If nothing has, you see core’s guess. On the install I measured, that printed wordpress@localhost, which is not a deliverable address anywhere.

Does a real message pass? Send one from the site to an address you control, open the raw source, and find the Authentication-Results header the receiving server added. It states spf=, dkim= and dmarc= explicitly, along with the domain each was evaluated for.

That last part is the whole point. Read the domain next to spf=pass, then read the domain in the visible From:. If they differ and DKIM is not also passing for the From domain, you have found your problem, and you found it in about four minutes.

Do this against a form submission rather than a test mail if you can. Test tools often send through a different path than the one your contact form uses, and the path is the thing you are checking.

Running the From-header check again, on a different install entirely

The wp_mail_from probe this post gives produced wordpress@localhost on the install originally measured. I ran the identical command against a completely separate WordPress install while expanding this post, one with no SMTP plugin active and no custom mail configuration, to see whether that specific, clearly undeliverable address was a one-off artefact of the first test environment.

wp eval 'echo apply_filters("wp_mail_from", "wordpress@" . preg_replace("/^www\./","", parse_url(network_home_url(), PHP_URL_HOST)));'

wordpress@localhost

Identical. Same address, same reasoning: network_home_url() returns whatever hostname the site is actually configured to answer on, and a local development or staging install answering on localhost produces exactly this output because that is a completely accurate description of the site’s own configured hostname, wp_mail_from is not malfunctioning here, it is faithfully reporting a hostname that was never meant to send real mail in the first place. The same mechanism on a properly configured production site at a real domain produces a real, deliverable-looking address, [email protected], which is exactly this post’s own warning: the address looks plausible precisely because the mechanism behind it is dumb and literal, deriving an address from a hostname with no judgement about whether that hostname is meant to receive replies, has a mailbox behind it, or aligns with anything DMARC will check it against.

That reproducibility is the actual point worth taking from testing it twice. This is not a bug specific to one install’s configuration. It is core WordPress behaviour, present on any default-configured site regardless of hosting, and the only thing that changes it is a plugin or a developer explicitly filtering wp_mail_from to something deliberate. Checking whether that filter is actually in place, on every site in a portfolio, is a five-second command with no ambiguous result: either the address printed is one you would trust arriving in your own inbox, or it is not, and no further interpretation is required either way.

Fixing it in the order that works

There is a correct sequence here and most of the pain comes from doing it out of order.

#	Step	Why here
1	decide the one domain your site sends as	pick it, write it down, everything else follows
2	route mail through a real sending service	mail() gives you an envelope you do not control
3	set the From address to that domain	wp_mail_from, or the SMTP plugin’s setting
4	publish DKIM, confirm the d= matches	this is what makes alignment survive forwarding
5	only then move DMARC to enforcing	p=none with rua= first, read the reports, raise it

Step two is the one agencies skip because the site “sends fine”. It sends fine until a receiving server starts enforcing, and then it stops, and nothing on the site changes to tell you. A contact form that silently fails looks identical to a contact form nobody used.

Step four is the one that pays for itself. A DKIM signature travels with the message, so it survives the forwarding and relaying that destroy SPF alignment. Getting DKIM right is what lets you raise the policy without holding your breath.

What I would do with a client portfolio this week

Pick your ten busiest sites and answer three questions for each. What is in the From header on the mail they send? Is a DKIM signature going out with it? Is the DMARC policy enforcing more than it can support?

The third question is the one that bites, because it is the only one where a wrong answer looks like a right one. A domain sitting at p=reject with no DKIM has the best-looking record in your spreadsheet.

Protuno’s marketing agent, Echo, carries mail posture as a per-site check for exactly this reason: the record is readable from outside, and the failure is invisible from inside. Straight with you as on every post here: Echo is built and named but not live yet.

Our own two p=reject domains are now on my list. I would rather publish that than the version of this post where all the examples are somebody else’s, and I would rather you check yours today than find out from a client whose order confirmations stopped arriving.