Triage
"Send mail as" Broke: A Patch-or-Dead-End Triage Tree
The verification email never came. Or it sent, then sat in spam. Or the reply went out as your @gmail.com address and a client noticed before you did. These look like one problem. They are several — and only some are worth an afternoon. This page sorts the fixable from the final.
When Gmail "Send mail as" is not working for your custom domain, the instinct is to start re-entering passwords. Sometimes that's right. Often it's shoveling against the tide, because the failure isn't a typo in your settings — it's Gmail stepping back from custom-domain sending. The trick is to classify the symptom first, then act. So before you touch a thing, run it through the triage below.
The triage tree
Find the symptom you're seeing. The middle column tells you what it really is; the right column tells you whether a patch buys real time or just delays the inevitable.
| Symptom you see | What it usually is | Patch or dead end? | Next move |
|---|---|---|---|
| Verification email to add the address never arrives | Forwarding loop or spam-filtered confirmation | Patch | Check spam and your forwarding rules; resend to an address that doesn't loop back into the same Gmail |
| SMTP auth error right after you enabled 2-step or rotated a password | Stale stored credential | Patch (if your host still issues app passwords) | Generate a fresh app password and re-enter it; if Gmail/your host no longer offers one, treat as dead end |
| Wrong SMTP host, port, or TLS/SSL setting | Configuration mismatch | Patch | Match host, submission port, and encryption to what your mail host specifies |
| Mail sends but is tagged "via gmail.com" or lands in spam | Alignment mismatch — your From domain and your auth domain differ by design | Dead end | No setting fixes this; the sending has to move to where From and auth share a domain |
Replies go out as @gmail.com instead of your address | Identity fallback, often because the feature was withdrawn | Dead end | Confirm the "Send mail as" entry still exists; if it's gone or won't apply, migrate |
| Adding a new custom address refuses to complete with clean settings | The side door closing on consumer accounts | Dead end | Stop retrying; stand up sending you own instead |
| You've fixed this exact break before, weeks ago | The approach, not the configuration | Dead end | Any recurring break is the clearest signal of all — migrate rather than re-patch |
Read the pattern down the "Patch or dead end" column: the patches are all one-off changes on your side — a stale password, a wrong port, a looped confirmation. The dead ends all share a different root: the From domain and the authenticating domain don't line up, or the feature itself is being withdrawn. No amount of re-entering a password changes either of those.
Here's how to spend the first five minutes. Reproduce the failure once and read what the error actually says — an SMTP auth rejection points you at the credential rows; a message that sends but lands wrong points you at the alignment row, which no login fix will touch. The goal of triage isn't to avoid ever patching — it's to stop you pouring an afternoon into a row the table already marks as a dead end.
Why the dead ends keep multiplying
"Send mail as" was always a bit of a kludge — a free consumer inbox borrowing an external SMTP server to send as an address it doesn't own. Two industry shifts turned that kludge brittle, and here it's worth being precise about what's actually been announced. Google has publicly deprecated the long-lived secrets this setup leaned on: app passwords, "less secure app" access, and basic username-and-password SMTP auth are all being retired. That part is confirmed, and it's why the credential patches above have a shelf life. The broader read — that consumer custom-domain "Send mail as" is being wound down altogether — is the widely expected direction those deprecations point, not a dated shutoff Google has published. Either way, when receivers now insist the From domain align with the authenticating domain (SPF, DKIM, DMARC), a Gmail-relayed custom send is a mismatch by design, which is the structural reason the spam-folder and "via gmail.com" dead ends don't yield to settings.
If you want to see that misalignment with your own eyes, open a message your "Send mail as" setup delivered and read its Authentication-Results header. A failing custom send looks like this:
Authentication-Results: mx.recipient.com; spf=pass smtp.mailfrom=yourname@gmail.com; dkim=pass header.d=gmail.com; dmarc=fail (p=REJECT) header.from=yourdomain.com
Every individual check "passes" — and DMARC still fails. SPF and DKIM both authenticate gmail.com, because Gmail's relay is what actually signed and sent the message, while the From address the recipient sees is yourdomain.com. DMARC's one job is to confirm those line up, and here they flatly don't: header.d=gmail.com against header.from=yourdomain.com is the misalignment, and no password you re-enter changes which domain did the signing. That single mismatch is why the alignment rows are dead ends — the only fix is for the signing domain and the From domain to be the same domain, which happens only when the sending lives on the domain itself.
Take a concrete case. You turned on two-step verification last month, your custom sends broke, you generated an app password, and it worked — for three weeks. Now it's failing again and a new app password doesn't stick. On the table, your first break was a genuine patch (stale credential), but the recurrence moved you into the bottom row. The credential isn't the disease; it's a symptom of the plumbing being withdrawn underneath you. That's the moment to stop patching and change approach.
Ending the cycle for good
Every dead end in the table traces to one root cause: your domain's mail goes out through an inbox you don't control, over a relay you don't own, with credentials someone else can deprecate. Change that root and the whole class of failures disappears — the From line is yours, the authentication aligns because the sending is yours, and there's no borrowed password left to go stale.
That's the model a clean migration moves you to, and Blue Folder Mail is one way to get there: a self-hosted, encrypted inbox that sends from your custom domains on your own Cloudflare account, with SPF and DKIM aligned so DMARC passes and the "via" tag is gone, and no per-domain fee to consolidate a messy pile of addresses. Mail is stored with zero-access encryption — a strong, specific protection, not a promise that anything is unhackable. The practical win is simpler than the privacy one: you stop troubleshooting a feature someone else is sunsetting.
- Why did my Gmail "Send mail as" suddenly stop working?
- Most often the SMTP credentials no longer authenticate — app passwords and legacy sign-in are being retired — or your mail now fails the alignment checks receivers require. Both reflect Gmail stepping back from custom-domain sending.
- Is there a setting that fixes "Send mail as" for good?
- You can patch individual failures, but there is no setting that stops the feature from being wound down. The durable fix is to send from your own domain on infrastructure you control.
- Why does my mail say "via gmail.com" or land in spam?
- Because the domain you send as does not align with the domain authenticating the message. Sending from an inbox you own, with SPF and DKIM for that domain, removes the mismatch.
- Do I have to pay per domain to fix this?
- Not with a self-hosted inbox. Blue Folder Mail runs on your own Cloudflare account with no per-domain fee, so you can consolidate every address into one inbox.