Email API Key Security: Scope, Rotate and Keep Keys Server-Side

TL;DR

• Keep email API keys on trusted servers and out of browser bundles, screenshots, analytics events and shared examples.
• Give each application and environment only the permissions it needs, with a recorded owner and replacement procedure.
• Rotate by deploying and verifying a replacement before revoking the old key, unless an active exposure requires immediate revocation.
• In MailBlastr, key creation and revocation belong in the dashboard; an API key cannot manage other API keys.

Treat an email key as permission to act as your product

A leaked email API key is more than a broken integration. Depending on its permissions, someone may send messages using your account or access other resources. Recipients will associate those messages with your product, even when the underlying problem is an exposed deployment credential.

Start by mapping where the key exists. A typical application has a production secret store, a deployment configuration, a worker process and perhaps a developer's local environment. Add the owner, purpose and permissions for each copy. If nobody can identify which application still uses a key, rotation becomes a guessing exercise.

Use separate credentials for production and testing. That separation makes it possible to disable a misconfigured test integration without interrupting password resets for real customers. It also gives logs a clearer operational meaning.

Keep the sending boundary on the server

The browser should submit an authorized request to your application. Your server decides whether an email is appropriate, builds the permitted message and calls the provider. Never expose the provider credential so a client can send arbitrary messages directly.

For example, a receipt endpoint should look up a completed order using the authenticated account. It should not accept an unrestricted recipient, subject and HTML document from the browser. Protecting the key while leaving an open email relay in your application solves only half the problem.

Check build-time environment conventions carefully. A variable intended for public browser configuration is the wrong place for an email credential. Inspect the deployed client assets when changing the integration, and exclude secrets from exception context, request tracing and support attachments.

The broader principles are least privilege, controlled storage, rotation and revocation. The OWASP secrets management guidance is a useful reference for designing that lifecycle rather than treating a secret as a permanent string.

Choose permissions around the actual task

MailBlastr distinguishes sending access from broader account access. A service that only sends notifications should use sending access. A separate administration integration may need broader permissions, but that is not a reason to give every background worker the same credential.

MailBlastr also reserves key creation, rescoping and revocation for dashboard sessions. API-key callers cannot create replacement keys through the API, including callers holding a full-access key. Plan rotation around that boundary instead of shipping an unattended script that assumes it can mint its own replacement. See handling API keys.

Record which sender domains and application routes each integration uses even when those are not individual permission controls. This inventory is operational context, not a claim that a label provides technical isolation. Test the actual permission behavior before relying on it.

Rotate without creating a delivery outage

For a routine rotation, create the replacement in the dashboard and store it in the production secret manager. Deploy the sending service with the new reference. Send a controlled message to a test recipient, confirm the expected provider result and inspect the application's error rate.

Next, wait for old application instances and workers to drain according to your deployment model. A successful request from one new instance does not prove every old process has stopped. Revoke the old credential once the fleet is using the replacement, then verify that the old key is rejected.

Keep the sequence in a short runbook with an owner and a rollback decision. A rollback should restore a known safe deployment, not silently reactivate an exposed credential. If you discover active misuse or a public leak, revoke promptly and accept that restoring service may require an incident response rather than a seamless change.

Investigate exposure beyond the visible file

Removing a key from a repository's latest revision does not revoke copies in history, forks, logs or downloaded artifacts. Replace the credential first, then investigate the exposure window and affected systems.

Review outbound activity for unusual recipients, sending patterns and message categories. Preserve the evidence your team needs without copying full sensitive payloads into a broadly accessible incident channel. Check related credentials only where the exposure suggests they may also be affected.

Afterward, add the smallest control that would have caught the actual mistake: secret scanning, restricted deployment permissions, safer logging defaults or a test proving browser requests never contain provider credentials.

Make credential changes part of email testing

Include an invalid-key case and an insufficient-permission case in your integration checks. They should produce a clear operational error without causing an endless retry loop. Authentication failures generally need configuration repair, not repeated sends with new idempotency keys.

Pair credential checks with an email testing checklist and a documented retry strategy. Reliable delivery depends on both: the right service must be authorized to send, and an uncertain network response must not create duplicate customer messages.