Send keys

A send key is the credential your application authenticates with when it sends mail — and nothing else. It can send; it cannot register a domain, edit a route, manage a webhook, or mint another key. Those are Console-plane actions governed by permissions, held by people and machine users. A send key authenticates an application on the data plane, so a leaked one can spam within your quota but can never reconfigure the product.

Early access. Email is being rolled out behind an Org flag. If you don’t see it in the Console, it isn’t enabled for your organization yet.

Create a key

Under Email → Send keys in the Console, or with the CLI:

lbr email send-key mint "production api"

Minting returns the secret in the form lpk_<key_id>.<secret>:

lpk_a1b2c3d4.9f8e7d6c5b4a39281706f5e4d3c2b1a0

The two halves matter separately: lpk_a1b2c3d4 is the key id (the public half, and the SMTP username), and the whole string is the secret you send with.

Important: The secret is revealed once, at mint, and never again — it’s hashed at rest, so we can’t show it to you later. Store it now in your secret manager or your app’s environment. If you lose it, revoke the key and mint a replacement.

Minting a send key is an admin-tier action, because a long-lived sending credential is a real escalation. It also requires an active payment method on the Org — the same provisioning gate as creating a cluster. Receiving needs neither.

Use a key

The same secret opens both front doors:

• HTTPS API — send it as a bearer token: Authorization: Bearer lpk_a1b2c3d4.9f8e...
• SMTP — the username is the key id (lpk_a1b2c3d4) and the password is the whole secret. One credential, two doors.

Sending mail has the full request shapes for each.

Restrict a key to domains

By default a key may send from any send-verified domain in the Org. You can pin a key to specific domains instead — useful when a key belongs to one service, or when you want a staging key that can’t send from your production domain. Pass one or more domain ids at mint:

lbr email send-key mint "staging worker" \
  --domain dom_staging1 --domain dom_staging2

A restricted key that tries to send from a domain outside its set is rejected at accept with a 403. The restriction is fixed at mint — to change which domains a key covers, mint a new key with the set you want and revoke the old one.

Revoke a key

Revoking a key stops it working immediately — every send with it is refused from that moment. Revoke from the Console, or:

lbr email send-key revoke <key-id>

Revocation is a tombstone: the key id is retired for good and can’t be reactivated. Do this the instant a secret leaks. Like minting, revoking is an admin-tier action.

Rotate a key with no downtime

Send keys don’t expire on a timer, so rotate them on your own schedule — and always after a suspected leak. Because a key’s domain restriction is immutable and its secret is reveal-once, rotation is mint-new, then revoke-old rather than an in-place reset:

1. Mint a new key with the same name and domain set.
2. Deploy the new secret to your application.
3. Confirm the new key is sending (watch the message log, or the key’s last used timestamp).
4. Revoke the old key.

Running both keys briefly in parallel means no send fails mid-rotation. If you manage keys with Terraform, the provider automates exactly this overlap — see Terraform.

Where to next

• Sending mail — send with the key over the API or SMTP.
• Terraform — declare and rotate keys as code.
• CLI — the full lbr email send-key command set.