API key security comes down to four habits: give every key the smallest set of permissions it needs, keep it in a proper secret store, rotate it without downtime and have a plan ready for the day one leaks. A leaked sending key lets anyone email as you, so it puts your sender reputation at risk as well as your data.
Check the permission names in your account. The permission names in this guide are examples of the pattern. Use the options your MigoSMTP account actually offers, and choose the narrowest one that works.
Why keys leak
| How it leaks | Example | Prevention |
|---|---|---|
| Committed to a repository | A config file with a key is pushed to a public or shared repo | Use environment variables, ignore files and secret scanning |
| Shipped to the client | A key inside JavaScript or a mobile app | Call your own server instead |
| Shared in chat or tickets | A key pasted in a support thread | Share through a secret manager and rotate if exposed |
| Left on a departing account | A former contractor still holds the key | Rotate when people leave |
| Logged by accident | A debug log prints request headers | Mask secrets in logs |
| Compromised server | Malware reads environment variables | Patch servers and limit what each server can reach |
Step 1: One key per application and environment
Create separate keys for production, staging and every application that sends mail. Name them so you can recognise them in an audit log.
| Key name | Used by | Permission |
|---|---|---|
| shop-production | The online store, order emails | Send only |
| shop-staging | Test environment | Send only, to test addresses |
| crm-production | The CRM, campaign sending | Send and manage own contacts |
| webhooks-reader | A reporting job | Read events only |
| ops-admin | A named person, rare tasks | Full access with two-factor authentication |
Step 2: Apply least privilege
Ask of each key: what is the least it needs to do? Sending mail does not require reading your contact list, changing DNS or managing billing, and a reporting job should not be able to send at all.
- Prefer a send-only key for any system that only delivers messages.
- Keep account, billing and user management for people with two-factor authentication, not for keys.
- Review permissions each quarter and remove what is no longer needed.
- If your account offers restrictions by IP address, domain or rate limit, use them. See the account security settings for what is available.
Step 3: Store keys safely
Load the key at runtime from the environment or a secret manager. A minimal pattern is below.
# .env (never commit this file)
MIGOSMTP_API_KEY=replace-with-your-key
# .gitignore
.env
*.pem<?php
$key = getenv('MIGOSMTP_API_KEY');
if (!$key) {
throw new RuntimeException('API key is not configured');
}Add secret scanning. Turn on secret scanning in your code host and run a scanner in your build pipeline. It catches keys before they reach a shared branch and gives you an alert if one slips through.
Step 4: Rotate without downtime
- Create the new key. Give it the same permissions and a name with the date or version.
- Store it. Add it to your secret manager or environment configuration.
- Deploy. Release the change and restart the services that read the key.
- Verify. Check delivery logs to confirm that traffic uses the new key.
- Revoke the old key. Do this only after traffic has moved. Wait a short period and check for failures.
- Record it. Note the date, the reason and who did it.
Step 5: Monitor for abuse
| Signal | What it can mean | Action |
|---|---|---|
| Volume far above normal | A leaked key or a loop in your code | Pause the key and investigate |
| New or unfamiliar recipients | Spam or phishing sent with your key | Revoke the key and review messages |
| Sending at unusual hours | Automated abuse | Check the source IP and restrict access |
| Rising bounces or complaints | Bad recipients or abuse | Check suppression and sources, see the spam checklist |
| Requests from new IP addresses | A key used outside your servers | Add an allow list and rotate |
If a key leaks: the first hour
| Minutes | Do this |
|---|---|
| 0 to 10 | Revoke the key. If you cannot deploy a replacement yet, accept a short outage over continued abuse |
| 10 to 30 | Create and deploy a new key. Confirm normal sending |
| 30 to 60 | Review the delivery log for messages you did not send. Check complaint and bounce rates and blocklists |
| After | Find out how it leaked, remove the source, rotate related secrets and write down what you learned |
If mail was sent in your name, follow the blocklist removal guide and contact support so that the account review has context.
Think a key was exposed? Revoke it first, then contact us with the key name and the time so we can help you review recent sending.
Further reading and sources
Frequently asked questions
Why is an email API key so sensitive?
Anyone who holds a sending key can send mail as you. Attackers use leaked keys to send phishing and spam within minutes, which can get your domain and IP blocklisted and your account suspended. The cost is in reputation, and that takes weeks to repair.
What does least privilege mean for API keys?
It means each key can do only what its job needs and nothing more. A key used by a web form to send mail should not be able to read contacts, change domains or manage billing. If it leaks, the damage is limited to what that key was allowed to do.
Should I use one key for everything?
No. Use a separate key for each application and environment. If one leaks you revoke only that key, and your logs show which system a message came from. Shared keys make incident response slow and risky.
Where should I store API keys?
Use environment variables or a secret manager, and load them at runtime. Do not put keys in source code, in the front end of a website or mobile app, in public repositories, in tickets or in chat. Add configuration files that hold secrets to your ignore file.
How often should I rotate keys?
A common rule is every 90 days for production keys, and straight away when a person with access leaves, a laptop is lost or a leak is suspected. More important than the interval is that you have a rotation process you have already practised.
How do I rotate a key without downtime?
Create a new key, add it to your secret store, deploy the change, confirm that traffic uses the new key and only then revoke the old key. Never revoke first, because that causes an outage while you deploy.
What should I do if a key is leaked?
Revoke the key immediately, create a replacement, deploy it, review recent sending for messages you did not send, and check for blocklist listings and complaint spikes. Then find out how it leaked and close that path.
How can I tell that a key is being abused?
Look for sudden volume, new or unusual recipients, sending at odd hours, a rise in bounces or complaints, and requests from unfamiliar IP addresses. Alerts on volume and bounce rate give you early warning.
Are SMTP credentials different from API keys?
They serve the same purpose, which is proving that you may send, and they need the same care. Treat the SMTP username and password like an API key: one set per application, stored as a secret and rotated on a schedule. See the SMTP settings guide for connection details.
Can I put an API key in a mobile app or in JavaScript on a web page?
No. Anything shipped to a device or browser can be extracted. Send mail from your own server, and let the app or page call your server, which then calls the email API with the key.