Testing SMTP from Linux with swaks or OpenSSL means you prove the dashboard host accepts TLS and authentication for a hosted identity, then you submit one unique message. This is your MailerZ account, not a stranger's relay. Copy host, port, and TLS mode from the dashboard. Do not invent 587. Free has no send-as. Use a dedicated test secret when you can. Keep passwords out of shell history. Read 235, 550 5.7.1, and timeouts as different tickets. Do not add leftover MX because a prompt failed.
One unique third-mailbox message is the whole test. A loop is a cap incident. Redact the transcript before it hits Slack.
Quick answer for test SMTP Linux swaks OpenSSL
Copy the MailerZ host, port, and TLS mode. On a paid plan, authenticate as the dashboard user. Send one unique subject to a mailbox you do not own.
If AUTH fails, diagnose like WordPress: plan, secret, TLS, identity, path. Do not edit MX.
If you only need to see the banner and the certificate, OpenSSL s_client to the printed host and port is enough. Stop before you paste a password into a recorded session.
SMTP: IETF RFC 5321 — Simple Mail Transfer Protocol. Paths: send and reply, docs, troubleshooting.
User problem and decision criteria
Plugins lie. Hosting panels lie. A shell transcript against the dashboard is the shortest proof the hop is reachable from that network.
Decision criteria: you own the account, you can copy dashboard values, you can rotate the secret after a sloppy paste, you will not test strangers' servers, you will not loop until you hit the monthly cap.
If you are on Free, the test should fail AUTH. That is a pass for the plan check.
If you need to prove inbound, this is the wrong tool. Use a third mailbox to an alias and read hop history.
If you need to prove Gmail send-as, use Gmail's UI plus this test as a second path, not a replacement.
If the origin is production WordPress, a Linux box in another network only proves that other network.
What the tools actually speak
SMTP is a line protocol. You connect, you may upgrade to TLS, you AUTH, you MAIL FROM, you RCPT TO, you DATA. Replies are three-digit codes. RFC 5321 is the map.
swaks will do those verbs for you. OpenSSL s_client gives you a TLS pipe and a keyboard. Both are fine. Both will store passwords if you type them carelessly.
MailerZ expects an authorized identity. MAIL FROM or From that is not hosted gets 550. That is the product.
STARTTLS versus implicit TLS is whatever the dashboard printed. Mixing them produces timeouts or handshake failures that look like AUTH if you skim.
A 250 after DATA is hop acceptance, not inbox placement. Open the third mailbox.
Step-by-step path
- Confirm paid send-as or accept that Free must fail AUTH.
- Copy dashboard host, port, TLS mode, username.
- Create a short-lived test password if the product lets you. Otherwise plan to rotate after.
- Disable shell history for the session or use a file descriptor the shell will not log. Do not put the password in the command line if you can avoid it.
- Connect with swaks or OpenSSL using the printed TLS mode only.
- Prove AUTH fail with a wrong secret. Prove AUTH success with the right one.
- Submit one unique subject to a third mailbox. Stop. Do not loop.
- Redact the transcript. File it. Open the mailbox.
- Rotate the secret if it appeared in history or a ticket.
- If this was to debug WordPress, paste the same values into the plugin only after the shell succeeded from a similar network.
Failure modes and proof
Password on the command line in a shared tmux. Rotate. Proof: history file.
Tested from a laptop, WordPress still fails. Path differs. Proof: run from the origin or accept two tickets.
Hit the hourly cap with a script. That is you. Confirm /pricing. Do not call it an outage.
Added leftover MX because AUTH failed. Now inbound is split. Roll that back first.
Used a stranger's hostname from a blog. You are now knocking on the wrong hop. Use the dashboard.
Proof: redacted transcript, unique message ID, plan name, dashboard match.
MailerZ workflow and product boundary
You may test your own authenticated SMTP. You may not use this article as a reason to probe random internet MX with AUTH.
Low volume. Caps. Not an open relay. Not IMAP. Not SOC 2.
Inbound history will not show a send you never authenticated.
Support wants the redacted transcript. Support does not want your password.
Dashboard values are the source. Community ports are not.
If you need a watch script, still respect caps and secrets. A cron that AUTH-fails every minute is an incident you wrote.
Cost and alternatives
swaks and OpenSSL are free. The hop is not if you need send-as.
Plugin tests are easier and easier to fake with fallback. Shell is the tie-breaker.
GUI tools on Windows are fine if they keep a transcript. This page is Linux-shaped because the keyword is.
A full mail client test is also valid and hides SMTP verbs. Use both when a human must see the inbox.
Paying for a transactional API with official CLIs makes sense at volume. Do not pretend swaks is a campaign runner.
Time spent looping tests can cost more than Solo. One unique message is the unit.
Worked scenarios
Auth fail on Free: plan confirmed. Test passed as a negative. Upgrade. Retest once.
Auth fail on paid: typo in username. Dashboard paste fixed it. WordPress then worked.
Timeout from WordPress, success from a home Linux: host firewall. Open the printed port on the origin.
Success in swaks, host-From in WordPress: plugin fallback. Disable it.
Someone scripted 200 tests and hit the cap. The transcript is the incident. Wait or upgrade. Do not add a second vendor mid-fire.
Practice and anti-patterns
Practice: dashboard paste. Anti-pattern: remembered ports.
Practice: history hygiene. Anti-pattern: -ap yourpassword.
Practice: one unique message. Anti-pattern: a while loop.
Practice: third mailbox. Anti-pattern: mail to root@localhost.
Practice: redact transcripts. Anti-pattern: Slack with AUTH PLAIN blobs.
Practice: rotate after sloppy paste. Anti-pattern: hope.
Practice: your account only. Anti-pattern: scanning strangers.
Operator closeout
Redacted transcript filed. Unique message opened. Plan named. Secret rotated if exposed. WordPress updated if that was the point.
Deputy can repeat without the password in argv.
Caps respected. No leftover MX added.
Review date if this is a quarterly probe. Same subject pattern so you can search.
Edge cases
Corporate SSL inspection breaks s_client. Use a network without it or install the inspection CA. Do not disable TLS.
IPv6 first, host A-only. Force the family the host supports or fix DNS.
Locale that mangles From in the terminal. Use ASCII subjects for the test.
swaks version too old for the TLS mode. Upgrade swaks. Do not downgrade TLS folklore.
OpenSSL s_client to the wrong SNI. Use the dashboard hostname.
CI runner that logs all argv. Use secrets manager. Rotate after the first leak.
Field notes
The useful transcript is boring: banner, TLS, 235, 250, unique subject.
The useful negative is one wrong password. Not twenty.
Juniors paste AUTH lines into tickets. Redact for them until they learn.
A successful shell test does not prove WooCommerce. It proves the hop from that OS.
If you cannot install swaks, OpenSSL plus care is enough. If you cannot be careful, do not use OpenSSL.
Caps are not a challenge. They are a wall.
Leftover MX tickets opened during an SMTP test are how agencies get famous.
Handoff memo
Dashboard URL, plan, test identity, TLS mode, where secrets live, history policy, last transcript path, last unique subject, who may run this.
Forbidden: argv passwords, loops, stranger hosts, MX edits, php mail.
The lab loop: fail AUTH, succeed AUTH, open mailbox, redact, rotate if needed.
Acceptance criteria
Transcript matches dashboard. Paid plan or documented Free negative. Unique third-mailbox proof. Secrets not in history. No leftover MX change.
If WordPress was the goal, plugin values match the successful shell.
Deputy can run the lab loop.
Operations review of shell tests
If a transcript lives in a ticket, confirm it is redacted. Test SMTP Linux swaks OpenSSL work that leaves AUTH PLAIN in Slack is an incident.
If a password was on argv, rotate even if you think history is off. Shared tmux lies.
If you tested from a laptop, do not close a WordPress ticket. Run from a similar origin or keep two tickets.
If a cron test exists, confirm it sends one message, respects caps, and pulls secrets from a manager.
If Free is still the plan, a failed AUTH is the expected quarterly probe. Do not 'fix' it with leftover MX.
If you hit a cap looping, write the loop as the cause. Wait or upgrade.
If OpenSSL s_client sessions were recorded, treat them as secret material.
If CI logs argv, fix CI before the next test.
If stranger hosts appeared in history, stop. This article is your account only.
If inbound was 'tested' by editing MX, undo that first.
Quarterly review
One unique paid-plan message, one wrong-secret 5xx, dashboard match, history clean, third mailbox opened.
Deputy can run the lab loop without argv passwords.
WordPress values match the last successful shell if that was the point.
Caps versus test frequency written. No while loops.
TLS mode still matches the dashboard. Folklore ports still forbidden.
Inspection CA documented if corporate TLS breaks s_client.
Review date next to domain renewal.
Closing notes
A Linux SMTP test is a dated, redacted transcript against dashboard values on a paid plan, plus one opened third-mailbox message.
Do not invent 587. Do not loop. Do not scan strangers. Do not add leftover MX because a prompt failed.
Start free for inbound. Upgrade for send-as. Then keep secrets out of history.
Field depth on transcripts
The useful transcript is short. Banner, TLS, 235, MAIL, RCPT, DATA, 250, unique subject. Test SMTP Linux swaks OpenSSL work that includes twenty AUTH fails is a cap incident, not thoroughness.
OpenSSL s_client will not remind you to AUTH. People send unauthenticated MAIL and call MailerZ broken. MailerZ is not an open relay. Type AUTH or use swaks.
SNI must be the dashboard hostname. A raw IP test can fail TLS for the wrong reason.
Corporate inspection requires the inspection CA. Disabling TLS to 'see' is not a test. It is a different protocol.
IPv6-first laptops versus A-only hosts look like AUTH if you skim. Read the connect error.
CI that echoes commands will publish secrets. Use a secrets manager and assume the first run leaked.
A successful shell from home does not close a WordPress-on-VPS ticket. Networks differ.
Looping to 'be sure' hits hourly caps. One unique message is sure enough.
People and deputies
Who may run tests, where secrets live, who redacts, who rotates after a sloppy paste.
Juniors paste AUTH PLAIN into Slack. Pair with them until they redact without being asked.
On-call must know this is our account only. Stranger MX AUTH is out of scope and out of policy.
WordPress owners need the same five fields the shell used. Deputies copy, they do not remember ports.
If two engineers share a test identity, rotate when either leaves.
Proof packet
Redacted transcript, unique third-mailbox proof, plan name, dashboard match, history clean, no MX edits, cap respected.
If WordPress was the goal, plugin screenshot matches the shell.
Wrong-secret 5xx included so fallback cannot hide.
Appendix
Appendix: never put the password in argv if you can avoid it. Assume shared tmux recorded it anyway and rotate after sloppy sessions.
Appendix: one unique message is the unit. A while loop is a cap incident.
Appendix: OpenSSL without AUTH is not a send test. MailerZ is not an open relay.
Appendix: SNI is the dashboard hostname. Raw IPs fail TLS for the wrong reason.
Appendix: corporate inspection needs the inspection CA. Do not disable TLS.
Appendix: IPv6-first clients versus A-only hosts are connect errors, not 535.
Appendix: CI that echoes commands leaked. Fix CI, rotate, then test.
Appendix: home-network success does not close a VPS WordPress ticket.
Appendix: stranger hosts are out of policy. This is your account.
Appendix: inbound is a third-mailbox alias test, not an MX edit during SMTP.
Appendix: Free AUTH fail is a plan probe. Do not 'fix' it.
Appendix: redact transcripts before Slack. AUTH PLAIN is a secret.
Appendix: swaks too old for the TLS mode: upgrade swaks, not folklore.
Appendix: locale-mangled From in a terminal: use ASCII for the test subject.
Appendix: cron tests must use a secrets manager and send one message.
Appendix: after a sloppy paste, rotate even if you 'unset HISTFILE' late.
Final pass
Final pass: redacted transcript, unique third-mailbox proof, dashboard match, paid plan or documented Free negative, history clean, no MX edits.
Wrong-secret 5xx included. WordPress matches the shell if that was the goal.
Keep secrets out of history. Keep leftover MX out of the ticket.
Extended operator narrative
A Linux SMTP test is a legal and operational act on your own MailerZ account. It is not a reason to AUTH against stranger MX, not a port scan, and not a load test. Copy dashboard host, port, and TLS. Use a short-lived secret if you can. Keep the password off argv. If it hit history or tmux or CI logs, rotate. Send one unique message to a third mailbox. Stop. Read 235, 550 5.7.1, and connect errors as different tickets. Do not edit inbound MX because a prompt failed.
OpenSSL s_client proves TLS and gives you a keyboard. If you never AUTH, you are not testing send-as. MailerZ is not an open relay. swaks is less error-prone for AUTH. Either tool stores secrets if you are sloppy. Redact transcripts. Do not paste AUTH PLAIN into Slack. Corporate inspection needs the inspection CA. IPv6-first laptops versus A-only hosts fail at connect. SNI is the dashboard hostname. Folklore ports are not a source.
A successful shell from home does not close a WordPress-on-VPS ticket. Networks differ. Caps differ from loops. Free AUTH fail is a plan probe, not a TLS mystery. After the shell works from a similar origin, paste the same five fields into the plugin and disable php mail fallback. Then open the third mailbox. 250 is hop acceptance, not inbox placement.
Cron and CI are how tests become incidents. One message, secrets manager, no argv echo, respect hourly caps. If you already looped two hundred times, the transcript is the incident. Wait or upgrade. Confirm /pricing. Do not add a second vendor mid-fire. Do not call support until the transcript is redacted and the plan is named.
Handoff: dashboard URL, plan, test identity, TLS mode, history policy, last unique subject, who may run this, forbidden list in bold. Lab loop: fail AUTH, succeed AUTH, open mailbox, redact, rotate if needed. Review quarterly. Keep leftover MX out of the folder named smtp-tests.
More operator notes
Write a two-line policy above the examples in your internal wiki: our account only, one unique message. Test SMTP Linux swaks OpenSSL pages that omit those lines grow loops and stranger hosts. Add history hygiene and redact-before-Slack. Add rotate-after-sloppy-paste. That is more important than which binary you like.
If WordPress is the reason you opened a shell, the shell is a tie-breaker, not a replacement for origin-path truth. After AUTH works from a similar network, paste the same five fields into the plugin, disable fallback, and open the third mailbox. If WooCommerce still fails, you have another library, not a broken hop.
CI and cron must pull secrets from a manager and must not echo argv. Assume the first sloppy run leaked. Rotate. Caps apply to robots too. A monitoring probe that AUTH-fails every minute is an incident you scheduled. Prefer a weekly unique send you can search.
File the redacted transcript with the plan name. Include a wrong-secret 5xx so fallback cannot hide. No MX edits in the folder. Review quarterly. Keep folklore ports out of the runbook.
One last note
One last note: our account, one unique message, secrets off argv, transcript redacted. Test SMTP Linux swaks OpenSSL work that violates those four rules becomes an incident even when the hop is healthy. Add rotate-after-sloppy-paste. Add no-stranger-hosts. Add no-MX-edits. Write them above any example command you keep internally.
Use swaks when you want AUTH done for you. Use OpenSSL when you need to see the certificate and you will remember to AUTH. Either way, SNI is the dashboard hostname, TLS mode is the dashboard mode, and folklore 587 is not a source. Free AUTH fail is a plan probe. Caps apply to loops and to cron.
A home-network 250 does not close a VPS WordPress ticket. After the shell works from a similar origin, paste the same fields into the plugin, disable fallback, and open a third mailbox. 250 is not inbox placement. If WooCommerce still fails, hunt the other library.
CI that echoes commands leaked. Fix CI, rotate, then test. Corporate inspection needs the inspection CA. IPv6-first clients can fail at connect. Label those path. Keep leftover MX out of the smtp-tests folder.
Start free for inbound. Upgrade for send-as. File the redacted transcript with the plan name. Review quarterly. Keep the test boring.
Last checks
Last check: redacted transcript, one unique third-mailbox message, wrong-secret 5xx, dashboard match, history clean. Test SMTP Linux swaks OpenSSL closeout is that list.
Last check: no stranger hosts, no loops, no MX edits, no argv password left behind. If a secret leaked, it was rotated.
Last check: WordPress matches the shell if that was the goal. Caps respected. Plan named. Review dated.
Endnote
Endnote: the internal wiki should show policy before commands. Our account. One message. Redact. Rotate if sloppy. No stranger hosts. No MX edits. That is a finished test SMTP Linux swaks OpenSSL session.
If WordPress is why you are here, the shell is a tie-breaker. Match the plugin after, not before. Open the third mailbox. 250 is not inboxing. Caps are walls. Confirm /pricing if you already looped.
FAQ
What is the safest way to handle test SMTP Linux swaks OpenSSL?
Copy dashboard values, use a test identity on a paid plan, keep secrets out of history, read the reply codes, send one unique message to a third mailbox.
Does this require a new mailbox?
No. The test mailbox should be a third party. MailerZ is not IMAP.
Will it work with Gmail or Outlook as recipients?
Yes. Self-send can lie after a 250. Open the original at a third provider.
What DNS records are involved?
None for a pure outbound test. Inbound exclusive MX matters when you want replies. SPF and DKIM follow the dashboard when you send-as.
What should you test before production?
TLS as printed, AUTH success, AUTH fail with a wrong secret, one unique 250, and no leftover MX added.
Is OpenSSL s_client enough?
It proves TLS and lets you type SMTP by hand. swaks is less error-prone for AUTH. Use either. Keep a transcript.
Key takeaways
- Dashboard values only. No folklore ports.
- Paid send-as. Free will fail AUTH on purpose.
- Keep secrets out of bash history.
- 235, 550 5.7.1, and timeout are different.
- Third mailbox. Self-send lies.
- This is your account. Not a scan of strangers.
- Leftover MX is not an SMTP test fix.
- Confirm /pricing and caps before a loop of tests.
Conclusion and next action
A Linux SMTP test is a dated transcript against dashboard values on a paid plan. MailerZ will 550 unauthorized senders. swaks will not fix leftover inbound MX. Start free, upgrade, then keep a redacted transcript in the ticket.
Prove the hop from a shell
Start free for inbound, pay for send-as, then test from Linux with dashboard values.
Copy the dashboard. Use a third mailbox. Sign in if the domain is already hosted.
Review quarterly, or sooner if provider behavior, pricing, or MailerZ scope changes. Author: MailerZ editorial, Secuno LLC.