Sendrealm API Keys and SMTP Credentials Best Practices

An email API key is not a setup detail. It is a production credential that can authorize sends, expose project resources, or modify messaging configuration depending on its permissions. Good key design limits the impact of a mistake and makes normal rotation uneventful.

Sendrealm supports project-scoped keys, team keys that can cover selected or all projects, and permission presets for sending, read-only, full, or custom access. The safest configuration is the narrowest key that still lets one integration do its job.

Start with the three dimensions of access

Every key should have an explicit answer to three questions.

Which environment owns it?

Production, staging, development, and local testing should not share a credential. Environment separation prevents a test script from sending through production and lets you revoke non-production access without affecting customers.

Which projects can it access?

Use a project API key when one service belongs to one Sendrealm project. Project keys cannot be expanded or reassigned to other projects.

Use a team API key only when an integration genuinely needs one, several, or every project in a team. Choose the accessible projects deliberately and set a clear default project. A team key is useful for a centralized platform service or agency operation, but it creates a larger security boundary.

Which operations does it need?

Sendrealm provides presets and custom permissions:

• Sending: email.send, push.send, and events.ingest
• Read-only: resources.read
• Full access: all supported operations
• Custom: an explicit combination such as email.send without push or resource writes

A transactional email worker normally needs email.send, not permission to modify audiences, templates, domains, or other resources. An observability job may need only resources.read.

API keys also act as SMTP passwords

For SMTP, use:

• host: smtp.sendrealm.com
• username: smtp
• password: the Sendrealm API key
• port 587 with STARTTLS, or 465 with implicit TLS

The SMTP username is not an account email address. The API key carries the authorization and remains subject to its project access and permissions.

Create a dedicated key for every SMTP integration. Naming a key production is not enough; prefer names such as:

• supabase-auth-production
• billing-worker-production
• support-tool-staging
• nightly-report-service

The name should tell an operator which system will break if the key is revoked.

Store secrets outside application code

Put Sendrealm keys in a managed secret store or protected server environment. Examples include your cloud provider's secret manager, a deployment platform's encrypted environment settings, or a tightly controlled CI/CD secret.

Never store a key in:

• browser code or a public runtime variable
• an iOS or Android application bundle
• app.json, google-services.json, or another client configuration file
• source control, even in a private repository
• screenshots, tickets, chat messages, or shared documents
• application logs or error-monitoring breadcrumbs

An .env file is only safe when it remains local, ignored by version control, and protected like any other secret. Production should use a managed store with access logs and rotation controls.

Create one key per workload

Shared credentials feel convenient until something goes wrong. If five services use the same key, revoking one exposed deployment interrupts all five. Activity is also harder to attribute.

A one-key-per-workload pattern gives you:

• precise revocation
• clearer ownership
• safer permission choices
• easier environment separation
• a usable secret inventory

Do not create a new key for every process replica. All instances of the same deployed workload can read the same managed secret. The boundary is the system and responsibility, not the container count.

Rotate without creating downtime

Use an overlap procedure:

1. Identify the key's owner, permissions, project scope, and every deployment that uses it.
2. Create a replacement with the same intended access.
3. Store the new value in the secret manager.
4. deploy or restart consumers so they read the replacement.
5. Send a controlled test and inspect its Sendrealm events.
6. Confirm the old key is no longer used.
7. Revoke the old key.
8. Record the rotation date and owner.

Do not delete the old key before you know every long-running worker and scheduled job has reloaded its configuration.

Routine rotation should follow your organization's security policy. Immediate rotation is required when a key appears in a commit, build artifact, log, support transcript, lost device, or compromised vendor configuration.

Treat source-control exposure as real exposure

Removing a key from the latest commit does not remove it from Git history, caches, forks, CI output, or copied clones. If a real key is committed:

1. revoke or rotate it immediately
2. update the affected deployment
3. inspect Sendrealm activity for unexpected use
4. determine how it entered the repository
5. add secret scanning and a prevention control

History rewriting can reduce future discovery, but it does not make the old key trustworthy again.

Design safer development and testing

Development keys should belong to a non-production project and use the same narrow permission model as production. Test messages should go only to controlled recipients.

Useful safeguards include:

• an allowlist in application code for non-production recipients
• a recognizable subject prefix such as [staging]
• environment-specific sending domains
• lower usage limits and alerts
• no production customer export in a development audience

The goal is to test the entire delivery path without making development capable of a broad production send.

Incident-response checklist

When exposure is suspected:

• revoke or replace the key first
• identify the exact project and permissions it had
• search deployments and repositories for every copy
• review message and resource activity during the exposure window
• notify internal security or operations owners
• document impact and remediation
• fix the storage or access path that caused the leak

Because a sending-only key and a full-access team key have different blast radii, accurate permission and project-scope records save time during an incident.

A practical key inventory

For every credential, record:

Review the inventory during staff transitions, vendor changes, and security audits. A key without an owner should be investigated, not left active indefinitely.

The operating principle

Use one identifiable key per workload, keep it server-side, restrict its projects and permissions, and practice replacement before an emergency. That pattern works for both the Sendrealm API and SMTP because the same credential model protects both paths.

For SMTP connection examples, continue with How to Send Email with Sendrealm SMTP.