Solanasis Docs

zoho-mail-domain-transition-brevo-emclient-research-grade-handoff-2026-03-25

26 min read

Zoho Mail + New Domain + Brevo + eM Client Transition Playbook and Handoff Memo — 2026-03-25

Executive Summary

This document extracts, organizes, verifies, and improves the key points from the discussion about moving an existing paid Zoho mailbox from dmitri@zasage.me to dmitri@mrsunshine.me, while keeping the old address active for inbound mail, using Brevo for website/blog sending, and keeping eM Client working after the change.

Bottom-line conclusions

  1. Verified: The safest Zoho path is not to create a separate new mailbox by default. Instead, add mrsunshine.me as a domain in the same Zoho organization, create dmitri@mrsunshine.me as an email alias on the existing user, and set that alias as the mailbox address. Zoho explicitly documents this flow and says it preserves current settings, contacts, and mail.
    Status: Verified
    Sources: [Z1], [Z2], [Z3]

  2. Verified: Changing the organization’s primary domain is not the same thing as changing the user’s actual main mailbox address. The primary-domain setting mainly changes the default domain selected in admin drop-downs.
    Status: Verified
    Sources: [Z2]

  3. Verified: If Zoho 2FA / OTP was enabled, eM Client will usually need a Zoho application-specific password for IMAP/SMTP access. Zoho explicitly requires app-specific passwords for POP/IMAP/ActiveSync access when 2FA is enabled.
    Status: Verified
    Sources: [Z4], [Z5]

  4. Verified: For paid Zoho organization users on custom domains, Zoho’s own docs show imappro.zoho.com / smtppro.zoho.com as the standard server names, but Zoho also warns that the exact server details shown inside the account are the source of truth because they vary by account type and data center.
    Status: Verified
    Sources: [Z5]

  5. Verified: Brevo’s standard sender-domain authentication does not require SPF or MX records just to authenticate the domain; Brevo says SPF and MX records are only provided when setting up a dedicated IP.
    Status: Verified
    Sources: [B1], [B2]

  6. Verified: If the domain already has a DMARC record, there must still be only one DMARC record. Brevo says if the existing record lacks a rua tag, it should be edited, not duplicated.
    Status: Verified
    Sources: [B1], [B3], [B4]

  7. Verified: Zoho says a domain must have one SPF record only. If another sending provider eventually requires SPF, the SPF mechanisms must be merged into the single existing SPF record rather than creating a second v=spf1 TXT record.
    Status: Verified
    Sources: [Z6]

  8. Tentative / judgment call: Zoho’s spam handling is reasonable to trust if configured conservatively during migration, but there is no official benchmark in the cited materials proving “good enough” versus competitors. A pragmatic setup is to keep filtering on, avoid aggressive hard rejection during the transition, and review spam/quarantine while DNS and auth changes settle.
    Status: Tentative / operational recommendation, not officially benchmark-verified
    Sources: [Z7], [Z8], [Z9], [Z10]

Purpose of This Document

This file is meant to serve as all of the following:

  • a guide for the user,
  • an execution playbook,
  • a briefing memo,
  • a verification artifact,
  • and a handoff document for another AI.

It is designed so that another AI should be able to continue the work without needing the original chat.

Discussion Context

User goals

  • Move from dmitri@zasage.me to dmitri@mrsunshine.me as the main identity going forward.
    Status: User-stated
  • Keep dmitri@zasage.me active as a secondary/legacy address that still receives mail.
    Status: User-stated
  • Continue using the existing paid Zoho Mail account rather than starting from scratch if possible.
    Status: User-stated / implied by context
  • Keep using eM Client as the desktop email client.
    Status: User-stated
  • Understand whether Zoho spam settings are trustworthy and how to set them.
    Status: User-stated
  • Use Brevo for website/blog signup and related sending.
    Status: User-stated
  • Resolve eM Client login issues that appeared after changes and after enabling OTP / 2FA.
    Status: User-stated

Practical environment inferred from the discussion

  • Existing Zoho mailbox is on a paid plan, not free.
    Status: User-stated
  • The UI is confusing and the user wants exact, operationally specific guidance, not theory.
    Status: User-stated
  • Another AI should be able to continue from this point with minimal ambiguity.
    Status: User-stated

Key Facts and Verified Findings

1) Zoho domain and mailbox-address mechanics

PointEvidence statusDetailsEvidence
Add the new domain to the same Zoho organizationVerifiedZoho’s Admin Console supports adding multiple domains under one organization.[Z2], [Z11]
New domain must be verified and mail delivery configuredVerifiedZoho says that after adding a domain, ownership must be proved and email delivery configured.[Z2], [Z11], [Z12]
The right way to change the effective main user address is via alias → mailbox addressVerifiedZoho documents: create an email alias and optionally select “Set as Mailbox Address.” It also documents setting an existing alias as the default mailbox address later.[Z1], [Z3]
Zoho does not let admins directly modify the user’s original primary email addressVerifiedZoho explicitly states: “You cannot modify the user’s primary email address.”[Z1]
This alias-to-mailbox-address method preserves existing settings / contacts / emailsVerifiedZoho explicitly says this route is better than deleting the current address because the current settings, contacts, emails, and so on can be retained.[Z1]
Changing organization primary domain is not the same as changing mailbox addressVerifiedThe “Set Primary Domain” function only changes the default selected domain in admin areas.[Z2]
Login address can be set separatelyVerifiedZoho documents a separate “Login Email Address” setting under Users → Security.[Z1]

Operational interpretation

For this case, the clean design is:

  • Same Zoho organization
  • Add mrsunshine.me
  • Verify domain
  • Configure mail delivery
  • Add dmitri@mrsunshine.me as alias to the existing user
  • Set that alias as mailbox address
  • Keep dmitri@zasage.me active on the same user for inbound continuity

Status: Mixed

  • The mechanics are Verified by docs.
  • The exact recommended sequence is Assistant-stated but strongly supported by the verified docs.

2) Zoho domain verification and mail-delivery setup

PointEvidence statusDetailsEvidence
Add domain pathVerifiedZoho: Admin Console → Domains → Add → enter domain.[Z2]
TXT verification pathVerifiedZoho: Domains → select domain → Verify Domain Ownership → Add a TXT record in DNS → Verify TXT record.[Z12]
Domain verification can also be done via CNAME or HTMLVerifiedZoho documents TXT, CNAME, and HTML verification methods.[Z12]
Email delivery must be configured after verificationVerifiedZoho says the domain must have email delivery configured after being added/verified.[Z2]

Missing but important implementation notes

These were not fully explored in the chat but should be part of the handoff:

  • MX, SPF, DKIM, DMARC for mrsunshine.me must be configured correctly before expecting clean mailflow.
    Status: Verified in general; exact records depend on region/provider and should come from Zoho/Brevo screens.
    Sources: [Z2], [Z13], [Z6], [B1]

  • Do not disturb DNS for zasage.me if it must continue receiving mail.
    Status: Assistant-stated but operationally obvious; not directly quoted in docs.
    Why it matters: breaking the old domain’s MX/auth records would break the fallback address.

3) eM Client + Zoho after 2FA / OTP

PointEvidence statusDetailsEvidence
IMAP must be enabled in Zoho before using an IMAP clientVerifiedZoho documents the path: Settings → Mail Accounts → primary email address → IMAP Access checkbox.[Z5]
With Zoho 2FA enabled, POP/IMAP/ActiveSync clients need an app-specific passwordVerifiedZoho explicitly requires an application-specific password for POP/IMAP/ActiveSync access under 2FA.[Z4], [Z5]
App password generation pathVerifiedZoho: accounts.zoho.com → Security → App passwords → Generate New Password.[Z4]
Exact server settings vary by account type and data centerVerifiedZoho explicitly says the precise server details in the account are the source of truth and clients can stop working if configured with the wrong ones.[Z5]
Paid custom-domain org users generally use imappro.zoho.com / smtppro.zoho.comVerifiedZoho’s IMAP docs explicitly list those for paid organization users with domain-based addresses.[Z5]
eM Client supports alias configuration under Menu → Accounts → AliasesVerifiedeM Client documents alias setup under Menu → Accounts for the selected account.[E1]
eM Client manual setup pathVerifiedeM Client’s official setup docs say: Menu → Accounts → Mail → Other for manual setup.[E2], [E3]

Important conflict / nuance

There is an important documentation mismatch that another AI should not ignore:

  • eM Client’s generic Zoho setup page shows imap.zoho.com and smtp.zoho.com with normal password guidance.
    Status: Verified, but generic.
    Source: [E4]

  • Zoho’s own paid-organization docs say custom-domain paid users should typically use imappro.zoho.com and smtppro.zoho.com, and that the exact server details shown inside the user’s account are authoritative.
    Status: Verified.
    Source: [Z5]

Best operational conclusion

When debugging eM Client for this mailbox, the authoritative sequence is:

  1. Check the exact server details inside Zoho Mail account settings.
  2. Ensure IMAP Access is enabled.
  3. Generate a Zoho app-specific password if 2FA is enabled.
  4. Re-enter credentials manually in eM Client if auto-detect is wrong.
  5. Use the full mailbox address that Zoho expects for the mailbox or alias, and validate send/receive.

Status: Assistant-stated but strongly supported by verified docs.

4) Zoho spam controls, allow/trust/block behavior, and what is actually documented

PointEvidence statusDetailsEvidence
Zoho has configurable organization spam processing and verification controlsVerifiedAdmin path: Security & Compliance → Spam Control / Spam Verification.[Z7]
SPF failure actionsVerifiedPermanent reject / Temporary reject / None / Move to quarantine.[Z7]
DKIM failure actionsVerifiedPermanent reject / Temporary reject / None / Move to quarantine.[Z7]
DMARC actionsVerifiedNone / Move to Spam / Move to quarantine.[Z7]
DNSBL actionsVerifiedPermanent reject / Temporary reject / Move to Spam / Quarantine.[Z7]
Allowed List does not fully override SPF failure in all casesVerifiedZoho notes that if SPF fails and no action is set, allowed-list entries may not prevent marking as spam because spoofing is possible.[Z8]
Trusted List bypasses spam checksVerifiedZoho says trusted-list emails go to inbox without any spam checks.[Z9]
Rejected List bounces mail without checksVerifiedZoho says rejected-list emails are bounced without checks.[Z9]
Zoho warns to be cautious with Trusted/RejectedVerifiedZoho warns wrong additions can let in lots of spam or lose legitimate emails.[Z9]
Zoho says the system learns from user corrections like Mark Spam / Mark Not SpamVerifiedZoho states its system learns from user corrections over time.[Z10], [Z14]

Recommendation made in the chat

  • Use Zoho spam filtering.
  • Do not allow everything through.
  • During transition, avoid overly aggressive hard rejection.
  • Use a conservative settings profile such as:
    • Spam processing enabled
    • SPF/DKIM failures not immediately hard-rejected
    • DMARC/DNSBL routed to Spam or Quarantine
    • Review spam folder / quarantine while changes settle

Evidence status of that recommendation

  • Zoho’s controls and options are verified.
  • The exact “best” configuration is not prescribed by Zoho as a universal best practice in the cited docs.
  • Therefore the recommendation is a Tentative / operational judgment, not a verified vendor mandate.

Strongest safe interpretation

A conservative migration posture is sensible because:

  • DNS and authentication changes can create false positives temporarily.
  • Hard rejects make troubleshooting harder because the message never lands for review.
  • Zoho explicitly offers Spam, Quarantine, and Reject as distinct operational choices.
    Status: Tentative recommendation, supported by available control semantics rather than a single official “best” profile.

5) Brevo sender-domain authentication and DNS interplay

PointEvidence statusDetailsEvidence
Brevo can authenticate domains automatically or manuallyVerifiedBrevo supports automatic authentication and manual authentication.[B1]
Manual auth is only required if Brevo cannot authenticate automaticallyVerifiedBrevo explicitly says manual authentication is only required if automatic auth cannot be done.[B1]
If a DMARC record already exists, Brevo may ask to replace it during automatic authVerifiedBrevo explicitly documents this.[B1]
If you do not want Brevo to replace an existing DMARC record, use manual authVerifiedBrevo explicitly says this.[B1]
Domain should have only one DMARC recordVerifiedBrevo explicitly says only one DMARC record should exist.[B2], [B3]
If existing DMARC lacks rua, edit the existing record and append Brevo’s rua tagVerifiedBrevo documents exactly this.[B2], [B4]
Standard Brevo domain auth does not require SPF or MXVerifiedBrevo says SPF and MX are not required to authenticate a domain; they are only provided for dedicated IP setups.[B1], [B2]
Dedicated IP setup may require SPF/MX and additional DNS recordsVerifiedBrevo’s dedicated-IP documentation shows advanced DNS including SPF, MX, DKIM, and DMARC.[B5]

Critical implication

If the user is on normal/shared Brevo sending:

  • Do not assume Brevo requires SPF changes.
  • Do not add a second SPF record.
  • Let Brevo’s current domain-authentication screen dictate the required DNS records.

If the user upgrades to a dedicated IP, the answer changes and SPF/MX can become relevant.

Status: Verified core behavior + assistant operational interpretation.

6) SPF management across Zoho + Brevo + anything else

PointEvidence statusDetailsEvidence
Each domain should have only one SPF recordVerifiedZoho explicitly states this.[Z6]
Multiple v=spf1 TXT records are invalid and harmfulVerifiedZoho says they can cause delivery failures, spam classification, SPF validation failure, and reputation problems.[Z6]
If multiple providers send mail for the same domain, SPF must be consolidated into one recordVerifiedThis follows directly from Zoho’s conflicting-SPF guidance.[Z6]

Best operational rule

Whenever a new sending service is introduced:

  1. Check whether it actually requires SPF.
  2. If yes, merge its include/mechanism into the single existing SPF record.
  3. Do not create a second SPF TXT record.

Status: Verified principle; exact syntax depends on the provider.

Major Decisions and Conclusions

DecisionEvidence statusWhy
Keep one Zoho user/mailbox rather than create a second mailbox by defaultAssistant-stated but strongly supportedBest fit for “same inbox, old address still receiving, minimal disruption.”
Add mrsunshine.me as domain in the same Zoho orgVerifiedRequired for the new address to exist in Zoho.
Create dmitri@mrsunshine.me as alias on the current userVerifiedSupported Zoho path for a new address on same mailbox.
Set the alias as the mailbox addressVerifiedThis is the mechanism to make the new address the effective default mailbox address.
Keep dmitri@zasage.me active on the same userAssistant-stated but logically alignedPreserves continuity for inbound mail and account-change lag.
Keep Zoho spam filtering on, but avoid harsh reject-first settings during migrationTentative / judgmentSafer while DNS/auth/client settings stabilize.
Use Brevo for website/blog/automation sending, not the personal mailboxAssistant-stated but consistent with common deliverability practice; only partially documented hereGood separation of roles and sender reputation.
Treat Zoho’s in-account server settings as authoritative over generic eM Client presetsVerifiedZoho explicitly says wrong server details can stop the client from working.
Use Zoho app-specific password in eM Client after 2FAVerifiedZoho explicitly requires this.

Reasoning, Tradeoffs, and Why It Matters

A) Alias-on-existing-user vs separate new mailbox

Alias-on-existing-user

Pros

  • Retains existing mail, contacts, settings, and mailbox history.
  • Lets the old address continue working on the same mailbox.
  • Less migration friction for eM Client and day-to-day workflow.

Cons

  • Can create confusion between mailbox address, alias, login email, and primary domain.
  • Some desktop client behaviors may need manual cleanup.

Evidence status: Mixed

  • Core mechanics are verified by Zoho.
  • Pros/cons are assistant synthesis.

Separate new mailbox

Pros

  • Cleaner conceptual separation.
  • Separate inbox and identity.

Cons

  • More operational pain.
  • Possibly another license / user.
  • Not aligned with the user’s stated desire to keep one working mailbox while transitioning.

Evidence status: Assistant-stated operational assessment.

Conclusion

Alias-on-existing-user is the right default unless the user explicitly wants a second inbox.

B) Hard reject vs spam/quarantine during migration

Reject-first approach

Pros

  • Maximum strictness.
  • Cleaner inbox.

Cons

  • Harder troubleshooting.
  • Legit mail can vanish before review, especially while DNS/auth is changing.

Spam/quarantine-first approach

Pros

  • Better visibility during transition.
  • Easier to recover false positives.
  • Lets the user observe what is breaking.

Cons

  • More review burden initially.
  • Some junk still reaches review queues.

Conclusion

For a transition period, Spam / Quarantine over immediate reject is the safer posture.

Evidence status: Tentative / operational judgment; not directly mandated by a single vendor source.

C) Brevo auth vs SPF editing

Why this mattered in the chat

The user asked whether using Brevo would require manually editing SPF.

What the verified evidence says

Not necessarily. Brevo explicitly says SPF and MX are not required just to authenticate a standard sender domain and are only required for dedicated IP setups.
Status: Verified
Sources: [B1], [B2], [B5]

Practical consequence

The right workflow is:

  1. Open Brevo’s current domain-authentication screen.
  2. Add exactly the records Brevo currently shows.
  3. Only touch SPF if Brevo actually instructs you to.

Recommended Playbook / Process

Phase 1 — Stabilize the mailbox design in Zoho

  1. Confirm the current Zoho organization and user that owns dmitri@zasage.me.
  2. Add mrsunshine.me to the same Zoho organization.
    Status: Verified process
    Source: [Z2]
  3. Verify domain ownership via TXT (or CNAME/HTML if needed).
    Status: Verified process
    Source: [Z12]
  4. Configure mail delivery for mrsunshine.me in Zoho.
    Status: Verified requirement
    Source: [Z2]
  5. Create dmitri@mrsunshine.me as an email alias on the current Zoho user.
    Status: Verified
    Source: [Z1]
  6. Select Set as Mailbox Address.
    Status: Verified
    Source: [Z1]
  7. Leave dmitri@zasage.me attached and active.
    Status: Assistant-stated operational step
  8. Optionally set mrsunshine.me as the organization’s Primary Domain for admin convenience.
    Status: Verified capability; optionality is assistant-stated
    Source: [Z2]
  9. Decide whether to also add dmitri@mrsunshine.me as the Login Email Address.
    Status: Verified capability
    Source: [Z1]

Success criteria

  • Both addresses receive mail in the same mailbox.
  • The new address is the effective main mailbox identity.
  • No unexpected breakage in Zoho webmail.

Phase 2 — Authenticate the new domain for sending and receiving

Zoho-side auth for receiving and normal mailbox sending

  • Ensure Zoho-directed MX records are correct for mrsunshine.me.
  • Ensure the domain’s SPF, DKIM, and DMARC are configured appropriately.
  • Do not create duplicate SPF records.
    Status: Mixed
    • Need for correct mail auth is verified in general.
    • Exact record values depend on account/provider.

Brevo-side auth for website/blog/automation sending

  1. In Brevo, open the sender-domain authentication flow.
  2. Use automatic authentication if it cleanly works and does not cause an unwanted DMARC replacement.
  3. If a DMARC record already exists and you do not want Brevo to overwrite it, use manual authentication.
  4. If the existing DMARC record lacks rua, edit the existing record and append Brevo’s rua tag.
  5. Do not change SPF unless Brevo actually asks for SPF for your current setup.

Success criteria

  • Brevo shows the domain authenticated.
  • Only one DMARC record exists.
  • Only one SPF record exists.
  • Test sends from Brevo authenticate properly.

Phase 3 — Fix eM Client after the mailbox / 2FA changes

  1. In Zoho webmail, confirm the mailbox itself works before touching the client.
  2. In Zoho Mail settings, verify IMAP Access is enabled.
    Status: Verified
    Source: [Z5]
  3. If 2FA / OTP is enabled, generate a Zoho app-specific password.
    Status: Verified
    Source: [Z4]
  4. In eM Client, do not assume auto-detect is right.
  5. Open Menu → Accounts.
  6. If necessary, use manual setup via Mail → Other.
    Status: Verified
    Sources: [E2], [E3]
  7. Use the server details from Zoho’s Server Configuration Details inside the account.
    Status: Verified
    Source: [Z5]
  8. For a paid custom-domain org account, expect something like:
    • IMAP: imappro.zoho.com, port 993, SSL
    • SMTP: smtppro.zoho.com, port 587/TLS or 465/SSL
      Status: Verified as standard pattern, but exact account values may vary
      Source: [Z5]
  9. Use the full mailbox address and the app-specific password in eM Client.
  10. Configure aliases in eM Client if needed under Menu → Accounts → Aliases.
    Status: Verified
    Source: [E1]

Success criteria

  • Receive works.
  • Send works.
  • From-address selection can use the new identity.
  • Old address remains available if desired.

Phase 4 — Set a conservative spam posture during transition

Suggested initial posture

This is a recommended operating stance, not a vendor-mandated “best profile.”

  • Keep Zoho spam filtering enabled.
  • Use the available spam-verification controls.
  • Avoid broad Trusted entries unless truly necessary.
  • Avoid broad Rejected entries unless absolutely sure.
  • Use Allowlist or Blocklist more sparingly and with better reversibility.
  • Check Spam / Quarantine during the transition period.
  • Use Mark Spam and Mark Not Spam to train the filter.

Why

  • DNS/auth changes can temporarily increase false positives.
  • Zoho explicitly learns from user corrections.
  • Trusted / Rejected bypass normal safety rails.

Evidence status: Mixed

  • Features and behaviors are verified.
  • The exact profile is a practical recommendation.

Core verified references

Zoho

Brevo

eM Client

Risks, Caveats, and Red Flags

1) Confusing “primary” concepts in Zoho

There are at least three different “primary” concepts that can be confused:

  • organization Primary Domain
  • user Mailbox Address
  • user Login Email Address

The discussion repeatedly risked mixing these.
Status: Verified conceptually from Zoho docs.

2) eM Client auto-config may be wrong for this account type

The generic eM Client Zoho setup page may not match a paid custom-domain Zoho org account.
Status: Verified conflict
Why it matters: this can directly cause login failures or false password errors.

3) Enabling Zoho 2FA without updating the mail client

This is likely the most direct cause of the post-change eM Client failure.
Status: Assistant-stated causal inference; strongly supported by verified Zoho requirements.

4) Adding multiple SPF or DMARC records

This is an easy way to break authentication.
Status: Verified
Sources: [Z6], [B2]

5) Trusting broad Trusted/Rejected spam-list entries

Trusted bypasses checks; Rejected bounces without checks.
Status: Verified
Source: [Z9]

6) Using the root domain for both personal mailbox and bulk/newsletter reputation without thought

This was not fully explored in the original chat. Another AI should consider whether Brevo should send from:

  • the main root domain (mrsunshine.me), or
  • a dedicated sending subdomain such as mail.mrsunshine.me or news.mrsunshine.me.

Status: Tentative / missing consideration
Why it matters: reputation isolation can be useful, especially if marketing/broadcast traffic grows.
Verification note: this is a broadly accepted deliverability design idea, but it was not directly verified in the official sources gathered for this memo.

7) Alias behavior inside eM Client may still need manual cleanup

Even when the server-side alias exists, the desktop client may need alias entries or default-from adjustments.
Status: Verified in part (alias setup exists), partly unverified for this exact mailbox because no live access or screenshots were available.
Sources: [E1]

Open Questions / What Still Needs Verification

  1. What DNS provider hosts mrsunshine.me?
    Needed for exact click-by-click DNS instructions.
    Status: Unverified

  2. Which Zoho data center is this mailbox in?
    Needed because Zoho says the exact IMAP/SMTP server details vary by data center and account type.
    Status: Unverified
    Source: [Z5]

  3. Was dmitri@mrsunshine.me already created as an alias and set as mailbox address?
    The discussion implied changes were made, but the final exact state was not fully confirmed.
    Status: Unverified

  4. Is dmitri@mrsunshine.me also configured as a Login Email Address, or only as mailbox address?
    Important for sign-in expectations vs client credentials.
    Status: Unverified

  5. Is eM Client using automatic setup or manual setup right now?
    Needed to know how much cleanup is required.
    Status: Unverified

  6. What exact fields are currently configured in eM Client?
    Need:

    • email address
    • username
    • incoming server
    • outgoing server
    • security type
    • port
    • password type used
      Status: Unverified

  7. Is Brevo on a shared sending setup or a dedicated IP?
    This changes whether SPF/MX become part of Brevo setup.
    Status: Unverified
    Source relevance: [B1], [B5]

  8. Does the domain already have a DMARC record? If so, what exactly is it?
    Needed before Brevo authentication changes.
    Status: Unverified

  9. Which domain / subdomain is Brevo sending from in the actual From address?
    Important for alignment, DMARC, and future reputation design.
    Status: Unverified

  10. What exact spam-processing settings are currently enabled in Zoho?
    The discussion recommended a posture, but the current live configuration is unknown.
    Status: Unverified

Suggested Next Steps

Immediate next steps

  1. In Zoho webmail, verify the mailbox state:
    • Is dmitri@mrsunshine.me present as an alias?
    • Is it set as mailbox address?
    • Is dmitri@zasage.me still active?
  2. In Zoho Mail settings:
    • Verify IMAP Access is enabled.
  3. In Zoho Accounts:
    • Generate a new app-specific password for eM Client.
  4. In Zoho Mail account settings:
    • Open the exact Server Configuration Details and record them.
  5. In eM Client:
    • Re-enter settings manually if needed using the authoritative Zoho values.
  6. In DNS:
    • Check mrsunshine.me for MX, SPF, DKIM, DMARC correctness.
  7. In Brevo:
    • Open the authenticated sender-domain screen and capture the exact required DNS records.
  8. Confirm whether Brevo wants only DKIM/DMARC/Brevo-code or whether this account is on dedicated IP and needs more.
  1. Send from an outside mailbox to dmitri@mrsunshine.me.
  2. Send from an outside mailbox to dmitri@zasage.me.
  3. Confirm both arrive in the same Zoho mailbox.
  4. Send outbound from Zoho webmail as dmitri@mrsunshine.me.
  5. Send outbound from Zoho webmail as dmitri@zasage.me if needed.
  6. Repeat send/receive tests in eM Client.
  7. Send a Brevo-authenticated test email and check authentication results.

Handoff Notes for Another AI

This is the most important section for continuation.

What has already been resolved

  • The correct conceptual Zoho design is now clear:
    • same org
    • same mailbox/user
    • new alias
    • new alias set as mailbox address
    • old address kept active
  • The main likely cause of the eM Client failure is also clear:
    • Zoho 2FA / OTP was enabled
    • eM Client likely still needs or is still using the wrong password/auth pattern
  • The Brevo SPF question is substantially clarified:
    • standard Brevo domain auth does not inherently require SPF/MX changes
    • dedicated IP setup is the special case
  • The spam-settings question is partially resolved:
    • controls are documented and understood
    • the exact “best” profile remains an operational judgment rather than a hard vendor truth

What another AI should do next

The next AI should not restart the whole explanation. It should ask for or work from the following concrete live-state details:

  1. Screenshot or transcription of:

    • Zoho user alias list
    • Zoho mailbox address state
    • Zoho server configuration details
    • eM Client account settings
    • current DNS for mrsunshine.me
    • Brevo sender-domain auth screen

  2. Then produce:

    • a precise repair checklist for eM Client
    • a DNS diff checklist
    • a safe spam-settings recommendation matched to the user’s tolerance for review vs rejection

Key caution for another AI

Do not tell the user that changing the org primary domain alone changes the mailbox. It does not.

Do not tell the user to add a second SPF record.

Do not assume eM Client’s generic Zoho setup page is authoritative for this paid custom-domain account.

Do not state with unsupported certainty that Zoho spam filtering is “excellent” or “best-in-class.” That was not verified here.

Reviewer Notes and Improvements Made

Reviewer capability

No separate reviewer-agent capability was available in this workflow.

Self-review performed

A serious self-review pass was performed with the following improvements:

  1. Separated verified facts from advice.
    Several earlier chat claims were pragmatic but not directly documented. This artifact now clearly labels those as:

    • Assistant-stated but strongly supported
    • Tentative / judgment
    • Unverified

  2. Flagged the biggest doc conflict explicitly.
    The contradiction between:

    • eM Client’s generic Zoho setup page, and
    • Zoho’s own paid-org custom-domain documentation
      was elevated to a major red flag because it directly affects troubleshooting.

  3. Removed false certainty around spam quality.
    The earlier chat leaned practical, but not all of it was directly benchmark-verifiable. This memo now clearly says the spam-settings recommendation is an operational posture, not a proven universal best practice.

  4. Added missing implementation risk around SPF/DMARC duplication.
    This is one of the easiest ways to break mail delivery/auth when multiple tools are involved.

  5. Added handoff-specific instructions.
    Another AI now has a clear path to continue from live settings instead of rehashing theory.

  6. Added unresolved questions explicitly.
    This makes it easier to move from “guidance” to “execution.”

Quality bar assessment

This artifact is substantially stronger than the original discussion because it:

  • isolates evidence status per point,
  • preserves source links,
  • makes the critical conflicts explicit,
  • adds missing operational pitfalls,
  • and converts the discussion into a reusable playbook.

Optional Appendix — Structured Summary (YAML-style)

document_date: 2026-03-25
topic: Zoho Mail domain/address transition with Brevo and eM Client
user_goals:
  - make dmitri@mrsunshine.me the main address
  - keep dmitri@zasage.me receiving mail
  - keep one working Zoho mailbox if possible
  - keep eM Client working
  - understand safe Zoho spam settings
  - understand Brevo DNS/SPF/DMARC implications
verified_core_findings:
  - zoho_alias_mailbox_address_flow_supported: true
  - zoho_primary_domain_not_same_as_mailbox_address: true
  - zoho_primary_email_not_directly_editable: true
  - zoho_login_email_separate: true
  - zoho_2fa_requires_app_password_for_imap_pop: true
  - zoho_paid_custom_domain_servers_use_pro_hosts: true
  - zoho_exact_server_details_depend_on_datacenter: true
  - zoho_only_one_spf_record_allowed: true
  - brevo_standard_domain_auth_does_not_require_spf_or_mx: true
  - brevo_dedicated_ip_can_require_spf_mx: true
  - brevo_single_dmarc_record_required: true
  - brevo_add_rua_to_existing_dmarc_if_missing: true
recommended_design:
  mailbox_model: single_existing_mailbox
  new_primary_identity: dmitri@mrsunshine.me
  legacy_receiving_address: dmitri@zasage.me
  zoho_action:
    - add_domain_mrsunshine_me
    - verify_domain
    - configure_email_delivery
    - create_alias_dmitri_at_mrsunshine_me
    - set_alias_as_mailbox_address
    - keep_zasage_alias_active
  emclient_action:
    - enable_imap_in_zoho
    - generate_app_password
    - use_exact_server_details_from_zoho
    - manually_fix_account_if_autodetect_is_wrong
  brevo_action:
    - authenticate_domain_based_on_current_brevo_screen
    - do_not_add_spf_unless_brevo_requires_it
    - maintain_single_dmarc_record
open_questions:
  - dns_provider_for_mrsunshine_me
  - exact_zoho_datacenter
  - exact_current_zoho_alias_state
  - exact_emclient_settings
  - current_dmarc_record
  - whether_brevo_uses_shared_or_dedicated_ip
red_flags:
  - confusing_primary_domain_vs_mailbox_address_vs_login_email
  - eM_Client_generic_Zoho_settings_may_be_wrong_for_paid_custom_domain
  - adding_multiple_SPF_records
  - adding_multiple_DMARC_records
  - enabling_2FA_without_switching_to_app_password

Graph View