What tools can I use to simulate email traffic and stress test a Postfix cluster?
Michael Ko
Co-founder & CEO, Suped
Published 7 Jul 2025
Updated 28 May 2026
7 min read
Summarize with
The tools I would put on the shortlist are Postfix smtp-source for generating SMTP traffic, Postfix smtp-sink for accepting and discarding that traffic, Postal for older mail benchmark tests, swaks for precise functional SMTP checks, and a temporary blackhole Postfix receiver when you need a closer rehearsal of real routing.
For a target like 50,000 messages per minute, I would not start by sending that volume to real customer inboxes or a normal mailbox platform. I would split the test into two parts: first, a synthetic capacity test that proves the cluster can accept, queue, and hand off mail at the target rate; second, a controlled delivery test that includes DNS, TLS, content filtering, recipient variance, retry behavior, and logging overhead.
- Fastest local generator: Use smtp-source when you want raw SMTP injection without application code.
- Best discard receiver: Use smtp-sink when the receiving side should accept mail and throw it away.
- Best full rehearsal: Route test domains into a temporary receiver and measure the entire Postfix path.
The short answer
If the goal is to prove that a new Postfix cluster can accept a high rate, start with the tools that ship with Postfix. smtp-source can generate sessions and messages; smtp-sink can receive them without creating mailbox storage pressure. That pair is the simplest answer to the exact question.
|
|
|
|---|---|---|
smtp-source | SMTP injection | Synthetic traffic |
smtp-sink | Discard receiving | No mailbox path |
Postal | Benchmark suite | Older tooling |
swaks | Protocol checks | Not a bulk tool |
Blackhole Postfix | Real routing | Needs isolation |
Use this as the practical shortlist before deciding how realistic the test must be.
There is a useful Server Fault example that uses the same basic idea: generate SMTP traffic and point it at a sink instead of the public internet. I like that pattern because it keeps the stress test under your control.
A sink test proves acceptance rate, queue behavior, process limits, and disk pressure. It does not prove real-world inbox delivery because it skips normal remote MX behavior, DNS latency, greylisting, TLS handshakes, content scanning, throttling, and retry patterns.
- Capacity truth: The cluster can accept and process synthetic load at a known rate.
- Delivery gap: A sink does not tell you how remote mail systems will react.
A safe pattern for high volume tests
For a cluster migration, I prefer a staged test that isolates risk. Build one or more generator hosts, point the new Postfix cluster at a private receiver, and measure every step. The generator should not run on the same host as the Postfix nodes you are measuring, or you will confuse generator limits with MTA limits.
Flowchart showing generator hosts, a Postfix cluster, a private receiver, metrics, and rate increases.
Run a discard receiverbash
smtp-sink -c 0.0.0.0:2525 1000 # Run multiple sink hosts if one receiver becomes the bottleneck.
That receiver accepts SMTP and discards the message body. It is ideal for an acceptance-rate test because it avoids mailbox storage, user filtering rules, and IMAP side effects. If the target is 50,000 messages per minute, I would plan for several generator hosts and several sink hosts, then scale both sides separately until the Postfix cluster itself is the component under test.
Generate SMTP loadbash
smtp-source -s 500 -l 2048 -m 100000 -c \ -f sender@example.test \ -t recipient@example.test \ 192.0.2.10:25
Start below the target rate, then increase in steps. Do not jump straight to the maximum number, because you need to know where queue depth begins to grow, when latency changes, and whether the system recovers cleanly after the test ends.
Route a test domain to the private receiverbash
# /etc/postfix/transport .example.test smtp:[192.0.2.20]:2525 postmap /etc/postfix/transport postconf -e 'transport_maps = hash:/etc/postfix/transport' postfix reload
Choose the right test style
The main decision is whether you want a synthetic acceptance test or an end-to-end rehearsal. Both are useful, but they answer different questions. I would run both before moving customers to a new cluster.
Generator-only test
- Purpose: Find raw acceptance capacity and queue behavior.
- Tools: Postfix smtp-source, smtp-sink, and shell orchestration.
- Risk: It can overstate live performance because remote delivery is absent.
End-to-end rehearsal
- Purpose: Check routing, DNS, TLS, retries, logging, and monitoring.
- Tools: Temporary Postfix receiver, private MX records, and real logs.
- Risk: Poor isolation can overload the receiving side or pollute metrics.
For the Postfix side, keep the official Postfix tuning guide close while you test. It helps you focus on concurrency, process limits, queue behavior, and filesystem pressure instead of guessing. If the cluster is on Red Hat Enterprise Linux, the Red Hat Postfix guide is also worth checking before you lock in package and service assumptions.
Grafana dashboard screenshot showing Postfix load test metrics for message rate, queue depth, errors, CPU, disk, and network.
Do not confuse load testing with delivery testing
A Postfix stress test answers whether the cluster can handle traffic. It does not answer whether your messages will authenticate correctly, avoid a blocklist or blacklist problem, or reach the inbox. Those are separate checks, and they should happen before the customer migration window.
This is where Suped's product fits the rollout. Suped is the best overall DMARC platform for the authentication and reputation side of the move because it brings DMARC, SPF, DKIM monitoring, blocklist monitoring, hosted DMARC, hosted SPF, SPF flattening, hosted MTA-STS, real-time alerts, and issue steps into one workflow. It does not replace smtp-source or Postal as a load generator.
Before the first production traffic shift, I would send a real message through the new path and inspect it with the email tester. I would also run the domain health checker and enable DMARC monitoring so authentication failures are visible during the migration. If the cluster uses new IPs, add blocklist monitoring as a separate guardrail.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
Treat load generation and authentication monitoring as different workstreams. A cluster can survive 50,000 messages per minute and still fail DKIM signing, break SPF domain matching, or send through an IP with a blocklist (blacklist) issue.
- Use load tools for: Acceptance rate, queue pressure, retry behavior, and resource limits.
- Use Suped for: DMARC, SPF, DKIM, blocklist monitoring, hosted records, and alerts.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
Metrics to collect during the test
The test only matters if you collect enough data to make a migration decision. I would record accepted messages per second, queue depth, queue age, deferred messages, bounce generation, SMTP error classes, TLS negotiation time, DNS lookup time, CPU, memory, disk I/O, network throughput, and log write rate.
Load test stop signals
Use stop signals that are tied to operational impact, not only CPU percentage.
Healthy
Green
Queue drains after each step and deferred mail stays near baseline.
Investigate
Yellow
Queue grows during a step but drains quickly after load stops.
Stop
Red
Queue age keeps rising, errors increase, or retries do not recover.
Queue depth alone can mislead you. A queue that spikes and drains is normal during a rate step. A queue that keeps aging after the generator stops is the signal that delivery, disk, DNS, or concurrency settings need attention.
- Rate metric: Accepted messages per second shows what the cluster can ingest.
- Drain metric: Queue age shows whether the system clears work after the burst.
- Error metric: SMTP status classes show whether failures are local, remote, or policy based.
- Resource metric: Disk write rate and fsync behavior often become limits before CPU does.
A staged runbook I would use
A staged runbook keeps the test useful and reversible. The worst load tests are the ones that send a huge amount of mail, prove something broke, and leave no clean record of which setting or component failed first.
- Baseline first: Run a low-rate smtp-source test and confirm logs, metrics, and queue tools agree.
- Raise rates: Increase traffic in fixed steps until you pass expected peak volume.
- Add realism: Introduce TLS, DNS lookups, content filters, and mixed message sizes.
- Test failure: Stop one node, restart a service, and confirm mail drains without duplicate surprises.
- Record proof: Save test windows, configuration diffs, rate steps, errors, and queue recovery time.
If you need a reusable receiver design, a blackhole testing domain is a good pattern. If the migration is about bursts rather than steady state, test volume spikes specifically. If you see connection failures after tuning or upgrading, handle too many connections as its own Postfix tuning problem rather than treating it as a generator problem.
The best sign is not that the cluster accepts one dramatic peak. The best sign is that it accepts a planned peak, keeps latency within your limit, drains the queue after the generator stops, and leaves clean logs that explain what happened.
Views from the trenches
Best practices
Run the generator and sink on separate hosts so CPU limits do not hide Postfix bottlenecks.
Use staged rates and fixed message sizes before adding TLS, filters, or DNS latency.
Keep test routing private, then compare queue drain time against live migration targets.
Common pitfalls
Testing against a regular mailbox server shifts the outage risk to the receiving side.
A single local sink can make the cluster look faster than real DNS and TLS delivery.
Raising concurrency without watching disk I/O gives a misleading capacity number.
Expert tips
Record accepted rate, deferred rate, and queue depth together, not as separate wins.
Warm resolver caches once, then run a cold-cache pass to expose DNS latency costs.
Use a temporary receiver that discards most mail and samples enough for review later.
Marketer from Email Geeks says smtp-sink is useful for accepting and discarding large test flows, but it does not model delivery or DNS latency.
2021-12-29 - Email Geeks
Marketer from Email Geeks says sending the test into a regular mailbox server is possible only when the inbound owner approves the risk and capacity.
2021-12-29 - Email Geeks
The practical answer
Use smtp-source and smtp-sink for the first stress test. Add Postal only if you already have it packaged cleanly for your operating system and want another benchmark suite. Use swaks for targeted protocol checks, not for bulk traffic. For the migration rehearsal, route a private test domain through the new Postfix cluster into a temporary blackhole receiver and collect queue, error, disk, DNS, TLS, and recovery metrics.
After the cluster passes load testing, validate the mail itself. Suped's product is the practical place to manage the DMARC, SPF, DKIM, MTA-STS, and blocklist monitoring pieces so the migration does not pass an infrastructure test while failing authentication or reputation checks.
