If your SMTP key leaks

An SMTP key lets an application send mail as your domain. Anyone who has the key can do the same, from anywhere, which is why we watch how each key behaves and why we look for keys in places they should not be.

You are probably reading this because you received one of two security notices:

• "We paused your SMTP key" — the key started behaving unlike itself, so its mail is being held while you decide.
• "We revoked your SMTP key: it was in a public repository" — the key was found in public code, so it has already been turned off.

Both go to the organization's owner and admins. Neither can be turned off in notification settings, because the person they are for is the one who did not know.

A pause. Each key is compared with its own last seven days. If, in one hour, it sends far more than its busiest hour, reaches far more domains than usual, or sends from a computer it has never used before — and two of those three are true at once — the key is paused. It still signs in, but its mail is held, not bounced, and nothing has been lost. The pause lifts by itself after about six hours, or the moment you press Resume sending. The notice says which of the three tripped, in plain words, so you can tell your own campaign from somebody else's computer.

A revoke for a leak. Every key made since September 2026 starts with mlt_, which lets GitHub recognise one in any public repository and tell us within minutes. When that happens we revoke the key on the spot: it stops signing in immediately, any mail it still had waiting to go out is removed, and the notice tells you where it was found. Keys made before then do not start with mlt_ and cannot be recognised this way — one more reason to replace old keys with new ones.

What you can see on the keys page. Under Last used, each key shows the address it last sent from and how many different addresses it sent from in the last 30 days. One application on one server is one address. Several addresses is not proof of anything, but it is the question to ask: does everything that holds this key have a reason to?

There is nothing to set up for the watching itself. What you decide is how much a key can do if it does leak:

1. Give every key a daily cap sized to the job. The form asks for one; it is what limits the damage.
2. Restrict it to an IP address when the application runs on a fixed server. Open the key, choose Edit, turn on "Restrict to specific IP addresses". Anyone else holding the key is then locked out.
3. Set an expiry for a key given to a tool, an agent or a contractor. A key made for a job that ends should end with it, on a day you chose, instead of on the day someone finds it.
4. One key per application. When one leaks, you revoke one, and the others keep working.

If the key is going to an AI tool or an automation, read Giving a key to an AI tool or an agent first. It covers what such a tool can and cannot be trusted with.

You were told a key was paused, and it was you. Press Resume sending in the notice or on the keys page. The held mail goes out; nothing was lost. If the same campaign trips the pause again, the key is paused again — that is the rule working, not a fault. Raise the key's daily cap to what the job actually needs, or split the sending across keys.

You were told a key was paused, and it was not you. Do not resume it. Press Revoke and replace: revoking stops the next sign-in immediately and deletes the mail the key still had waiting. Then create a new key and update the application. Ask support for the list of what went out — recipients, count, first and last time — so you can tell your own customers what they may have received.

You were told a key was found in a public repository. It is already revoked and its waiting mail is already gone; there is nothing to resume. Three things to do now, in order:

1. Create a new key and put it in the application, with a cap and, if the server has a fixed address, an IP restriction.
2. Remove the old key from that code. The notice links to the exact file. Take it out of the current version and, if the repository is one you control, out of the history too — a revoked key left in public code keeps being found and reported. Move the new one to an environment variable or a secrets store, never into the repository.
3. Replace it everywhere else it lived. A key that was in one place is usually in another: a .env file on a laptop, a chat message, a shared document, another tool's settings. Anything that used the old key needs the new one.

A key shows "used from several addresses" and you did not expect that. Check what holds the key. If you cannot account for every address, treat it as leaked: revoke, replace, and restrict the new one to the addresses you can account for.

Your application says authentication failed after one of these. That is the revoke doing its job. It needs the new key; the old one cannot be turned back on for you and its password cannot be recovered.

You revoked a key by mistake. A revoked key can be re-enabled from the keys page, under its actions, unless we revoked it for a leak — a key that has been in public code stays revoked, and the fix is a new one.

• Senders and SMTP credentials — creating a key, the host and port, the one thing you must copy at once
• Giving a key to an AI tool or an agent — caps, restrictions and expiry for a key you hand to software you do not control
• API keys — the other kind of key, for the API rather than SMTP, and the same habits
• Go to SMTP keys