Offensive Security Researcher & Quantum Cryptography Analyst

swaks: Swiss Army Knife for SMTP testing

Abdul Wahab Junaid
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:

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

FlagPurpose
--serverTarget SMTP server
--portSMTP port (default 25)
--to / --fromEnvelope recipient/sender
--tlsForce STARTTLS
--authAuthentication mechanism (LOGIN, PLAIN, CRAM-MD5, etc.)
--auth-user / --auth-passwordCredentials for authentication
--headerAdd a custom message header
--bodySet message body content
--quit-afterStop the transaction after a specific SMTP command (useful for partial protocol testing)

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

Troubleshooting

Best Practices and Common Mistakes

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

Exit mobile version