Workspace administration · how to

Configure shared email and forwarding

Connect receiving and sending for a shared team address, test both directions, and route it to the correct inbox.

3 min readUpdated August 12, 2026
For
Owner, Admin
Availability
Your current plan and entitlements
Product evidence
WRKZY · reviewed August 12, 2026
Editorial review
WRKZY Editorial
Before you begin
  • Owner or Admin approval for a company-owned shared address
  • Provider access for receiving and Microsoft, Google, or SMTP sending
  • A destination team inbox and routing owner
  • Internal test sender and recipient accounts

Two paths make one shared inbox

Open Settings → Shared email. Receiving and sending are configured separately:

  • Receiving forwards messages from the business mailbox to a WRKZY-generated forwarding address.
  • Sending uses Microsoft, Google, SMTP, or the displayed WRKZY fallback when available.

A green sending state does not prove forwarding works, and an active forwarding path does not prove replies use the intended address.

Add the shared inbox

  1. Select Add shared inbox.
  2. Enter the real business address, a clear display name, and a purpose such as sales, support, or billing.
  3. Save and expand the inbox details.
  4. Under Receiving, copy the generated forwarding address.
  5. In the mailbox provider, create a forwarding rule from the business address to that generated address. Complete any provider verification.
  6. Send a safe inbound test from an external address and confirm a new message appears in WRKZY.

Do not create another WRKZY connection to fix a forwarding rule; duplicates make ownership and thread history harder to reason about.

Configure outbound sending

  1. Select Connect sending or Manage sending.
  2. Choose Microsoft or Google OAuth when available, or enter the required SMTP host, port, username, password, and SSL setting.
  3. Enter a safe recipient and send the provider test email.
  4. Confirm the inbox row says it can reply and shows the intended provider.
  5. Send a reply from a test conversation and confirm the visible From address and delivery outcome.
  6. Decide whether open and click tracking is appropriate, then set the row switch.

The fallback address is an operational bridge, not proof that direct sending from the business address is configured.

History synchronization

Use the history start date and synchronization controls only after the live connection is healthy. Choose the narrowest useful date range. Check the result before expanding; large history imports can create unexpected volume and duplicate-looking threads if provider state was already ingested elsewhere.

Email evidence chain

  1. 01
    LocalPrepared

    Content and recipient are ready but nothing has left WRKZY.

  2. 02
    PendingSubmitted

    WRKZY handed the request to the connected provider.

  3. 03
    AcceptedProvider accepted

    The provider accepted processing, not necessarily delivery.

  4. 04
    ResultDelivered or failed

    A terminal provider event confirms delivery or an exception.

  5. 05
    RecoverException reviewed

    An owner diagnoses, recovers safely, or escalates with evidence.

Prepared and submitted are not delivered. Verify the provider connection, receiving path, and final delivery outcome separately.

Verify ownership and routing

After connection, link the shared email channel to the correct team inbox in Settings → Team inboxes. Test routing there so an inbound message reaches the intended queue and assignment policy.

Recovery

For inbound failure, inspect the provider forwarding rule, generated destination, verification status, and WRKZY receiving status. For outbound failure, inspect the selected provider, test result, authentication error, and Message delivery. Do not paste SMTP passwords or OAuth tokens into support. Provide inbox ID/address, provider type, direction, approximate time, test recipient domain, and redacted error.

Shared email ready
  • Business address and purpose are correct
  • Provider forwarding reaches the generated address
  • Direct or fallback sending path is understood
  • Inbound and outbound tests passed
  • Channel is routed to the intended team inbox
  • Credentials were never copied into evidence
Was this guide useful?

Choose an answer. No message text or personal information is collected.

Still need help?

Contact WRKZY support with the workspace name and a safe, redacted example.

Contact support about this guide