Rotating and Resetting SMTP Credentials

SMTP credentials — the username and password used by your application to authenticate with the MigoSMTP server — should be treated with the same security rigour as API keys or database passwords. Regular rotation reduces the risk window if credentials are ever exposed, and immediate resets are critical in the event of a suspected compromise. This article explains when and how to rotate or reset SMTP credentials safely.

Credential Rotation vs Credential Reset

When to Rotate Credentials

• Regular schedule — every 90 days as part of your security policy.
• Team member departure — any time an engineer or admin who had access to the credentials leaves your organisation.
• Code repository exposure — if credentials were accidentally committed to a Git repository (even briefly, even in a private repo).
• Third-party access change — when a vendor, contractor, or third party who had the credentials changes relationship with your organisation.
• Security audit requirement — compliance audits (ISO 27001, SOC 2) typically require documented rotation schedules.

Safe Rotation Process — Zero Downtime

The key to zero-downtime rotation is generating the new credentials before disabling the old ones, updating your application, and only then retiring the old credentials.

1. Generate new credentials:
   Go to SMTP Accounts → [account name] → Reset Password.
   A new password is generated. The old password is still valid at this point — MigoSMTP gives you a short overlap window.
2. Copy the new password immediately and save it to your password manager.
3. Update your application with the new SMTP password:
   • Update the environment variable (SMTP_PASSWORD) on your server.
   • For containerised deployments, update the secret in your secrets manager (AWS Secrets Manager, HashiCorp Vault, Kubernetes Secrets) and trigger a rolling deployment.
   • For WordPress/plugins, update the SMTP password in the plugin settings.
4. Verify the new credentials work by sending a test email from the updated application or via the SMTP Accounts test button.
5. Confirm deployment is complete — all application instances are using the new password.
6. Monitor for 15 minutes to confirm no authentication errors appear in your application logs.

Emergency Reset — Suspected Compromise

If you suspect credentials have been compromised (spotted unusual sending in delivery logs, credentials found in a public repo, security incident):

1. Immediately disable the account (faster than resetting if you need to stop sending instantly): SMTP Accounts → [account] → Disable Account. This immediately rejects all authentication attempts with these credentials.
2. Review delivery logs for the past 24–72 hours for any unauthorised or unusual sends from this account.
3. Reset the password to generate new credentials.
4. Re-enable the account.
5. Update all application environments with the new password.
6. If unauthorised sends occurred, contact Rackwave support with the delivery log details for investigation and remediation guidance.

Updating Credentials in Common Environments

Credential Storage Best Practices

• Never store in source code — SMTP credentials in a Git repository (even private) are a serious security risk.
• Use a secrets manager — AWS Secrets Manager, HashiCorp Vault, or Doppler for production environments.
• Use environment variables — at minimum, store credentials as server environment variables, not in configuration files.
• Limit who has access — only the specific application(s) and team members who need the credentials should have them.
• Audit access logs — MigoSMTP delivery logs attribute every send to a specific SMTP account, making it easy to detect anomalies.

Next Steps

• Managing multiple SMTP accounts
• API key security best practices
• What are SMTP accounts?