# Sharing credentials with support safely

Source: https://catalystgroup.gg/docs/email-delivery/sharing-credentials-safely/
Updated: 2026-10-19 · By Duane Garner

How to give support access to your site without exposing passwords or API keys, and how to remove that access afterwards.

Sometimes the fastest way to fix an email problem is to let someone look at your site. This article shows you how to give that access safely, what never to share, and how to tidy up afterwards. It is for anyone working with our support team, or with any developer or agency.

 

## The golden rules

 
1. **Never send passwords or API keys by email, chat or a support ticket.** Messages are stored in many places and are easily forwarded. A leaked mail-service key lets anyone send spam in your name.
2. **Give a separate account, never your own login.** Then you can remove it without changing your own password.
3. **Give access for as short a time as possible,** and remove it as soon as the work is done.
4. **Rotate anything you did share.** If a key or password was exposed, even by accident, replace it.

 

## Do we need access at all?

 

Often we do not. Many problems are solved from the error text alone. Before creating any account, send us:

 
- The error from **Copy error log** on the failed-send banner, or from **CRM-NG SMTP → Tools → Debug Events**.
- The CRM-NG SMTP section and versions from **Tools → Site Health → Info** (the **Copy site info to clipboard** button).
- Your mailer name and, for Other SMTP, the host, port and encryption, but **not** the password.

 

See [Debugging sending issues](https://catalystgroup.gg/docs/email-delivery/debugging-sending-issues/) for the full list.

 

## Check logs before you share them

 

Debug logs and site information can contain sensitive values. Before you paste them anywhere, read them and remove:

 
- Anything labelled password, pass, secret, key, token or authorization.
- Long strings of random-looking letters and numbers.
- Lines from an SMTP conversation that start with `AUTH`, and the line after them. These can contain your login in an encoded (not encrypted) form.

 

Replace them with `[removed]`. We never need the real values to read a log.

 

## Giving temporary access to WordPress

 

If we do need to look at your settings:

 
1. Create a new user
  Go to **Users → Add New User**. Use a username such as `support-temp` and the email address our support team gives you.
2. Choose the role
  CRM-NG SMTP's screens need the **Administrator** role, because they can change how the whole site sends email.
3. Set a strong password
  Let WordPress generate one.
4. Share the password safely
  Use a one-time secret link (a service that shows the text once and then deletes it) or a shared password manager vault. Send the link and the username in separate messages.
5. Tell us when it expires
  Agree a time, for example 48 hours.

 

Some security and login plugins can create time-limited login links that expire on their own. If you use one, that is even better.

 

## Mail-service keys and passwords

 

We should almost never need the key to your mail service itself. If someone does need it to test something:

 
- Create a **new, separate key** at the provider just for this, with the smallest permission that works (for example "send only"). Many services let you create several keys.
- Share it with a one-time secret link, never in plain text.
- Delete that key at the provider as soon as the work is done.

 

For Google, Microsoft 365 and other sign-in based mailers, nobody needs your account password. The connection uses an app and a client secret, which you can replace at any time.

 

## After the work is done

 
1. Delete the temporary user
  Go to **Users**, hover over the account and click **Delete**. When asked, attribute any content to your own account.
2. Remove temporary keys
  Delete any key you created for support at the mail service.
3. Rotate anything exposed
  If a password or key was shared in plain text by mistake, change it at the provider, then paste the new one into **CRM-NG SMTP → Settings → General** and send a test email.
4. Turn debugging off
  If you enabled **Debug Email Sending** on **CRM-NG SMTP → Tools → Debug Events**, untick it and save.

 

## Keep secrets out of the database

 

For extra protection, you can define your mail-service keys in `wp-config.php` instead of the settings screen. They then never appear in the database or in a database backup you might share. See [Securing settings with wp-config constants](https://catalystgroup.gg/docs/email-delivery/secure-settings-constants/).

 

## Contact support

 

Open a request at [catalystgroup.gg/support](https://catalystgroup.gg/support/). We will never ask you to email a password.

 

## Related

 
- [Debugging sending issues](https://catalystgroup.gg/docs/email-delivery/debugging-sending-issues/)
- [What the plugin stores and sends](https://catalystgroup.gg/docs/email-delivery/privacy-and-data/)
- [Securing settings with wp-config constants](https://catalystgroup.gg/docs/email-delivery/secure-settings-constants/)
- [Troubleshooting email delivery](https://catalystgroup.gg/docs/email-delivery/troubleshooting/)
