Solanasis Docs

solanasis_local_personalized_email_outreach_handoff_playbook_research_grade_2026-03-17

22 min read

Solanasis Local Personalized Email Outreach Playbook, Briefing Memo, and AI Handoff

Document date: 2026-03-17
Prepared for: Dmitri / Solanasis
Primary use: Guide, playbook, briefing memo, and handoff artifact for another AI
Scope: How to use eM Client + Google Workspace + Baserow to send personalized one-to-one emails at scale without turning the workflow into obvious bulk mail or relying on unsupported assumptions.

Executive Summary

The core conclusion from this discussion is straightforward:

  • [Verified] Sending through a local desktop client such as eM Client can support a more personal workflow, but it does not by itself improve deliverability or “beat spam filters.” Deliverability still depends heavily on domain authentication, sending behavior, recipient engagement, and account reputation. Google explicitly documents sending limits and sender authentication expectations.
    Sources: Google Workspace sending limits, Google sender guidelines, Google DKIM setup

  • [Verified] For a Windows + eM Client + Google Workspace setup, the strongest operational pattern is:
    Baserow as the CRM/source of personalization → local compose launch into eM Client → human review → send one recipient at a time.
    This is supported by eM Client’s documented startup parameters such as /mailurl and /newmail, Baserow’s formula/button support for mailto: links, and the mailto: standard itself.
    Sources: eM Client startup parameters, eM Client FAQ / startup parameters, Baserow formula guide, RFC 6068 mailto

  • [Verified] mailto: is appropriate for recipient + subject + plain-text body prefill, but it is not a robust standard for attachments, rich formatting, or complex compose-state control. RFC 6068 explicitly says creators of mailto: URIs cannot expect clients to understand more than subject and body.
    Source: RFC 6068

  • [Verified] eM Client has a legitimate Mass Mail feature with variables, but that feature is explicitly positioned by eM Client as a paid capability for sending individualized copies to multiple recipients. It is workable, but it moves the workflow closer to campaign tooling rather than “I personally wrote this to you.”
    Sources: eM Client Mass Mail FAQ, eM Client variables and mass mail, eM Client FAQ features

  • [Major recommendation] For the Solanasis launch, the best fit is not BCC blasting, not pretending bulk mail is manual, and not relying purely on one giant mailto: formula. The best fit is a reviewed one-to-one workflow where Baserow provides structure and personalization, and eM Client remains the actual human sending surface.

Purpose of This Document

This artifact is designed to let another AI continue the work without needing the original chat.

It does all of the following:

  • extracts the key goals, constraints, facts, and recommendations from the discussion
  • verifies major technical and operational claims against primary or high-quality sources where possible
  • labels important points by evidence status
  • flags earlier weak spots, overstatements, and uncertainties
  • converts the discussion into an actionable operational playbook
  • adds missing considerations that logically matter for implementation

Evidence Status Legend

Use these labels exactly as follows:

  • Verified — confirmed against a primary source or highly reliable reference
  • User-stated — stated by the user in this discussion; not independently verified here
  • Assistant-stated but unverified — proposed earlier by the assistant but not fully verified from authoritative sources
  • Tentative / speculative — inference, recommendation, or open possibility that should not be treated as established fact

Discussion Context

User goals and constraints

  • [User-stated] The user wants an easy way to send emails locally using eM Client with Google Workspace.
  • [User-stated] The emails should feel like they came directly from the user, not like obvious mass mail.
  • [User-stated] The workflow should work for specific people, especially friends / warm contacts around the Solanasis launch.
  • [User-stated] The emails need to be personalized, including the recipient’s name.
  • [User-stated] The source of contact data / personalization should come from the user’s CRM, currently Baserow.
  • [User-stated] The user specifically asked about possibilities such as:
    • popping up local compose windows
    • using mailto: / anchor-style links with prefilled content
    • sending at scale without it feeling like mass mail

Environment assumed in the earlier discussion

  • [Assistant-stated but mostly verified] Assumed operating environment: Windows desktop + eM Client + Google Workspace + Baserow.

Key Facts and Verified Findings

1) Google Workspace sending limits still apply even if mail is sent from eM Client

  • [Verified] Google Workspace documents that sending limits apply per user account, and exceeding them can suspend sending for up to 24 hours.
    Source: Google Workspace sending limits

  • [Verified] Google states these limits are applied over a rolling 24-hour period, not simply “per calendar day.”
    Source: Google Workspace sending limits

  • [Verified] Official documented limits relevant to this workflow include:

    • 2,000 maximum messages per day per paid user account
    • 500 maximum messages per day for trial accounts
    • 100 recipients per message when sent with SMTP by POP/IMAP users
    • 10,000 total recipients per day
    • 3,000 external recipients per day
    • 3,000 unique recipients per day (2,000 unique external; 500 external for trial accounts)
      Source: Google Workspace sending limits

Why it matters:

  • [Verified] Using eM Client does not exempt the mailbox from Google’s limits because the account is still ultimately sending through Google’s infrastructure.
    Source: Google Workspace sending limits

  • [Recommendation] For Solanasis warm launch outreach, this is less about hitting hard ceilings and more about avoiding behavior patterns that look abrupt, unnatural, or campaign-like.

2) Authentication matters more than “sending locally” for inbox placement

  • [Verified] Google’s sender guidance says messages must be authenticated by SPF or DKIM, and bulk senders must have SPF, DKIM, and DMARC.
    Sources: Google sender guidelines, Google DKIM setup

  • [Verified] Google says that for email sent to personal Gmail accounts, all senders must set up SPF or DKIM, while bulk senders (more than 5,000 messages/day) must also set up DMARC.
    Source: Google DKIM setup

  • [Verified] Google recommends using 2048-bit DKIM where the domain provider supports it.
    Source: Google sender guidelines

  • [Verified] Google notes that outbound gateways or systems that modify outgoing mail can interfere with DKIM.
    Source: Google DKIM setup

Why it matters:

  • [Verified] The earlier discussion was directionally right that local sending can feel more human, but it was too loose if interpreted as “local sending improves spam placement.” Authentication and domain health are far more foundational.

3) Google Workspace third-party clients now need OAuth, not legacy password auth

  • [Verified] Google says that starting March 14, 2025, users must use OAuth with third-party apps to access Gmail, Google Calendar, and Google Contacts; basic username/password access for less secure apps was turned off.
    Source: Google transition from less secure apps to OAuth

  • [Verified] eM Client states that Google OAuth login is used by default when setting up a Gmail / Google Workspace account, and that users should not need “less secure apps” enabled.
    Source: eM Client on Google less secure apps

  • [Verified] eM Client’s Google Workspace setup flow explicitly says the user will see an OAuth authentication step in a browser window.
    Source: eM Client with Google Workspace

Why it matters:

  • [Recommendation] Another AI should verify that the user’s existing eM Client Google Workspace account is using OAuth, not an old or imported legacy setup.

4) eM Client officially supports startup parameters that can drive a local compose workflow

Why it matters:

  • [Verified] This makes a local scripted workflow technically credible.
  • [Recommendation] This is a stronger foundation than trying to do everything inside Baserow formulas alone.

  • [Verified] Baserow’s formula docs explicitly show:

    • button('https://example.com/' + [ID], 'View Details')
    • link('mailto:' + [Email])
      Source: Baserow formula guide

  • [Verified] Baserow docs show that formula logic is available for creating interactive buttons and links.
    Source: Baserow formula guide

  • [Verified] Baserow supports database tokens (same concept also described as personal API tokens in the docs) that are scoped to a single workspace and can be permission-limited.
    Source: Baserow database tokens

  • [Verified] Baserow supports exporting a grid view through the UI in formats including CSV, JSON, or XML.
    Source: Baserow view customization

  • [Verified] Baserow table/view export is a real feature documented in Baserow’s user docs.
    Sources: Baserow view customization, Baserow customize a table

Important correction:

  • [Verified correction] An earlier artifact stated or implied broader export support that included Excel. That was not verified from the sources reviewed here and should not be treated as established based on this discussion. Verified official docs reviewed here support CSV/JSON/XML export claims, not a general Excel-export claim.

6) mailto: is useful but intentionally limited

  • [Verified] RFC 6068 defines mailto: using addr-spec syntax for recipients.
    Source: RFC 6068

  • [Verified] The RFC says the body pseudo-header is intended for the first text/plain body part.
    Source: RFC 6068

  • [Verified] The RFC says creators of mailto: URIs cannot expect clients to understand more than subject and body.
    Source: RFC 6068

  • [Verified] The RFC says line breaks in the body should be encoded as %0D%0A.
    Source: RFC 6068

  • [Verified] The RFC warns that client behavior varies for multiple header fields and that not all header values are safe or consistently handled.
    Source: RFC 6068

Why it matters:

  • [Verified] mailto: is a good mechanism for opening a draft with basic prefill.
  • [Verified] mailto: is not a standards-based way to reliably handle attachments or complex formatting.
  • [Recommendation] For anything beyond simple recipient/subject/body prefill, a local launcher script is cleaner.

7) eM Client Mass Mail is real, but it changes the mode of operation

Interpretation:

  • [Tentative / strategic recommendation] Mass Mail may still be useful later for certain follow-ups or controlled partner outreach, but for the Solanasis launch to warm personal contacts, it is probably not the first-choice workflow if the goal is maximum personal feel.

8) Baserow-only prefilled mailto: formulas may work, but there are community-reported quirks

Interpretation:

  • [Recommendation] Complex all-in-Baserow mailto: formulas should be treated as test-required, not assumed production-safe.
  • [Recommendation] This is one reason the Baserow → local script → eM Client approach is stronger operationally.

Major Decisions and Conclusions

Decision 1: Do not frame this as “how to trick spam filters”

  • [Verified] The earlier discussion needed tightening here. Local sending is not a deliverability hack. Authentication and sending behavior matter more.
    Sources: Google sender guidelines, Google DKIM setup
  • [Recommendation] If the user wants the outreach to feel like it truly came from Dmitri, the workflow should create one draft per person and keep the user as the final sender.

Decision 3: Use Baserow as the source of truth for contact data and personalization

Decision 4: Prefer a local launcher script over overcomplicated Baserow formulas

  • [Verified + recommendation] Because eM Client officially supports /mailurl and /newmail, and because mailto: is simple but limited, the strongest implementation is a small local script that reads Baserow data and opens personalized drafts in eM Client.
    Sources: eM Client startup parameters, RFC 6068

Decision 5: Confirm OAuth and domain authentication before scaling any outreach

Reasoning, Tradeoffs, and Why It Matters

Why not just use eM Client Mass Mail?

  • Pros

    • [Verified] It is a real feature.
    • [Verified] It supports variables and sends individualized copies.
    • [Verified] It avoids exposing recipients in BCC/CC.

  • Cons

    • [Verified] It is explicitly a mass-mail feature, not just a draft-launch mechanism.
    • [Recommendation] It can push the user into campaign thinking and more templated writing.
    • [Recommendation] For warm launch outreach, this may subtly degrade authenticity.

Why not do everything with mailto: inside Baserow?

  • Pros

    • [Verified] Officially supported at least for recipient/email link behavior.
    • [Recommendation] Very low setup friction for small-scale use.

  • Cons

    • [Verified] Standards support is narrow: subject/body are the only fields you can reliably count on.
    • [Verified from community] Complex encoding/button logic may require testing and can be brittle.
    • [Recommendation] Harder to maintain if the message body gets longer or more dynamic.

Why the local launcher approach is strongest

  • Pros

    • [Verified] Supported by eM Client command-line startup behavior.
    • [Recommendation] Keeps CRM logic separate from email client behavior.
    • [Recommendation] Easier to log, pause, review, and control.
    • [Recommendation] Gives the user a human-in-the-loop checkpoint before every send.

  • Cons

    • [Tentative] Requires a little setup and local scripting.
    • [Tentative] May need path and encoding testing on the user’s machine.

Recommended Playbook / Process

Phase 1: Validate the sending foundation

1. Confirm the Google Workspace account is set up in eM Client using OAuth

Practical check:

  • [Verified from eM Client guidance] If the account was set up with direct username/password fields rather than OAuth token flow, it may be an older / less secure style setup that should be recreated.
    Source: eM Client on Google less secure apps

2. Confirm domain authentication

  • [Recommendation] Before sending launch outreach at any meaningful scale, verify:

    • SPF present and correct
    • DKIM enabled and signing
    • DMARC published

  • [Verified] Google recommends SPF and DMARC alongside DKIM, and all senders to Gmail need SPF or DKIM.
    Sources: Google sender guidelines, Google DKIM setup

3. Avoid outbound modifications that can break DKIM

  • [Verified] If there is any outbound gateway or footer-injection system in play, confirm it is not invalidating DKIM.
    Source: Google DKIM setup

Phase 2: Build the CRM structure in Baserow

Core fields

  • [Recommendation] Full Name
  • [Recommendation] First Name
  • [Recommendation] Email
  • [Recommendation] Relationship Type
  • [Recommendation] Organization
  • [Recommendation] Why They Came to Mind
  • [Recommendation] Suggested Ask
  • [Recommendation] Personalized Opening
  • [Recommendation] Subject Draft
  • [Recommendation] Body Draft
  • [Recommendation] Status
  • [Recommendation] Last Sent
  • [Recommendation] Reply Outcome
  • [Recommendation] Notes

Useful helper fields

  • [Recommendation] Greeting Name
  • [Recommendation] Send Link (simple)
  • [Recommendation] Ready To Send?
  • [Recommendation] Priority

Simple Baserow formula examples

  • [Verified pattern]
link('mailto:' + [Email])

Source: Baserow formula guide

Button-style external action

  • [Verified pattern]
button('https://example.com/' + [ID], 'View Details')

Source: Baserow formula guide

Prefilled mailto: example

  • [Tentative / must test locally]
button(
  'mailto:' + [Email] +
  '?subject=' + encode_uri([Subject Draft]) +
  '&body=' + encode_uri([Body Draft]),
  'Open Draft'
)

Caution:

  • This is a logical extension of verified Baserow and RFC behaviors, but it should be treated as test-required, not assumed flawless, due to community-reported quirks with encode_uri(...) and complex mailto formulas.
    Sources: RFC 6068, Baserow community mailto issue thread

Phase 3: Choose the actual sending workflow

Workflow A — lowest friction

Baserow row → click mailto: link → eM Client opens → user reviews and sends

Use when:

  • the list is modest
  • setup time must stay minimal
  • simple subject/body prefill is enough

Workflow B — recommended operator workflow

Baserow export or API → local script → eM Client /mailurl → user reviews and sends

Use when:

  • the message body is more complex
  • the user wants better control over encoding
  • the user wants repeatable throughput without becoming a campaign tool

Why Workflow B is preferred

Phase 4: Content rules for warm Solanasis launch outreach

Message construction guidance

  • [Recommendation] Keep each email to one recipient.
  • [Recommendation] Use plain text or very light formatting.
  • [Recommendation] Use the person’s name naturally, not mechanically.
  • [Recommendation] Include a real reason they came to mind.
  • [Recommendation] Use one clear ask.
  • [Recommendation] Avoid newsletter energy.
  • [Recommendation] Avoid sending large groups the exact same first line.

Suggested structure

  • [Recommendation] Line 1: warm personal opener
  • [Recommendation] Line 2: short Solanasis launch context
  • [Recommendation] Line 3: why this specific person came to mind
  • [Recommendation] Line 4: a simple ask (feedback, intro, connection, catch-up)
  • [Recommendation] Line 5: clean signoff

Subject line guidance

  • [Recommendation] Favor casual warm subjects over campaign subjects.
  • Examples:
    • Quick favor
    • You came to mind
    • Wanted to share what I’m building
    • Would love your take

Phase 5: Send in sane batches

  • [Recommendation] Start with a very small batch first.
  • [Recommendation] Send to seed contacts likely to reply positively.
  • [Recommendation] Watch reply rate, spam placement, and bounce behavior.
  • [Recommendation] Do not send all launch outreach in one burst if the domain/mailbox is newly ramping.

Example Implementation Notes

Example local PowerShell pattern

Status: Assistant-authored example based on verified eM Client startup support

$csvPath = "C:\temp\solanasis_launch.csv"
$emClient = "${env:ProgramFiles(x86)}\eM Client\MailClient.exe"
if (-not (Test-Path $emClient)) {
    $emClient = "${env:ProgramFiles}\eM Client\MailClient.exe"
}
 
$rows = Import-Csv $csvPath
 
foreach ($row in $rows) {
    $subject = $row.SubjectDraft
    $body = $row.BodyDraft
 
    $mailto = "mailto:{0}?subject={1}&body={2}" -f `
        $row.Email, `
        [uri]::EscapeDataString($subject), `
        [uri]::EscapeDataString($body)
 
    Start-Process -FilePath $emClient -ArgumentList "/mailurl `"$mailto`""
 
    Read-Host "Press Enter to open the next draft"
}

Why this example is reasonable

  • [Verified] /mailurl is an official eM Client startup parameter.
  • [Verified] RFC 6068 requires proper percent-encoding for content in mailto URIs.
  • [Recommendation] Using a local script reduces the formula/encoding burden inside Baserow.

What still must be tested locally

  • [Tentative] Exact install path for MailClient.exe
  • [Tentative] Message length tolerances in the user’s actual Windows/browser/client flow
  • [Tentative] Whether the user prefers CSV export vs Baserow API token pull

Primary / official sources

  1. Google Workspace sending limits
    https://knowledge.workspace.google.com/admin/gmail/gmail-sending-limits-in-google-workspace

  2. Google sender guidelines
    https://support.google.com/a/answer/81126?hl=en

  3. Google DKIM setup / authentication guidance
    https://knowledge.workspace.google.com/admin/security/set-up-dkim

  4. Google transition from less secure apps to OAuth
    https://knowledge.workspace.google.com/admin/sync/transition-from-less-secure-apps-to-oauth

  5. eM Client with Google Workspace
    https://www.emclient.com/em-with-google-workspace

  6. eM Client: Google less secure apps / OAuth guidance
    https://www.emclient.com/blog/google—less-secure-apps—access-and-what-it-means-for-em-client-489

  7. eM Client startup parameters documentation
    https://www.emclient.com/documentation/technologies-advanced/startup-parameters

  8. eM Client startup parameters FAQ
    https://www.emclient.com/faq-em-client-features

  9. eM Client variables and mass mail
    https://www.emclient.com/variables-and-mass-mail

  10. eM Client FAQ getting started / mass mail
    https://www.emclient.com/faq-getting-started

  11. Baserow formula field reference
    https://baserow.io/user-docs/understanding-formulas

  12. Baserow database tokens
    https://baserow.io/user-docs/personal-api-tokens

  13. Baserow view customization / export a view
    https://baserow.io/user-docs/view-customization

  14. Baserow table customization / export tables
    https://baserow.io/user-docs/customize-a-table

  15. RFC 6068: mailto URI scheme
    https://www.rfc-editor.org/rfc/rfc6068

Secondary / community / user-reported sources

  1. Baserow community: mailto formula/button issues
    https://community.baserow.io/t/issues-with-formula-for-creating-mailto-links-or-buttons/5678

  2. Baserow community: encode_uri usage for button URLs
    https://community.baserow.io/t/challenge-with-implementing-dynamic-buttons-using-concatenation-in-formulas/4794

  3. eM Client community: setting eM Client as MAILTO default on Windows
    https://forum.emclient.com/t/create-a-new-email-whan-clicking-on-a-mailto-link/85874

Risks, Caveats, and Red Flags

Deliverability risks

Workflow risks

  • [Verified] mailto: has limited interoperability expectations.
  • [Verified] Body content must be encoded correctly.
  • [Verified from community] Complex Baserow formulas may need debugging.

Messaging risks

  • [Recommendation] If the same message is sent to many contacts with only the first name changed, recipients may still perceive it as bulk mail.

Compliance / policy boundary

  • [Tentative / prudent business note] If the user later expands from warm/friend outreach into broader promotional outreach, another AI should flag that legal/compliance rules may become more relevant and should not be hand-waved. This artifact does not provide legal advice.

Product/version risks

  • [Tentative] eM Client feature packaging can change over time. Mass Mail being paid is verified; other feature availability should be confirmed against the current license if implementation depends on them.

Open Questions / What Still Needs Verification

  1. Does the user’s current Solanasis / Google Workspace domain already have SPF, DKIM, and DMARC fully working?

    • Status: Not verified in this discussion.

  2. Is the user’s current eM Client account connected via OAuth or via an older/imported authentication setup?

    • Status: Not verified locally.

  3. Does the user want a Baserow-only click flow, or is a local PowerShell/Python script acceptable?

    • Status: Not finalized.

  4. What exact segmentation exists in Baserow now?

    • Friends / family / former clients / peers / referral partners / prospective partners may need different message variants.
    • Status: Not yet mapped.

  5. What is the current install path and version of eM Client on the user’s machine?

    • Status: Not verified.

  6. How long are the planned messages?

    • Longer bodies make pure mailto: more fragile and push the recommendation further toward the local launcher approach.
    • Status: Not finalized.

  7. Does the user want tracking or reply-state sync back into Baserow?

    • Status: Not discussed in depth.

  8. Should launch outreach be limited to true warm contacts first?

    • Status: Strategically recommended, but the exact audience boundary was not finalized.

Suggested Next Steps

Immediate next steps

  1. Verify Google Workspace authentication posture

    • SPF
    • DKIM
    • DMARC

  2. Verify eM Client Google Workspace account auth mode

    • confirm OAuth-based setup

  3. Set / confirm eM Client as the Windows MAILTO handler

    • community guidance exists; should be confirmed on the user’s actual device

  4. Create the Baserow launch-outreach table

    • include status and personalization fields

  5. Pilot with a 3-person test batch

    • one Gmail recipient
    • one Outlook recipient
    • one close contact likely to reply

  6. Decide implementation path

    • Baserow-only mailto: click flow
    • or Baserow export/API + local launcher script

Best next artifact to produce

  • [Recommendation] A separate implementation package with:
    • Baserow field schema
    • Baserow formula set
    • sample CSV template
    • working PowerShell script
    • short SOP for send-review-log workflow

Handoff Notes for Another AI

Another AI picking this up should assume the following:

What is already settled

  • The user wants a local, personal-feeling outreach workflow.
  • The stack is eM Client + Google Workspace + Baserow.
  • The use case is Solanasis launch outreach to warm contacts / friends / specific people.
  • The strategic recommendation is one draft per person, reviewed by the user before sending.
  • The strongest technical implementation is likely Baserow → local script → eM Client compose window.

What should not be reintroduced carelessly

  • Do not reframe this as “how to bypass spam filters.”
  • Do not assume Baserow complex mailto: formulas are flawless.
  • Do not assume that sending through a desktop client changes Google’s underlying limits.
  • Do not assume the user’s Workspace auth, DKIM, or DMARC are already configured correctly.

What another AI should do next if continuing

  1. Ask for or inspect the current Baserow schema.
  2. Produce a clean Baserow table design for launch outreach.
  3. Produce a tested PowerShell script and CSV template.
  4. Optionally produce 2–3 outreach message variants by relationship type:
    • friend / peer
    • former client / professional contact
    • referral partner / connector
  5. Add a logging method for:
    • sent date
    • reply status
    • follow-up needed

Decision logic to preserve

  • If the user wants minimum setup, recommend simple Baserow mailto: links.
  • If the user wants best workflow quality, recommend local launcher script + eM Client review.
  • If the user wants campaign throughput, evaluate eM Client Mass Mail — but flag that it shifts the feel toward a campaign tool.

Reviewer Notes and Improvements Made

Reviewer mode used: serious self-review pass (no separate reviewer agent available in this environment)

Problems in the earlier state of the discussion that were improved here

  1. Overstated implication that local sending might help avoid spam filtering

    • Fixed by grounding deliverability claims in Google’s actual authentication and sending-limit documentation.

  2. Insufficient distinction between “personal feel” and “technical deliverability”

    • Fixed by separating those two concerns explicitly.

  3. Overconfidence around Baserow + complex mailto formula flows

    • Fixed by limiting verified claims to official Baserow docs and moving formula quirks into a clearly labeled community-reported section.

  4. Unverified export-format claim

    • Fixed by correcting earlier overreach and only asserting export behavior supported by the sources reviewed here.

  5. Missing OAuth transition context

    • Fixed by adding Google’s 2025 OAuth requirement and eM Client’s Google Workspace OAuth setup guidance.

  6. Missing operational next steps

    • Fixed by turning the discussion into phased implementation guidance and a handoff-ready checklist.

Confidence assessment

  • High confidence in the core conclusion that the best workflow is Baserow-driven personalization + local eM Client compose review + one-to-one sending.
  • Medium confidence in Baserow-only advanced formula workflows, because official support is partial and community reports show quirks.
  • High confidence that any scaled or repeated outreach should first verify OAuth + SPF/DKIM/DMARC.

Optional Appendix: Structured Summary

project:
  name: Solanasis launch outreach workflow
  objective: Send personalized launch emails from a real local mailbox workflow without obvious bulk-mail feel
 
user_stack:
  crm: Baserow
  mail_client: eM Client
  mailbox_provider: Google Workspace
  assumed_os: Windows
 
core_conclusion:
  recommended_workflow: "Baserow -> local draft launch -> eM Client compose review -> send one recipient at a time"
  not_recommended_as_primary: "BCC blast behavior"
  optional_secondary_path: "eM Client Mass Mail for some future cases"
 
verified_facts:
  - Google Workspace sending limits apply even when sending through a desktop client
  - Google requires SPF or DKIM for all senders to Gmail, and SPF+DKIM+DMARC for bulk senders
  - Google requires OAuth with third-party apps after 2025-03-14 for managed accounts
  - eM Client supports /mailurl and /newmail startup parameters on Windows
  - Baserow supports formula links/buttons including simple mailto links
  - RFC 6068 only reliably supports subject and body in mailto URIs
 
open_questions:
  - Is the current Workspace domain auth fully configured?
  - Is the current eM Client account OAuth-based?
  - Does the user want Baserow-only links or a local script?
  - What audience segments need separate message variants?
 
next_best_artifact:
  - Baserow schema
  - formula pack
  - CSV template
  - tested PowerShell launcher
  - outreach SOP

Graph View