Mailbox connection test checklist: record what actually passed

Define the decision

Tests are most informative when they answer a specific question. Start with configuration and authorization, then progress to a controlled send and reply. Keep campaign scheduling outside the mailbox verdict so a later idle campaign does not automatically trigger unnecessary credential changes.

Work through the procedure

1. Record the tested mailbox identity, provider endpoint and transport settings without credentials.
2. Run the supported SMTP and IMAP checks and preserve separate results.
3. Send a clearly labeled internal message and return a reply from an owned address.
4. Verify rendered identity and incoming visibility, then document what the tests did not exercise, such as future sequence timing.

Worked example

The following is a synthetic example for this procedure, not a customer result or performance benchmark.

Test record
SMTP authentication: pass
IMAP access: pass
Controlled outbound message: observed
Controlled reply in Zintara: observed
Signature: correct owner
Not tested: every recipient domain, inbox placement, future campaign capacity

Read the result

The record is stronger because its limits are clear. It establishes a working example of the intended mailbox loop without claiming universal deliverability. If a later issue appears, compare the failing operation with this baseline rather than repeating every test without a hypothesis.

Check before moving on

1. Use an owned address instead of a prospect for diagnostics.
2. Capture the test time so provider logs can be correlated.
3. Retest the affected path after a material configuration change.

Limits and next action

A connection pass is not a production-readiness certificate for the whole campaign. Zintara still applies recipient state, scheduling and delivery controls. Preserve test evidence and investigate the specific failed stage when behavior differs from the baseline.

Source: Zintara unified inbox product context