SMTP accounts are named sending credentials within your MigoSMTP workspace. Each account has a unique username and password that your application uses to authenticate with the MigoSMTP SMTP relay server. This article explains what SMTP accounts are, how they are structured, and why using multiple accounts strategically improves your email operations.
SMTP Accounts Explained
Think of your MigoSMTP workspace as a building and each SMTP account as a named key to the building's mailroom. Each key:
- Has a unique identity (username and password).
- Can open the same mailroom (connect to the same SMTP server:
smtp.migosmtp.com).
- Can be tracked separately — all mail posted with that key is attributed to that account in your analytics.
- Can be revoked (password reset or account deleted) without affecting other keys.
- Cannot exceed the workspace's overall sending limits — all accounts share the workspace quota and daily/hourly limits.
SMTP Account vs API Key — What Is the Difference?
|
SMTP Account |
API Key |
| Protocol used |
SMTP (port 587 or 465) |
HTTPS REST API |
| Authentication |
Username + password via SMTP AUTH LOGIN |
Bearer token in Authorization header |
| Best for |
Applications that use standard SMTP libraries (PHPMailer, nodemailer, Laravel Mail, WordPress) |
Applications that can make HTTP requests directly and want more control over email features |
| Features accessible |
Send email — basic delivery, open tracking, click tracking |
Full Email API — templates, bulk send, scheduling, suppression management, reporting |
| From address |
Set in the email's From header by the sending application — must be on a verified domain |
Set in the API request JSON body — must be on a verified domain |
Why Use Multiple SMTP Accounts?
| Strategy |
Example Setup |
Benefit |
| One per application |
Account A: Production App; Account B: Staging App; Account C: Dev/Testing |
Rotating production credentials does not affect staging or development environments |
| Separate by email type |
Account A: Transactional; Account B: Marketing; Account C: Notifications |
Per-stream analytics; easy identification of which stream has delivery issues |
| Separate by team |
Account A: Engineering team; Account B: Marketing team |
Teams can rotate their own credentials independently; isolated usage tracking per team |
| One per client (agencies) |
Account A: Client 1; Account B: Client 2; Account C: Client 3 |
Clean usage attribution; easy client billing; revoking access to one client does not affect others |
SMTP Account Properties
| Property |
Description |
| Account Name |
A descriptive label for your internal reference (e.g. Production App). Not visible to recipients. |
| SMTP Username |
Auto-generated unique string. Used as the SMTP AUTH username in your application. Format: smtpuser_[alphanumeric] |
| SMTP Password |
Auto-generated 32-character random string. Shown only once at creation — copy and store securely. Can be reset at any time. |
| Status |
Active or Disabled. A disabled account's credentials are rejected at the SMTP server — no mail can be sent. |
| Sending statistics |
Total sent, delivered, bounced, and complaint counts attributed to this specific account — visible in the account detail view. |
| Created date |
When the account was created — useful for auditing and rotation schedules. |
Plan Limits for SMTP Accounts
| Plan |
Maximum SMTP Accounts |
| 10k Email SMTP Server |
5 |
| 20k Email SMTP Server |
10 |
| 30k Email SMTP Server |
15 |
Next Steps