Bits of .NET

🔧 The Password Reset Email That Only Started Failing After the Move

WordPress, by default, hands outgoing mail to PHP’s built-in mail() function, which only confirms the message was accepted by the server’s local mail system – it has no visibility into, and therefore no way to report on, whether the receiving mail provider actually accepted or rejected it afterward. Switching hosts changes the IP address outgoing mail is sent from, and if the domain’s SPF record (and any DKIM configuration) wasn’t updated to authorize the new host, every outgoing email, including something as time-sensitive as a password reset, starts failing authentication checks at the receiving end while WordPress continues reporting success the entire time.

🔎 The Problem

Old host: mail sent from IP 203.0.113.10
DNS: SPF record includes 203.0.113.10 as an authorized sender for
blog.example.com - password reset emails pass SPF/DKIM checks,
deliver to the inbox normally.

After switching hosts: mail now sent from IP 198.51.100.44
DNS: SPF record was never updated - still only authorizes the OLD
host's IP.

Receiving mail server's perspective:
  Message claims to be from blog.example.com
  SPF check:  FAIL (sending IP not authorized for this domain)
  DKIM:       not configured at all, or configured against the
              old host
  Result:     delivered to spam, or silently dropped, depending on
              the receiving provider's own policy - WordPress
              itself reports the email as "sent" successfully the
              entire time, because as far as PHP's mail() function
              is concerned, it was.

✅ Fix: Update DNS Authentication for the New Host

• Update the domain’s SPF record to authorize the new host’s outgoing mail servers (or switch to an SMTP plugin that sends through a dedicated transactional email service, which typically handles this configuration for you).
• Set up DKIM signing for the domain through the new host (or through whichever SMTP service is actually sending the mail), since SPF alone is frequently not enough for modern spam filtering to trust a message fully, especially right after a hosting change with no established sending history yet.
• Switch away from PHP’s built-in mail() function to a proper SMTP plugin or transactional email provider generally, regardless of the specific hosting change – PHP’s mail() gives WordPress no visibility into whether a message was actually accepted by the receiving server, only whether it was handed off locally.

⚠️ Why This Is Easy to Miss

• WordPress reporting ’email sent’ only confirms the message was handed to the server’s local mail system – it has no way to know, and therefore no way to report, whether the receiving mail provider actually accepted or rejected it afterward.
• This specific failure is invisible to anyone testing with an email address at the same domain, or one already trusted by whichever provider happens to be used for testing – it often takes a genuinely new user requesting a reset from an unrelated provider to actually surface the problem.