swaks: Swiss Army Knife for SMTP testing

Every time I need to test an SMTP server — whether it’s checking if open relay is possible, verifying SPF/DKIM/DMARC behavior, testing STARTTLS enforcement, or just confirming a mail server accepts a specific envelope — swaks (Swiss Army Knife for SMTP) is what I reach for. It’s a scriptable, feature-complete SMTP testing tool that lets me construct and send a fully custom SMTP transaction from the command line, without needing a full mail client.

This article covers what swaks does, how it builds and sends SMTP transactions internally, installation, syntax, real command examples, and how it fits into email security assessments and troubleshooting.

What Swaks Does

swaks is a Perl-based command-line tool that lets you construct and send arbitrary SMTP transactions, testing things like:

• Basic SMTP connectivity and banner behavior
• STARTTLS negotiation and certificate details
• Authentication mechanisms (PLAIN, LOGIN, CRAM-MD5, etc.)
• Open relay testing (sending mail through a server to an external domain without authentication)
• Custom envelope sender/recipient combinations for SPF/DMARC testing
• Raw protocol-level SMTP command sequences for debugging edge-case server behavior

Architecture and Internal Working

swaks works by directly implementing the SMTP client protocol rather than shelling out to sendmail or another MTA. Its workflow:

1. It opens a TCP connection to the target mail server (or resolves via MX record if instructed).
2. It performs the SMTP conversation step by step — EHLO/HELO, optional STARTTLS, optional AUTH, MAIL FROM, RCPT TO, DATA, and QUIT — printing every line sent and received when run in default (verbose) mode.
3. Each of these stages can be independently customized, skipped, or scripted via command-line flags, which is what makes it so useful for edge-case testing — you can test “what happens if I send MAIL FROM before EHLO” just as easily as a normal transaction.
4. For STARTTLS, it upgrades the plaintext connection in place and continues the conversation over TLS, printing the negotiated cipher and certificate chain.

Because every step is visible and independently controllable, swaks functions as both an SMTP testing tool and a protocol-level debugging tool.

Installation

Debian/Kali:

sudo apt update
sudo apt install swaks -y

From source (single Perl script, minimal dependencies):

wget https://jetmore.org/john/code/swaks/files/swaks-20240103.0/swaks
chmod +x swaks
sudo mv swaks /usr/local/bin/

Verify:

swaks --version

Basic Syntax

swaks [options]

Unlike many tools, swaks doesn’t require a positional target argument — everything is controlled via flags like --to, --from, and --server.

Command Examples

1. Basic connectivity/banner test

swaks --to test@example.com --server mail.example.com

Sample output:

=== Trying mail.example.com:25...
=== Connected to mail.example.com.
<-  220 mail.example.com ESMTP Postfix
 -> EHLO swaks-client
<-  250-mail.example.com
<-  250-PIPELINING
<-  250-STARTTLS
<-  250 8BITMIME
 -> MAIL FROM:<user@swaks-client>
<-  250 2.1.0 Ok
 -> RCPT TO:<test@example.com>
<-  250 2.1.5 Ok
 -> DATA
<-  354 End data with <CR><LF>.<CR><LF>
 -> [message content]
<-  250 2.0.0 Ok: queued as A1B2C3D4
 -> QUIT
<-  221 2.0.0 Bye

2. Testing STARTTLS negotiation

swaks --to test@example.com --server mail.example.com --tls

This forces STARTTLS and shows the negotiated cipher and certificate details, which is useful for confirming a mail server properly enforces encrypted transport.

3. Testing SMTP authentication

swaks --to test@example.com --server mail.example.com --auth LOGIN --auth-user myuser --auth-password 'mypassword' --tls

4. Open relay test (authorized testing only)

swaks --to external@otherdomain.com --from spoofed@example.com --server mail.example.com

If the server accepts and relays this without authentication and without the sender belonging to a locally hosted domain, that’s a serious open relay finding worth flagging immediately.

5. Testing a custom envelope sender for SPF validation

swaks --to test@example.com --from admin@example.com --server mail.example.com --header-From '"CEO" <ceo@example.com>'

This helps validate whether SPF/DMARC policies actually reject spoofed sender domains as expected.

6. Sending a message with a custom subject and body

swaks --to test@example.com --from tester@example.com --server mail.example.com \
  --header "Subject: SMTP Test" --body "This is a test message from swaks."

7. Testing specific SMTP command sequences manually

swaks --to test@example.com --server mail.example.com --protocol smtp --hostname mytest.local --pipeline

8. Testing via a specific port (e.g., submission port 587)

swaks --to test@example.com --server mail.example.com --port 587 --tls --auth LOGIN --auth-user myuser --auth-password 'mypass'

Configuration Options

Real-World Use Cases

Open relay testing: One of the highest-value, fastest checks in an external mail server assessment — confirming a server won’t relay unauthenticated mail to arbitrary external domains.

SPF/DKIM/DMARC validation: Sending test messages with spoofed From headers to confirm whether receiving mail servers correctly reject or flag messages that fail authentication checks.

STARTTLS enforcement testing: Confirming a mail server doesn’t silently accept plaintext SMTP when it should be enforcing encrypted transport, which matters for both confidentiality and downgrade-attack resistance.

Mail server troubleshooting: When a client reports mail delivery issues, swaks lets me reproduce the exact SMTP transaction step by step to see precisely where a server rejects or mishandles a message.

Phishing simulation support (with authorization): Constructing test messages with specific header configurations to validate how well a target organization’s mail filtering catches spoofed sender scenarios, strictly within an approved phishing assessment scope.

Workflow and Tool Integration

# Step 1: enumerate valid SMTP users first
smtp-user-enum -M VRFY -U userlist.txt -t mail.example.com

# Step 2: test open relay against a discovered valid user
swaks --to validuser@example.com --from external@otherdomain.com --server mail.example.com

# Step 3: validate STARTTLS/cipher configuration
sslscan --starttls-smtp mail.example.com:25

swaks, smtp-user-enum, and sslscan together give a fairly complete picture of a mail server’s security posture in one focused testing session.

Performance Optimization

• Use --quit-after to stop the transaction early when you only need to test up to a specific command (e.g., stopping right after RCPT TO to check relay acceptance without actually sending a full message body).
• Batch multiple recipient tests with a shell loop rather than manually re-running the command for each address.
• Suppress full verbose protocol output with --suppress-data when scripting large batches of tests and only checking final status codes.

Troubleshooting

• Connection refused — confirm port 25/587/465 is actually open and not blocked by an ISP or firewall (many residential/cloud providers block outbound 25 by default).
• STARTTLS negotiation fails — check certificate validity on the target server; swaks --tls will report the specific TLS error returned.
• Authentication always fails — confirm the correct auth mechanism is being used; try --auth-user/--auth-password with each of PLAIN, LOGIN, and CRAM-MD5 if the server’s supported mechanisms aren’t explicitly known.

Best Practices and Common Mistakes

• Always get explicit written authorization before running open relay or spoofed-sender tests — sending mail that appears to originate from a domain you don’t control, even for testing, can have legal and reputational implications if unauthorized.
• Don’t forget to test both port 25 (server-to-server) and port 587 (submission, typically requiring auth) — they often have different security postures.
• Clean up test messages sent to real mailboxes during testing where possible, and coordinate with the client on expected test traffic so it isn’t mistaken for a real incident.

FAQ

Does swaks require a full mail server installed locally? No — it implements the SMTP client protocol itself and only needs network access to the target mail server.

Can swaks test IMAP or POP3 as well? No, swaks is SMTP-specific; other tools are needed for IMAP/POP3 protocol testing.

Is testing for open relay illegal? Testing without authorization against systems you don’t own or have permission to test is illegal in most jurisdictions; always operate within a signed scope of work or your own lab environment.

Lab Example

Set up a Postfix server in a lab VM, deliberately misconfigure it as an open relay, and test:

swaks --to external@lab-otherdomain.com --from spoofed@lab-example.com --server 192.168.56.60

Confirm the relay succeeds, then correct the Postfix mynetworks/relay restrictions and re-run the same command to confirm it’s now rejected.

Summary

swaks gives me full, granular control over every stage of an SMTP transaction, which makes it invaluable for open relay testing, SPF/DKIM/DMARC validation, STARTTLS verification, and general mail server troubleshooting. Its scriptable, flag-driven design means almost any SMTP edge case can be reproduced and tested precisely, without needing a full mail client.

References

• Official project page: https://www.jetmore.org/john/code/swaks/
• Man page: man swaks