Knowing when to deactivate versus delete an SMTP account — and how to do each safely — is important for maintaining a clean, secure workspace. This article explains the difference, walks through each process, and covers what happens to in-flight messages and delivery history when accounts are deactivated or deleted.
Deactivate vs Delete — Key Differences
| Deactivate (Disable) | Delete | |
|---|---|---|
| Effect on credentials | Credentials remain; any authentication attempt is rejected with 535 | Credentials are permanently destroyed — username and password cease to exist |
| Reversibility | Fully reversible — re-enable at any time to restore sending capability instantly | Permanent — cannot be undone; a new account must be created if needed |
| Plan slot | Account still occupies a plan slot while disabled | Slot is freed immediately — available for a new account |
| Usage history | All historical statistics preserved | Account-level statistics removed; delivery logs retained at workspace level |
| Use when | Temporarily stopping sending (maintenance, investigation, environment offline) or suspected compromise while investigating | Permanently decommissioning an environment, removing a client, or freeing a slot |
How to Deactivate an SMTP Account
- Go to MigoSMTP → SMTP Accounts.
- Click on the account you want to deactivate.
- In the account detail view, click Disable Account.
- Confirm the action in the dialog.
- The account status changes to Disabled.
- Any application trying to authenticate with this account's credentials immediately receives:
535 5.7.8 Authentication credentials invalid
Re-enabling a Disabled Account
- Go to SMTP Accounts → [account].
- Click Enable Account.
- The account is immediately active — credentials work again within seconds.
- No password change is required — the original credentials remain valid.
What Happens to In-Flight Messages When an Account Is Disabled
| Message State at Time of Disable | What Happens |
|---|---|
| Already dispatched to recipient server | Delivery continues normally — disabling an account does not recall already-dispatched messages |
| In the sending queue (queued for limit reset) | Queued messages submitted via this account may not be dispatched while the account is disabled — clear the queue before disabling if you want to prevent delivery |
| In retry queue (deferred) | Deferred messages may continue retry attempts — the account disable only blocks new authentication attempts, not already-in-flight retry cycles |
How to Delete an SMTP Account
- Confirm no active application is using the account's credentials — update or disable those integrations first.
- Confirm the queue is empty for this account (check Reports → Delivery Reports filtered to this account for Queued status).
- Go to SMTP Accounts → [account].
- Click Delete Account (may be in a dropdown or overflow menu).
- Type the account name in the confirmation field.
- Click Confirm Delete.
Cannot be undone. Once deleted, the account and its credentials are permanently destroyed. If your application attempts to authenticate after deletion, it receives a permanent 535 authentication error until new credentials are configured. When in doubt — disable, do not delete.
Bulk Account Cleanup — Removing Dormant Accounts
For workspaces with many accounts accumulated over time, a periodic cleanup frees slots and reduces clutter. Identify dormant accounts:
- Go to SMTP Accounts and sort by Last Used.
- Identify accounts with Last Used > 90 days ago and low or zero total sent count.
- Before deleting, search your codebase and server environment for references to that account's username — confirm it is truly unused.
- Delete dormant accounts one at a time to avoid accidental deletion of an account that is used infrequently but is still needed.
Post-Deletion Checklist
| ✓ | Action After Deleting an Account |
|---|---|
| □ | Remove deleted credentials from all application environment variables |
| □ | Remove from any secrets managers (AWS SM, Vault, Doppler) |
| □ | Remove from any CI/CD pipeline secret stores |
| □ | Update team password manager entries to remove the old credentials |
| □ | Document the deletion in your infrastructure change log |