Email API key security: scopes, rotation and where keys belong

An email API key is a small string with a lot of power. Whoever holds it can send mail from your domain, to anyone, under your name. Leaked keys are one of the most common ways phishing campaigns end up being sent from legitimate companies’ infrastructure.

The good news: a few habits make a leak unlikely, and limit the damage if one happens anyway. This guide covers them, using the controls Inbixio gives every key.

What an Inbixio key can do

Every key you create in API Keys → Create Api Key has three settings:

• Name, for your own bookkeeping, for example prod-auth-service.
• Server Access: All Server (sends through the first SMTP server you connected) or Selected Server (exactly the one you pick).
• Permissions: Send, Read and Manage. The API currently has one endpoint, sending email, so Send is the permission your services need.

Keys look like ibx_ followed by 32 hexadecimal characters. The prefix makes them easy to recognise, and easy for secret scanners to catch.

Rule 1: one key per service and environment

Do not share one key across your whole company. Create a separate key for each service, and for each environment:

Separate keys mean:

• A leak is contained. Revoking prod-billing does not take down sign-in emails.
• Each service sends from the right address. A key pinned to the billing@ server sends from billing@, not from whichever server you connected first. If you delete a pinned server, the key falls back to your first server, so re-pin keys when you remove servers.
• Rotation is painless. You can renew one service’s key without touching the others.

Rule 2: grant the least permission that works

A backend that sends email needs Send and nothing else, so leave Read and Manage unticked. The less a key is allowed to do, the less a leak can cost.

Rule 3: keys live on servers, never in clients

Anything shipped to a browser or a mobile app can be extracted, minified or not. That includes:

• JavaScript bundles (React, Vue, Next.js client components),
• environment variables prefixed for the browser, such as NEXT_PUBLIC_, VITE_ or REACT_APP_,
• iOS and Android app binaries.

If a user action in your frontend should trigger an email, call your own backend endpoint. Your backend checks the user is allowed to do it, applies rate limits, and only then calls Inbixio with the key it keeps in its environment.

// ✅ Browser → your API → Inbixio
await fetch('/api/invite', { method: 'POST', body: JSON.stringify({ email }) });

// ❌ Never do this in frontend code
fetch('https://backend.inbixio.com/api/send-email/', {
  headers: { 'X-API-Key': 'ibx_…' }, // visible to every visitor
});

Rule 4: store keys like passwords

• Put keys in a secrets manager (AWS Secrets Manager, Google Secret Manager, Doppler, 1Password, Vault) or your platform’s encrypted environment variables.
• Never commit them. Add .env to .gitignore and turn on secret scanning for your repositories; GitHub’s push protection blocks many leaks before they happen.
• Keep keys out of logs. If you log outgoing requests, strip the X-API-Key header first.
• Don’t paste keys into tickets, chat or screenshots. Share access to the secret, not its value.

Rule 5: rotate on a schedule, and immediately when in doubt

Inbixio can renew a key: click the refresh icon next to it on the API Keys page. Renewing issues a new value under the same name, server access and permissions, and the old value stops working at once. To rotate a production key with no failed sends:

1. Create a second key with the same settings (for example prod-auth-2).
2. Deploy the new key to the service and confirm its requests return 200, for example in your own application logs.
3. Delete the old key.

Use the refresh icon when speed matters more than a seamless hand-over, such as right after a leak. Rotate routine keys every few months, and whenever someone with access leaves the team.

If a key leaks

Treat it as an incident, but a manageable one:

1. Renew (refresh icon) or delete the key immediately. This stops all use of the old value.
2. Check the dashboard logs for unusual activity: calls at odd times or a spike in volume. The log shows when calls were made, not which key made them, so compare it with your own services’ logs.
3. Look at your mail provider for bounces or spam complaints caused by messages you did not send.
4. Find how it leaked, whether a commit, a log line or a frontend bundle, and close that path.
5. Tell affected users if messages were sent in your name, so they know to ignore them.

A quick checklist

• One key per service and environment, with clear names
• Keys pinned to the server (sender address) each service should use
• Only the Send permission on sending services
• No keys in frontend code, mobile apps or repositories
• Keys stored in a secrets manager and stripped from logs
• A rotation date in the calendar, and a plan for leaks

Security is also what keeps you out of spam folders: messages sent from a compromised key damage your domain’s reputation. Pair this checklist with SPF, DKIM and DMARC for the full picture.