Three things have to happen, in this order: the domain gets verified, a credential gets issued, and your application's mailer gets four new settings. Everything below is copy-paste.
This is enforced, not encouraged. The relay will not issue you a credential — and would not sign your mail if it had — until the domain you intend to send from is verified. It is the one thing standing between a shared relay and an open one.
Go to Sending → Domains and add the domain your app sends from — the domain in your
From: header, not the one your site is hosted on. CleverlyBox generates a DKIM key pair and
shows you the DNS records to publish: a DKIM TXT record, an SPF include, and the ownership
record. Publish all of them at your DNS provider.
Nobody approves this by hand. Once the records propagate — usually minutes, occasionally an hour if your provider is slow — the domain flips to verified on its own. If it does not, the dashboard shows which specific record it could not find, which is nearly always a copy-paste that dropped a trailing character.
Go to Sending → SMTP Relay and issue a credential. A username and a generated password appear
on screen. That is the only time you will ever see the password. We store a hash
of it, not the value, so there is no "show me again" button and no support ticket that can recover it —
copy it into your secret manager or your .env before you close the dialog.
Lost it? Rotate the credential. Rotation issues a fresh password and invalidates the old one immediately — so rotate during a deploy window, not during a checkout rush. Revoking is the harder stop: the credential stops authenticating at once, and any app still using it starts failing on connect.
You get 2 credentials on Business and 10 on Agency. Use them: one per application, or one per client. Each is metered and monitored separately, so when something misbehaves you can revoke exactly the thing that misbehaved instead of taking all your mail down with it.
| Host | smtp.cleverlybox.com |
| Port | 587 (STARTTLS) or 465 (implicit TLS) |
| Encryption | TLS — required on both ports |
| Username | the credential username from your dashboard |
| Password | the password shown once at issue |
| From address | any address at your verified sending domain |
587 or 465? Use 587 unless something forces your hand. It starts in the clear and upgrades to TLS with STARTTLS, and it is what nearly every mail library expects by default. Reach for 465 when your client wants TLS from the first byte (some WordPress plugins and older libraries do) — set the encryption mode to SSL/TLS rather than STARTTLS when you do, or the handshake will fail in a way that looks like a wrong password.
MAIL_MAILER=smtp MAIL_HOST=smtp.cleverlybox.com MAIL_PORT=587 MAIL_USERNAME=your-credential-username MAIL_PASSWORD=your-credential-password MAIL_ENCRYPTION=tls MAIL_FROM_ADDRESS=hello@your-verified-domain.com MAIL_FROM_NAME="Your App" # then clear the cached config, or it will keep using the old mailer php artisan config:clear
| Mailer | Other SMTP |
| SMTP Host | smtp.cleverlybox.com |
| Encryption | TLS |
| SMTP Port | 587 |
| Authentication | ON |
| SMTP Username | your credential username |
| SMTP Password | your credential password |
| From Email | an address at your verified domain |
Send the plugin's own test email before you trust it. If WP Mail SMTP is storing the password in
wp-config.php rather than the database, use its constant — a plugin update should not
be able to wipe your mail config.
const transporter = nodemailer.createTransport({ host: 'smtp.cleverlybox.com', port: 587, secure: false, // false on 587 — STARTTLS upgrades the connection requireTLS: true, // refuse to send if the upgrade doesn't happen auth: { user: process.env.CLB_RELAY_USER, pass: process.env.CLB_RELAY_PASS, }, }); // on port 465 instead: secure: true, and drop requireTLS
$mail = new PHPMailer(true); $mail->isSMTP(); $mail->Host = 'smtp.cleverlybox.com'; $mail->SMTPAuth = true; $mail->Username = getenv('CLB_RELAY_USER'); $mail->Password = getenv('CLB_RELAY_PASS'); $mail->SMTPSecure = PHPMailer::ENCRYPTION_STARTTLS; $mail->Port = 587; $mail->setFrom('[email protected]', 'Your App');
The credential is wrong, rotated, revoked, or suspended. In that order of likelihood. Check the SMTP Relay page in your dashboard: if the credential shows as suspended, our reputation monitoring stopped it because its bounce or complaint rate crossed the threshold — fix the underlying list or loop first, because re-issuing a credential and sending the same mail through it will suspend the new one too. If it shows as active, you are almost certainly sending a stale password from a cached config.
Two causes, and the meter tells you which. Out of volume: once your monthly allowance and any
top-up credits are spent, further messages are dropped — not queued, not retried — and counted as
rejected against the credential. Unverified domain: if the From: address is on a
domain that is not verified, the message will not be signed or relayed. Both show up in the usage
meter rather than as an SMTP error, which is why the meter is the first place to look.
Your client is trying to STARTTLS on a port that expects TLS from the first byte. Set the encryption mode to SSL/TLS (not STARTTLS) on 465, or just move to 587 and use STARTTLS. The reverse mistake — implicit TLS on 587 — produces the same class of unhelpful error.
You are hitting the rate ceiling — 500/hr on Business, 2,000/hr on Agency. That ceiling exists to make a runaway loop in your code cheap instead of catastrophic. If your legitimate traffic genuinely needs more headroom, that is a plan conversation, not a bug.
The usage meter on the SMTP Relay page: messages sent this cycle, what remains of your monthly allowance, top-up credits in hand, and the rejection counters. It is the same number we meter you on — there is no second, private ledger.
Included on Business and Agency, with 10,000 and 50,000 relay messages a month.