Today’s session started with a red banner in WP Mail SMTP and ended with a fully authenticated mail pipeline running through my own domain. Here’s the trail, and what I’d tell someone else hitting the same wall.
The Symptom
WP Mail SMTP flagged a failed send with a Gmail API error: CREDENTIALS_MISSING, Login Required. On the surface it looked like a plugin bug. It wasn’t — I’d configured the Google/Gmail mailer with Client ID and Secret, but never completed the OAuth authorization step. No token, no send. A reminder that partial configuration often looks complete right up until the moment it has to actually do the job.
The Pivot
Rather than debug Google’s OAuth flow (test-user scopes, consent screens, the works), I asked a more basic question: did I even want Gmail in the mail chain at all? I don’t use Gmail day-to-day, and I already have a real mailbox — dennis@ny2honolulu.com — sitting unused on my Network Solutions hosting package. Sometimes the fix isn’t fixing the thing in front of you, it’s asking whether that thing needs to be there.
The Real Troubleshooting
Switching to “Other SMTP” surfaced the actual lesson of the day: hostnames matter, and guessing at them wastes time.
I tried the “obvious” values first — mail.ny2honolulu.com, then smtp.ny2honolulu.com — both pulled straight from my hosting panel’s labeled incoming/outgoing server fields. Both failed identically:
php_network_getaddresses: getaddrinfo failed: Name or service not knownThat’s a DNS resolution failure, not a credentials problem — the server name itself doesn’t exist as advertised. Two different “correct-looking” hostnames failing the same way was the signal to stop guessing and go to the source. A quick live chat with Network Solutions support produced the real answer: netsol-smtp-oxcs.hostingplatform.com, port 465, SSL — a backend proxy hostname that isn’t documented anywhere in the self-service panel.
That one connected. Progress — but it then failed at 535 5.7.8 Authentication failed, a clean SMTP handshake followed by a rejected login. Reset the mailbox password, updated it on both ends (Network Solutions and WP Mail SMTP), and the test email landed.
The Finishing Touch
With SMTP working, I checked WP Mail SMTP’s built-in domain check: SPF was already valid, but DMARC was missing. Support added a monitoring-only DMARC record (p=none) directly to the domain’s DNS — the safer starting policy that reports on spoofing attempts without blocking legitimate mail while it’s new.
Same Day: CVE-2026-63030
Separately, this was also patch day for CVE-2026-63030 (“wp2shell”), an actively-exploited SQL injection vulnerability. The built-in WordPress auto-updater silently failed, so the fix went in manually: SFTP upload of WordPress 6.9.5, then an upgrade to 7.0.2. A good reminder that “the updater didn’t error” isn’t the same as “the updater worked” — verify the version number after, not just the absence of a red banner.
Takeaways
- A visible error and a silent failure deserve equally close attention. The auto-updater failing quietly was arguably the riskier of today’s two issues.
- When the same class of error repeats with different specific values (two different hostnames, same DNS failure), that’s a signal the informal panel documentation is wrong — go to a human, don’t keep guessing.
- “Connected, then rejected” (535 auth error) is a completely different failure mode than “couldn’t connect at all” (DNS error) — read the debug log’s stage, not just its presence, to know what to fix next.
- DNS changes need time. Don’t panic-check DMARC/SPF propagation for a few hours after a support tech makes the change.
Both fixes are live now: the domain sends its own mail, and the CVE is patched. Next up: circling back to confirm DMARC propagated cleanly.