I subscribe to a small number of newsletters that consistently break industry news first. Instead of opening every one of them by hand, I connect my inbox to an AI tool with read-only access, scoped so it can only view and summarize, never send, delete, or change anything. It scans just those subscriptions and tells me what changed in my industry, and the industries of the clients I work with.
Every video in my "30 Hacks From Dahlia" series ends with the same line, and this one is the reason I keep saying it: I help small teams do big things, and most of what that actually looks like is quietly automating the parts of the day that don't need me personally. This hack is the one people ask about most once they see it, because it touches something everyone hesitates over: connecting an AI tool to your actual email inbox.
Watch: Hack 31, the tool that reads my newsletters for me
Why I built this in the first place
As a small business owner, staying on top of every trend, hack, and tip in my industry is part of the job. I don't chase all of it. I subscribe to the handful of newsletters I already trust, the ones that consistently bring the news first and give genuinely valuable content instead of recycled takes. That part hasn't changed in years.
What changed is what happens after I subscribe. I used to open each one manually, skim for anything that mattered, and half the time forget I'd read it by the following week. Now I have a tool set up that goes through my email, finds those specific newsletter subscriptions, reads through them, and summarizes what's in them, so I know the latest trends or changes that happened in my industry, or in the industries of the clients I work with, without opening a single one by hand.
The part everyone asks about: connecting your email safely
The question I get every time I mention this is some version of "wait, you gave an AI access to your email?" Not exactly. I gave it read-only access, which is a specific, narrower permission than the one people picture. It is worth understanding the difference, because it's the whole reason I'm comfortable running this unattended.
On Gmail
Gmail's API offers separate, named permission scopes for different levels of access. The one I use is called gmail.readonly. It lets a connected tool view and read messages, and nothing else. It does not include the scopes needed to send mail, delete mail, or modify labels and folders. When you authorize a connector through Google's OAuth screen, it shows you in plain language exactly what you're granting, something like "Read all resources and their metadata," never "Send email as you," unless you've separately approved that broader permission.
On Outlook or Microsoft 365
Microsoft's equivalent lives in the Graph API permission model. The scope is called Mail.Read, and it is deliberately kept apart from Mail.ReadWrite and Mail.Send. If a tool only requests Mail.Read, it is structurally unable to send or modify a message, the same way a read-only database credential cannot run a delete statement no matter what query you send it.
The comfort here doesn't come from trusting the tool to behave. It comes from the permission itself being incapable of the risky action. A connector authorized only for gmail.readonly or Mail.Read cannot send an email or delete one, regardless of what it's instructed to do. That's the property that makes it safe to leave running in the background.
I didn't need the AI to trust me. I needed the permission to make trust unnecessary.
What the digest actually looks like
I'm not opening a dashboard for this. The tool connects through MCP, the same open protocol I use to link most of the AI systems I run, scoped to only the newsletter senders I've chosen. It reads through what came in, pulls out what's actually new or changed, and hands me a plain summary of the trends and shifts worth knowing about, in my industry and in the industries of the clients I work with. If nothing meaningful changed that week, there's nothing to read. That's the whole point: I only spend time on the signal, never the scanning.
Before you connect anything to your inbox
One hack, out of thirty
This is hack 31 in a series I never expected to keep going past thirty, because there's always one more piece of the day quietly worth automating. Full step-by-step guide and the rest of the series are linked in my bio. If you run more than one inbox for your business or your clients, the pattern here scales the same way: connect only what you need, only with the access level that matches the job, and let the summary come to you instead of you going to look for it.
Frequently Asked Questions
Read-only access means the connection is scoped so the tool can only view and read your inbox. It cannot send, delete, forward, or modify anything. On Gmail this is the gmail.readonly OAuth scope; on Microsoft 365 it is the Mail.Read Graph API permission. Both are separate, narrower permissions than the ones needed to send or manage mail, and neither one grants that access.
It is safe when the connection is explicitly scoped to read-only and limited to what you actually need it to see. The safety comes from the permission itself, not a promise: a tool authorized only for gmail.readonly or Mail.Read is structurally incapable of sending or deleting anything, regardless of what it is instructed to do. Always check the exact scope you are granting before authorizing any connector.
Check the OAuth consent screen when you authorize the connection. Google and Microsoft both display exactly which permission is being granted in plain language, such as "Read all resources and events on your calendar" versus "Send email as you." If the consent screen only mentions reading or viewing, the send and delete actions are not available to the tool no matter what it is asked to do.
Start small. Pick the three to five newsletters you already trust to break industry news first, the ones you would actually stop and read if you saw them. A tool that summarizes a handful of high-signal sources is more useful than one drowning in every subscription you have ever signed up for.
Sources
