Solanasis Docs

solanasis_google_workspace_trulyinbox_playbook

8 min read

Solanasis Playbook: Google Workspace + TrulyInbox + Deliverability Monitoring (2026)

Purpose

This document is a practical handoff for another AI or operator. It captures the key findings from testing and research around:

  • connecting TrulyInbox to a Google Workspace mailbox,
  • handling Google Workspace third-party app access,
  • understanding when Trusted appears to be required in practice,
  • and building an AI-native deliverability monitoring stack for Solanasis and future clients.

Executive summary

Key conclusion

For this specific Google Workspace + TrulyInbox setup, the OAuth connection did not work under narrower third-party app access modes. Even after trying more scoped options, the flow produced:

“This app is blocked. This app tried to access sensitive info in your Google Account. To keep your account safe, Google blocked this access.”

Operational note for this tenant

In this real-world test, the app would not work unless the TrulyInbox app was set to Trusted in Google Workspace Admin.

That is the key operational takeaway.

Important nuance

Treat that as a tested practical outcome for this tenant / app flow, not as a universal rule for every Google Workspace app.

In theory, Google Workspace supports narrower policies such as:

  • Specific Google data
  • Limited
  • Trusted

And, in theory, Specific Google data is the more security-tight least-privilege option.

But in this case, the narrower options did not allow the TrulyInbox OAuth connection to succeed.

So the practical handoff guidance is:

If TrulyInbox OAuth keeps failing with the Google “This app is blocked” message, the working fix in this tenant was to set the app to Trusted.

What was verified about TrulyInbox

Product / pricing

TrulyInbox currently presents itself as a dedicated email warmup platform and currently advertises:

  • a Free Forever plan,
  • 1 account on free,
  • 10 warmup emails/day on free,
  • and paid tiers starting at $29/month monthly, with lower effective monthly cost on annual billing.

It also presents connection methods that include:

  • Google OAuth
  • SMTP / IMAP

Practical interpretation

This means TrulyInbox is not just a browser extension sitting inside Gmail UI. It behaves more like a standalone service that connects to the mailbox.

That distinction matters operationally, but it does not mean Google officially approves automated warmup as a concept.

The Google Workspace policy issue

Intended least-privilege setup

The initial security-leaning approach was:

  • choose Specific Google data,
  • allow only Gmail-related access,
  • keep scopes narrow,
  • avoid broad trust if possible.

That is the right instinct from a security perspective.

What happened in practice

Even after trying the narrower access mode(s), the OAuth flow resulted in:

This app is blocked

This strongly suggests one of the following happened:

  1. TrulyInbox requested Gmail scopes that were still not sufficiently allowed under the scoped config.
  2. The app requested sign-in and/or sensitive Gmail scopes that triggered Google’s blocking behavior.
  3. Google treated the app/scopes combination as too sensitive for the narrower access mode in this tenant.
  4. The narrower mode may be theoretically correct but still not practically usable for this app.

Practical tested conclusion

For this tenant and this app flow, Trusted was required to get past the block.

What to tell another AI

Use this exact practical instruction:

When connecting TrulyInbox to this Google Workspace environment via OAuth, the narrower Google Admin third-party app access settings did not work. The app only functioned once it was marked as Trusted in Google Workspace Admin.

Also tell it this:

Do not over-argue least privilege here if the business goal is simply to get the dedicated outreach inbox working. In this case, the practical workaround that actually resolved the issue was using Trusted.

Because Trusted is broader than ideal, contain the blast radius.

Best-practice containment steps

  1. Use a dedicated outreach mailbox only

    • Example: ds@solanasishq.com
    • Do not use a primary executive/admin mailbox for this.

  2. Keep this mailbox in a dedicated OU or policy segment if possible

    • That way the broader app trust decision applies only where needed.

  3. Do not reuse this mailbox for sensitive internal operations

    • Keep it for outbound relationship-building / outreach only.

  4. Enable strong account security

    • 2-Step Verification
    • strong unique password
    • recovery options locked down

  5. Review connected apps periodically

    • Make sure TrulyInbox is the expected integration.

  6. Avoid adding unnecessary Google services to the workflow

    • Even if the app is trusted, keep the operational role of the mailbox narrow.

Internal policy language

Use this framing:

We are accepting a broader app trust posture only for a low-sensitivity dedicated outreach mailbox because narrower controls failed in practice.

Best practical setup

  • Mailbox: dedicated outreach mailbox
  • Platform: Google Workspace
  • Connection method: Google OAuth
  • Google Admin third-party access: Trusted for this app in this tenant, because narrower modes failed
  • Warmup level: start conservative
  • Real send volume: also start conservative

How to start

  1. Connect the dedicated outreach mailbox.
  2. Use OAuth.
  3. If blocked under scoped access, set TrulyInbox app to Trusted.
  4. Confirm the connection succeeds.
  5. Start with the smallest reasonable warmup footprint.
  6. Layer in real, low-volume, highly personalized outreach.

What not to do

  • Do not assume warmup alone makes outreach safe.
  • Do not ramp real sends too aggressively.
  • Do not treat a warmup tool as a substitute for domain authentication and complaint monitoring.

Deliverability monitoring stack for an AI-native agency

The core idea is to build a repeatable stack that Solanasis can run internally and eventually offer to clients.

Best free / low-cost official signal layer

1. Google Postmaster Tools

Use for:

  • Gmail spam rate
  • domain reputation
  • authentication health
  • delivery errors

Best for domains that have enough Gmail volume to surface data.

2. Microsoft SNDS / JMRP

Use for:

  • Outlook/Hotmail reputation signals
  • complaint reporting

3. Yahoo Complaint Feedback Loop

Use for:

  • Yahoo/AOL complaint feedback
  • spam complaint reporting flows

4. DNS / auth checks

Automate checks for:

  • SPF
  • DKIM
  • DMARC
  • MX
  • general DNS sanity

Optional paid layer for agency scale

If Solanasis wants a more agency/MSP-ready monitoring layer, consider platforms in categories like:

  • DMARC multi-tenant platforms
  • inbox placement testing platforms
  • deliverability reporting tools with APIs or multi-client dashboards

The value is not that one account magically scans everyone. The value is that each client is onboarded into your monitoring stack, and then your AI agents monitor all of them centrally.

Important commercial model clarification

Wrong model

“We can buy one account and scan any client we want.”

That is generally not the right mental model.

Right model

“We onboard each client’s domain/mail stream into our monitoring stack, obtain access/verification/forwarding where needed, and then our AI agents monitor all clients from one operational center.”

That model is legitimate and scalable.

What Claude Code or other AI agents should automate

Daily / scheduled checks

  1. Pull Google Postmaster metrics where available.
  2. Parse complaint emails from Yahoo / Microsoft flows.
  3. Run DNS checks for SPF / DKIM / DMARC / MX.
  4. Flag missing or broken auth.
  5. Trend complaint spikes.
  6. Flag potential reputation degradation.
  7. Generate weekly client-facing summaries.

Example outputs for clients

  • Authentication status summary
  • Deliverability risk summary
  • Complaint trend summary
  • Recommended remediations
  • Warmup / sending ramp recommendations
  • “Do not send yet” warnings for broken setups

Suggested Solanasis service packaging

Internal use first

Use the stack for Solanasis outbound and internal testing.

Then offer as service

Offer a lightweight managed service such as:

  • Email Deliverability Baseline Audit
  • Google Workspace / Microsoft 365 Auth Hardening
  • DMARC / SPF / DKIM Remediation
  • AI-Monitored Deliverability Watch
  • Weekly Deliverability Reports
  • Outreach Mailbox Safety Setup

Final handoff guidance

What another AI should remember most

  1. TrulyInbox may fail under scoped Google Workspace app-access modes even when the configuration seems reasonable.
  2. In this tested environment, the OAuth connection only worked after setting the app to Trusted.
  3. Once using Trusted, reduce risk by isolating the mailbox and keeping it dedicated to outreach.
  4. Warmup is not enough. Real deliverability hygiene still requires authentication, complaint monitoring, and conservative sending behavior.
  5. For agency scale, think multi-client onboarding into a monitoring stack, not generic scanning without access.

Use this wording internally:

We attempted to connect TrulyInbox to our Google Workspace outreach mailbox using narrower third-party app access settings such as scoped Google data access. The OAuth flow kept failing with Google’s “This app is blocked” message. In our environment, the connection only worked once the app was marked as Trusted. Therefore, for this mailbox/app combination, Trusted is the required practical setting. Because Trusted is broader than ideal, the mailbox should remain a dedicated outreach-only account with limited business sensitivity.

Bottom line

Practical answer

For this Solanasis setup:

  • Yes, use TrulyInbox if desired as a helper.
  • Yes, use a dedicated outreach inbox.
  • Yes, use Google OAuth if possible.
  • And yes, based on actual testing, the app needed to be set to Trusted in Google Workspace Admin to work.

That is the operational conclusion to carry forward.

Graph View