SMTP credential password lost or leaked: revoke it, create a new one and update the program

Security·· 92 views· 3 min read

The short answer: the password of an SMTP credential cannot be recovered, not even by us: it is only shown when you create it, and what we keep is an encrypted version that cannot be reversed. If you lost it, create a new credential, swap it into the program and only then revoke the old one. If the password leaked, the order changes: revoke first.

You lost the password, but nobody saw it

There is no rush here, and the goal is to keep sending without a break:

1 Create a new credential, with a name that tells it apart (for example, «Main website, November»). Copy the username and password.
2 Swap it into the program: username and password. The server and port stay the same.
3 Send a test and check in the Email Center log that it went out.
4 Revoke the old credential. The Last used column helps you confirm nobody is using it any more.

The password leaked

Leaked means someone else may have it: it ended up in a public repository, in a .env file that opened in a browser, in a screenshot, in an e-mail sent to the wrong person. It also counts as leaked if the log shows e-mails you did not send.

1 Revoke the credential now. The program stops sending for a few minutes, but whoever has the password also loses the ability to send in your name.
2 Create a new credential and put it in the program.
3 Check the Email Center log for the last few days: odd recipients, subjects that are not yours, a sudden wave of bounces.
4 Close the leak: remove the password from the repository (and its history), move the .env file out of the public folder, delete the screenshot.
Spam sent with your credential leaves from your verified domain. Complaints and bounces are tied to it, and it is your domain reputation that suffers. That is why a leaked password is revoked at once, even if the website stops for a few minutes.

So it does not happen again

Where to keep it How
Applications In a .env file outside the public folder, never in the code or the repository.
Team In a shared password manager, not in a spreadsheet or a chat group.
Asking for help Never paste the password into a support ticket or a screenshot. We do not need it to help you.
The same thinking applies to API keys: see an API key has leaked.

Seeing e-mails in the log that you did not send? Revoke the credential and open a ticket: we will help you work out what went out.

Open a support ticket

SEE ALSO

One SMTP credential per program: naming, organising and revoking only the one you stop using

The program says sent, the customer got nothing: finding SMTP e-mails in the Email Center log

An API key or token has leaked: what to do, in the right order

Someone is sending e-mail in the name of your domain: what SPF, DKIM and DMARC do about it

Testing an SMTP credential before going live: a test e-mail from the command line

RECOMMENDED PRODUCT

Professional e-mail on your domain

Mailboxes in your company name, no adverts, with spam filtering. from R118.80/mo (3-year plan, with coupon)

See plans
Was this answer helpful? Your answer helps us improve this article.

Related Articles

Security 2,328 What is an SSL certificate and why does it matter? An SSL certificate encrypts the connection between a visitor's browser and your site, so passwords, card numbers and any...
Security 2,371 Why does my SSL certificate show fewer than 365 days? If you're on the free SSL every account gets by default, this doesn't apply to you - skip to the note below. This is onl...
Security 3,979 How to redirect HTTP to HTTPS with .htaccess This forces every visitor to the encrypted version of your site, even if they type or link to the plain http:// address....
Security 2,257 How to tell if your site has been compromised Most infections don't announce themselves - they show up as small, odd symptoms before anything looks obviously wrong. S...
Security 2,139 How to clean up a compromised site Cleaning up is only half the job - if the door that let the infection in stays open, it comes back. Work through this in...
Security 77 What never to put in a transactional SMS: passwords, full card numbers and private details The short answer: in a transactional SMS, never include passwords, PINs, full card or account numbers, ID document numbe...