Google is retiring one of Gmail’s oldest conveniences: the ability to send mail from a non-Google address directly through the Gmail interface. If you use Gmail to send “from” your own domain, that setup has an expiry date.
What is changing
Gmail’s “Send as” feature lets you compose a message and have it appear to come from a third-party address — for example, sending from your own-domain email while still using Gmail’s familiar inbox. Google has announced it is ending support for this feature for external, non-Google accounts.
The rollout is staged:
- New “Send as” configurations for third-party addresses are already being restricted on the web.
- Existing configurations keep working during a transition period.
- The feature is removed completely in January 2027. After that point, per Google’s own support page, you will no longer be able to send mail from a third-party account in Gmail on the web or in the mobile apps.
Google’s stated reason is “disproportionate maintenance resources.”
A related feature, Gmailify — which extended Gmail’s spam filtering and inbox organisation to third-party accounts — is also being discontinued in January 2027.
Sending from your own domain is what breaks
The core of this change is about sending mail from an address you don’t
actually host with Google. If your business or personal identity is tied to a
custom domain — you@yourdomain.com — and you’ve been routing its outgoing mail
through Gmail’s “Send as,” that path closes in January 2027.
What stays:
- Reading third-party mail inside Gmail (via Mail Fetcher, POP3/IMAP).
- Forwarding from a third-party account to Gmail.
What goes:
- Sending from that third-party address through Gmail’s own interface.
So the loss is specific but real: anyone who centralised their inbox in Gmail while presenting a domain they own to the world loses the ability to send from that domain without leaving Gmail.
What sending from your own domain actually requires
To send mail from you@yourdomain.com, the address needs a mail server that
accepts your outgoing messages and signs them for your domain. The three paths:
Use Gmail as before. Works only for Google-hosted addresses. For a custom domain that means paying for Google Workspace, where Google hosts the domain’s mail. You keep one interface, but Google remains the server and the domain’s mail flows through it.
A dedicated provider with a custom domain. Proton, Fastmail, and others host your domain’s mail and let you send from it. You keep a clean interface and your own address, on a server someone else runs.
Your own mail server. You host the domain yourself. The server accepts your outgoing mail, DKIM-signs it, and you control it entirely. This is what cripta.to sets up: a mail server on infrastructure you control, with your domain, DNS records (SPF, DKIM, DMARC), and TLS handled for you.
The first option keeps you on Google. The second changes which provider holds your mail. The third removes the third party from the sending path entirely.
The trade-off, plainly
Sending from a custom domain is not something you can bolt onto a free consumer account forever. Google’s change makes that explicit. What you’re really deciding is where your domain’s mail lives:
- Convenience — Gmail/Workspace: one interface, but Google runs the server and sets the terms.
- Independence — your own server: you own the address and the path it takes, at the cost of some setup, which cripta.to automates.
If you depend on a custom domain, the question isn’t whether to move off the “Send as” workaround — that’s decided for you. It’s where to move.