Greeting checks and connection capacity for SMTP, submission, IMAP and POP3, including the implicit-TLS ports.
Category MailStack Postfix, Exim, Dovecot, Courier, Sendmail, Stalwart, ExchangeJobs 22
Load tests the mail protocols of Postfix, Exim, Dovecot, Courier, Sendmail, Stalwart or Exchange: greeting checks for SMTP, submission, IMAP and POP3, accepting connections on the implicit-TLS ports, and inbound connection ramps on ports 25 and 143. It shows how many simultaneous connections the server accepts before it refuses them.
It holds 22 ready-made jobs: 9 single scenarios and an enterprise test plan of 13 stages to run in order, 8 of them with pass/fail targets (SLOs). Each job is a plain request pattern you can change before running.
Scenarios include SMTP greeting (port 25), submission greeting (port 587), SMTPS accept (port 465), IMAP greeting (port 143) and IMAPS accept (port 993).
host to point at your own Mail servers system, ideally a staging copy.hostsmtpPortsubmissionPortsmtpsPortimapPortimapsPortpop3Portpop3sPortNo mail is sent: this reads the greeting only. Mail servers throttle and ban noisy clients (per-IP connection limits, postscreen, fail2ban), so run from a whitelisted address; a '421 too many connections' reply is counted as an error and shows the limit works. Checks for the 220 greeting: the cost of every inbound delivery attempt, and what spam bots hammer.
No mail is sent: this reads the greeting only. Mail servers throttle and ban noisy clients (per-IP connection limits, postscreen, fail2ban), so run from a whitelisted address; a '421 too many connections' reply is counted as an error and shows the limit works. Where authenticated users send mail. Usually has stricter limits than port 25.
Implicit TLS: the server waits for a ClientHello, so only the TCP accept is timed, not a greeting.
No mail is sent: this reads the greeting only. Mail servers throttle and ban noisy clients (per-IP connection limits, postscreen, fail2ban), so run from a whitelisted address; a '421 too many connections' reply is counted as an error and shows the limit works. Checks for '* OK'. Mail clients open several IMAP connections each, so this multiplies with users.
Implicit TLS accept only. Dovecot's process limit (process_limit, client_limit) shows here.
No mail is sent: this reads the greeting only. Mail servers throttle and ban noisy clients (per-IP connection limits, postscreen, fail2ban), so run from a whitelisted address; a '421 too many connections' reply is counted as an error and shows the limit works. Checks for '+OK'.
Implicit TLS accept only.
No mail is sent: this reads the greeting only. Mail servers throttle and ban noisy clients (per-IP connection limits, postscreen, fail2ban), so run from a whitelisted address; a '421 too many connections' reply is counted as an error and shows the limit works. Ramps greeting checks to find the connection limit (smtpd_client_connection_count_limit, max_connections). Staging servers only.
No mail is sent: this reads the greeting only. Mail servers throttle and ban noisy clients (per-IP connection limits, postscreen, fail2ban), so run from a whitelisted address; a '421 too many connections' reply is counted as an error and shows the limit works. Ramps connections to find where Dovecot's client_limit or the file descriptor limit is reached, e.g. a morning login peak.
Run in order: smoke, baseline, load, stress, spike, soak, breakpoint and failover window, each with pass/fail targets.
Enterprise plan, step 1 of 10. One request a second for 30 seconds. Run this first, every time: it proves the address, credentials and headers are right and that the environment is up before any real load is applied. Gate: zero errors. Reference request: SMTP greeting (port 25).
Step 2 of 10. About a fifth of normal traffic for 5 minutes: the uncontended latency of this request. Every later result is judged against it, so record p50 and p95. Gate: at most 0.5% errors and the default latency targets. Reference request: SMTP greeting (port 25).
Step 3 of 10. Normal busy-hour traffic for 10 minutes. The rate is the reference job's rate: raise it to your measured production peak-hour rate. This is the run that proves (or breaks) your SLO. Gate: at most 1% errors, p95 and p99 inside the targets. Reference request: SMTP greeting (port 25).
Step 4 of 10. Twice the average for 10 minutes: the busiest hour of the year plus headroom. Latency may rise, but must stay in SLO; if it does not, you have no headroom. Gate: at most 2% errors, latency targets doubled. Reference request: SMTP greeting (port 25).
Step 5 of 10. Ramps to four times average over 10 minutes, then holds for 2. Finds where it degrades and HOW: gracefully (latency rises, errors stay low) or badly (errors, timeouts, crashes, restarts). Observation only, no gate. Reference request: SMTP greeting (port 25).
Step 6 of 10. Reaches ten times average within 10 seconds and holds for 2 minutes: a campaign email, a news link, a failover. Checks autoscaling, queue limits and load shedding. Gate: at most 5% errors, because shedding load is acceptable and crashing is not. Reference request: SMTP greeting (port 25).
Step 7 of 10. Run IMMEDIATELY after the spike, at average load for 5 minutes. Latency and errors must return to the baseline from step 2. If they do not, something is stuck: queues, connection pools, GC, an autoscaler cool-down. Gate: same as average load. Reference request: SMTP greeting (port 25).
Step 8 of 10. One hour of steady load. Finds leaks and slow decay in memory, connections, file descriptors, disk, log volume and cache churn. Watch the resource graphs: any line that climbs and never flattens is a finding. Gate: at most 0.5% errors. Reference request: SMTP greeting (port 25).
Step 9 of 10. Ramps to twenty times average over 20 minutes. Stop it when errors pass about 5%: the rate at that moment is your ceiling, and ceiling divided by peak is your capacity margin. Use a production-like environment, never production. Reference request: SMTP greeting (port 25).
Step 10 of 10. Average load for 15 minutes. About 5 minutes in, cause the event you are testing: kill a pod or node, fail over the database, roll out a new version, drain a zone. Errors in the window are your real availability loss. Gate: at most 1% errors overall; read the time series for how long the dip lasted. Reference request: SMTP greeting (port 25).
Ramps new connections per second to ten times normal: a fleet reconnecting after an outage, a deploy that restarts every pod, a network blip. Shows accept-queue, file descriptor and handshake limits. Reference request: SMTP greeting (port 25).
Three times normal connection attempts for 10 minutes: a newsletter bounce wave or a spam run. Watch per-IP connection limits and the deferred queue. Reference request: SMTP greeting (port 25).
Every mail client reconnects at the start of the working day. Ramps to five times normal over 2 minutes. Reference request: IMAP greeting (port 143).
The Mail servers template has 22 jobs: 9 single scenarios and an enterprise test plan of 13 stages (smoke, baseline, load, stress, spike, soak, breakpoint and failover window). Scenarios include SMTP greeting (port 25), submission greeting (port 587), SMTPS accept (port 465) and IMAP greeting (port 143). 8 of them have pass/fail targets (SLOs), so a run can be judged against limits you set.
Open the template in BLASTA and set host, then pick a job and start it. Results stream live: requests per second, latency percentiles and errors, and the run is kept in your history. To run from the command line, use blasta preset new mail-servers with your address.
All 22 jobs in this template are read-only: they request pages or data and do not change anything. Even so, a load test can slow a live system down, so start with a low rate and prefer a staging copy. Only test systems you own or have permission to test.
Welcome back. Sign in to run and review load tests.
Send the confirmation email again
Just looking? Try a quick test without an account
Point BLASTA at something you own, choose how hard to hit it, and press Start test. Results stream in live.
Queries are read-only unless Allow writes is on.
Multi-statement input and writable CTEs (WITH d AS (DELETE…)) are always refused.
For MQTT, LDAP, AMQP and other binary protocols. The templates fill this in for you.
The address accepts host:port or tcp://host:port.
Leave this empty to only test the connection handshake.
No results yet
Set up a target above and press Start test. Charts and numbers appear here as the test runs.
Ready-made jobs for common systems. Search by system, protocol or what you want to test (wordpress, saml, redis, spike, login storm…), pick a job, and it opens on the Test page ready to run.
You are browsing as a visitor: you can read every template and job. Sign in or create an account to use them.
No templates match
Try a shorter search, or a system name such as keycloak, postgres or soap.
You are browsing as a visitor: you can read every job here. Sign in or create an account to use them.
Fill in your system's address. The jobs below update as you type.
Your tests. Open one to see it the way it looked live, with its charts, load settings and server usage.
| When | Job | Target | Requests | Avg req/s | p95 | Errors | CPU avg | RAM avg | Result |
|---|
Charts were not recorded for this run (it was saved by an older version).