Mailbox Credential and Recovery Inventory Template

Use this template to record mailbox ownership and recovery metadata without storing passwords or tokens. Keep one row per mailbox (or inbox grouping), record the account owner, the recovery path and contacts, access method, last rotation/check date, and escalation instructions so teams can diagnose lockout and reassign access without secrets.

What this inventory is for and what it is not

This inventory captures control metadata: who owns an account, how it can be recovered, how people normally access it, when access was last verified, and who to call in an emergency. It is explicitly not a credential store — do not record passwords, API keys, 2FA secrets, OAuth refresh tokens, or other secrets in this document. Decision boundary: any field that could be used to authenticate (passwords, 2FA seed, recovery codes) must be excluded. Record only recovery paths (e.g., recovery email, phone, delegated admin) and the party responsible for that recovery. Evidence limits: provider procedures for recovery vary; for example Google documents recovery options and best practices but does not guarantee outcomes 1. Treat provider guidance as directional and verify recovery capability regularly rather than assume it will work in an incident.

Required fields and why each matters

Owner: the person or role legally/operationally responsible for the mailbox. Use role addresses (e.g., Platform-Owner) if owners rotate frequently. Capture a primary and secondary owner to avoid single points of failure. Recovery path: record the exact recovery method available (example: recovery email address, recovery phone number, delegated admin account, organization SSO owner) and the owner of that recovery artifact. Note any provider-specific constraints you verified. This field answers “who can ask the provider to reset or prove ownership.” Access method: note whether the mailbox is accessed via web UI, IMAP, delegated mailbox, shared inbox tool, or service account. This guides troubleshooting steps and indicates whether single-user sign-in is required. Include client types and whether app-specific passwords or OAuth are used. Rotation/check date: the last date when the owner verified the recovery path and access method still work. Use this to schedule verification and detect drift. Emergency contact & escalation: name, role, and alternate contact (phone/secondary email). Also record documented emergency steps and stop conditions (e.g., “if recovery-email is unreachable, escalate to IT SRE and request domain admin change”).

Practical sequence to create and maintain the inventory

Initial capture: do a discovery sweep of all mailboxes used for operations, marketing, billing, and system accounts. For each mailbox, interview current owner to capture the required fields and record evidence (screenshot of recovery settings is allowed only if redacted of secrets). Verification: schedule the owner to perform a non-destructive recovery check (confirm recovery email/phone and delegated admin access) and mark the rotation/check date. Do not request passwords or 2FA codes as part of verification; instead confirm that the recovery channel receives test messages or that delegated admin can view settings. Maintenance cadence: verify high-risk mailboxes (customer-facing, billing, domain admin) quarterly and other mailboxes every 6–12 months. Update owner and recovery-path fields when people change jobs; require outgoing owners to transfer ownership in the provider console or capture the recovery path before departure. Incident use: when lockout occurs, follow the recorded recovery path first. If the recovery path fails, use escalation instructions and the emergency contact. Document outcomes and update the inventory with what worked and what did not.

Decision/diagnostic table (when a mailbox is inaccessible)

Use this compact decision table to triage an inaccessible mailbox. Each row is a diagnostic path; stop once a successful action restores access or you reach the escalation row and follow emergency contact steps. Example rows below show practical checks and stop conditions.

Storage, access controls, and auditability

Where to keep the inventory: store in an access-controlled, auditable system (ticketing system, vault metadata, or encrypted document store). Ensure the permission model limits editing to designated roles and records change history. Do not store the inventory in a public or broadly shared document. Audit trail and backup: enable logging for edits and export periodic snapshots to an encrypted backup. For legal or compliance requests, retain historical copies per policy but redact ancillary data that may expose personal contacts unnecessarily. Review who has access to the inventory at least annually.

Practical checklist

• Create one record per mailbox or grouped inbox (do not combine unrelated accounts).
• Record owner (primary and secondary), role, and contact methods (work email and phone).
• Capture recovery path details: recovery email/phone, delegated admin, or SSO owner; name the person who controls that recovery path.
• Specify access method: web UI, IMAP/POP, delegated mailbox, shared inbox tool, or service account; note OAuth vs. app-password use.
• Add last verified date and schedule the next verification (quarterly for high-risk, 6–12 months otherwise).
• Document emergency escalation steps and include an emergency contact with redundancy.
• Do not record passwords, 2FA seeds, recovery codes, tokens, or other secrets in this inventory.
• Restrict edit permissions, enable change logging, and store backups encrypted.
• After any lockout incident, update the record with what worked and change the next verification date.

Where RepMail fits

Use this template as an operational checklist when configuring mailbox access for outbound programs. Keep the inventory alongside your mailbox access and multi-inbox ownership records so deliverability, ops, and on-call teams can quickly identify who can recover an account and how to proceed during a lockout. Do not assume provider recovery will succeed; verify periodically and update the inventory with incident outcomes.

Continue with A/B Testing Cold Email With Small Samples for the next step in the workflow.

Related RepMail guides

• Client-owned recovery methods and break-glass access plan
• Agency knowledge transfer from departing account owner

Sources