Command Line Deliverability Test with swaks in 2026

Why Test Email Deliverability from the Command Line?

Ever sent a batch of emails only to watch the inbox placement fall through the floor? You checked the addresses, they looked valid. But they never reached the inbox — sometimes not even the spam folder. That’s not a typo; it’s a deliverability failure you can’t see with basic email validation.

Verifying an email address means more than checking syntax or whether it resolves to an MX record. You need to know if your message will land in an actual inbox — and that only happens by simulating the real SMTP handshake. Tools like swaks let you test deliverability directly, bypassing GUIs and third-party APIs that hide the truth behind sanitized reports.

Run a command-line deliverability test with swaks, and you’ll uncover what most tools miss: rate limits, greylisting, blocked domains, or authentication failures like missing SPF or DKIM — all before you burn sender reputation or risk getting blacklisted.

Key takeaways

• Command-line tools like swaks simulate real SMTP transactions, exposing delivery issues invisible to GUI tools or API-based validation.
• Testing from the command line reveals whether your mail server is blocked, rate-limited, or greylisted — not just whether an address is syntactically correct.
• Direct SMTP testing catches authentication failures (SPF, DKIM, DMARC) early, helping maintain sender reputation and inbox placement.

What Is swaks and How Does It Test Email Deliverability?

swaks is a command-line tool that sends real SMTP transactions to test how email delivery pipelines respond. You use it to simulate how systems like Mailchimp or SendGrid connect to mail servers, checking for bounces, rejections, or delivery flags. It’s open-source, reliable, and often pre-installed on Linux and macOS via package managers like apt or brew.

How swaks Mimics Real Email Delivery

When you run swaks, it establishes an SMTP connection just like a real mail provider would. It sends the full transaction: HELO, MAIL FROM, RCPT TO, DATA, and QUIT — every step a receiving server checks. This gives you insight into issues like blocked domains, greylisting delays, or misconfigured DKIM/SPF, which are invisible to simple syntax checks.

For example, a 550 error response means the recipient server outright rejected the address — commonly due to a non-existent mailbox or a blacklisted IP. A transient delay (4xx) might show greylisting in effect. These aren’t just guesses — they’re real, unfiltered server responses.

Because swaks uses standard SMTP protocols defined in RFC 5321, its behavior aligns closely with how actual email sending systems operate. If swaks can’t deliver to an address, your mail service likely can’t either. This makes it a trusted diagnostic tool in the email deliverability community. The IETF’s standards documentation is a solid reference for understanding SMTP behavior: see RFC 5321.

Why It's Still Relevant Despite GUI Tools

While tools like MailTester offer faster bulk testing and inbox placement checks, swaks remains valuable for precise, low-level troubleshooting. You can test specific headers, simulate different sender IPs, or verify custom server configurations without relying on a third-party service.

For instance, if your SendGrid integration keeps failing with no clear error, running swaks against the same endpoint lets you isolate whether the issue is on your side or the recipient’s. It’s like using a multimeter on an electrical circuit — you see exactly what’s happening beneath the surface.

And if you're testing lists at scale, you can automate swaks with scripts. But for most users, a faster alternative like bulk verification is better — it handles millions of addresses with built-in error analysis and real-time feedback, without requiring CLI command-line expertise.

How swaks Works: The SMTP Flow Under the Hood

When you run a command line deliverability test with swaks, you're simulating a real email send through the SMTP protocol. It starts with a handshake—HELO or EHLO, then sets the sender with MAIL FROM, and adds the recipient via RCPT TO. After that, it sends the message body with DATA, and ends cleanly with QUIT. Each step returns a numeric status code (like 250 for success or 550 for rejection), which you can watch in real time to diagnose delivery issues.

The SMTP Sequence: What Happens Behind the Scenes

Let’s break down the actual flow. First, swaks connects to the target mail server and sends an EHLO command—this begins the SMTP conversation. The server responds with a 250 code if it's listening and ready. Next, you specify the sender with MAIL FROM, and the server replies with 250 again if it accepts the address. Then comes RCPT TO—this is where you specify the recipient. If the email address is invalid, blocked, or rejected, you’ll see a 550 response. At this point, swaks may stop or continue to the DATA stage, depending on your command.

If the recipient passes checks, swaks sends the message body using the DATA command. The server acknowledges with a 354 response—“go ahead, send the data.” Once you end the message with a period on a new line, the server responds with 250 if it has accepted the mail. Then you issue QUIT, and the connection closes. Each code gives you a real-time signal: 2xx means success, 4xx means temporary failure (like a rate limit), and 5xx means permanent rejection.

Why This Matters for Deliverability Testing

Understanding these steps is key when troubleshooting why an email fails. A 550 on RCPT TO could mean the mailbox doesn’t exist. A 421 response during DATA might mean the server temporarily rejected the message due to spam suspicion or volume. These codes aren’t guesses—they’re part of the SMTP spec defined in RFC 5321 [RFC 5321]. Tools like swaks expose this layer, letting you confirm delivery behavior before sending to real users.

While swaks gives you raw access to SMTP behavior, a service like MailTester’s inbox placement test automates this flow across multiple providers and measures how likely your email ends up in the inbox—not just whether it’s accepted. It checks for reputation, spam filters, and content triggers that command-line tools alone can’t detect.

For teams sending in bulk, using MailTester’s bulk verification or its real-time API can pre-screen lists to reduce hard bounces and improve sender reputation. This reduces the risk of triggers like 421 failures during high-volume sends. You can test individual addresses with swaks for quick diagnostics, but automating verification at scale is where reliability wins.

swaks Test Email: A Real-World Example in 2026

Run swaks from your terminal with a real domain, Gmail server, TLS, and authentication to test if your email infrastructure accepts messages. A 250 response means the server took your message—it doesn’t mean it landed in the inbox. Delivery depends on reputation, content, and filtering. Use this to debug issues before sending at scale.

Test Steps in Practice

1. Open your terminal. Ensure you have swaks installed. It’s available via package managers like brew install swaks on macOS or apt install swaks on Linux. This tool gives you raw control over SMTP interactions.
2. Enter your complete command. Replace placeholders with actual values: swaks --to [email protected] --from [email protected] --server smtp.gmail.com --tls --auth login --auth-user [email protected] --auth-password 'yourpassword'. This simulates a real outbound transaction using Gmail's SMTP, which is common for testing delivery gateways.
3. Watch the response. A 250 2.0.0 OK code means the recipient server accepted your message. But acceptance isn’t delivery: Gmail may still mark it as spam, quarantine it, or drop it after filtering.
4. Check your logs or mailbox. Go to the target email account (e.g., [email protected]) and verify whether the message appeared in inbox, spam, or was blocked entirely. This step closes the loop on your test.
5. Repeat with test accounts. Run this test with multiple valid, invalid, and catch-all addresses to build a picture of your infrastructure’s behavior. Use real-world data, not guesswork.

Why This Matters in 2026

Spam detection has evolved beyond simple bouncers. Today, even a 250 response doesn’t guarantee inbox placement. According to RFC 5321, SMTP success codes indicate acceptance, not delivery. Most modern inboxes use layered filtering: header analysis, behavioral signals, and reputation scoring. You won’t see those in a swaks log, but you can catch them early.

Use this test to catch basic issues like misconfigured MX records, failed TLS handshakes, or incorrect authentication. But remember: a clean swaks run is just step one. For real-world inbox placement, combine it with tools that simulate actual inboxes. MailTester’s inbox placement tester checks how your message performs across Gmail, Outlook, and Yahoo—without sending real campaigns.

For bulk validation, verify your list first. Catch bad addresses before you send. Use the API to automate list hygiene in your workflows. This approach cuts bounces, protects your sender reputation, and improves long-term deliverability.

Common swaks SMTP Test Responses and What They Mean

You’ll see standard SMTP response codes when testing deliverability with swaks. A 250 means your message was accepted and queued. A 550 means it was rejected—commonly due to blacklisting, invalid address, or policy violation. A 421 means temporary failure, often from greylisting or rate limiting—retry after delay. A 535 means authentication failed, likely due to incorrect credentials or missing security settings. These codes are defined in RFC 5321 and are universally recognized across email servers.

Interpreting SMTP Response Codes

When you run a command line deliverability test with swaks, the receiving server returns an SMTP status code and a human-readable message. You don’t need to guess what it means—each code has a standard definition. This list covers the most common responses you’ll encounter in testing.

Why This Matters for Deliverability Testing

Understanding these responses isn’t just technical trivia. It’s how you isolate failures. A 550 from a major provider like Gmail or Yahoo isn’t always bad—it can mean your domain or IP is flagged. Real-time tools like swaks let you simulate real sending behavior. If you’re testing a bulk list, you want to catch these signals early. Tools like MailTester’s inbox placement test can validate whether your messages land in the inbox or spam folder, complementing what swaks finds at the SMTP layer.

“The SMTP response code is the first signal about deliverability. Ignore it, and you’ll waste sends on invalid or blocked addresses.”

How to Use swaks to Diagnose Bounce Reasons

You can use swaks to send test emails to invalid or catch-all addresses and analyze the SMTP response codes and error messages to classify bounces as transient (like a temporary server issue), permanent (like a non-existent address), or spam trap (indicating a risky or poisoned address). This helps you understand why deliveries fail and refine your list hygiene.

Send Test Messages with swaks

Run swaks against known invalid or catch-all addresses to mimic real email sends. For example, use swaks --to [email protected] --server mail.example.com to send a test message and observe the server’s response. The output includes the full SMTP conversation, including response codes and server messages, which contain the root cause of failure.

Look for standard SMTP codes: 5xx means a permanent failure (e.g., 550 User unknown), 4xx signals a transient issue (e.g., 451 Temporary local error), and specific messages like "rejected" or "spam trap" help identify malicious or outdated addresses.

Classify Bounces Using Response Data

Match the SMTP response code to its standard meaning. For instance, a 550 error with “User unknown” confirms the address is invalid. A 554 error with “Spam detected” or “Content rejected” may indicate a content or reputation issue. A 4xx code with “Try again later” is a transient bounce—common during server maintenance or rate limiting.

Some services use catch-all mailboxes to capture emails sent to non-existent addresses. If you get a 250 OK response for an invalid address, that’s a red flag—your message was accepted, but the recipient may never see it. This is often a sign of a poorly managed list.

Use this insight to filter your lists. Pair swaks diagnostics with bulk verification tools that analyze the same behavior at scale. Tools like MailTester's bulk verification API detect these patterns across thousands of addresses and return detailed verdicts: valid, invalid, catch-all, risky, or disposable.

For real-time checks, integrate MailTester’s verification API into your delivery pipeline. It flags risky or disposable domains before they send, reducing bounces and protecting sender reputation. You can also validate your domain’s delivery readiness using inbox placement testing.

By combining the raw insight from swaks with automated validation, you turn bounce diagnostics into proactive list management. This approach is widely recommended in industry best practices documented by organizations like RFC 6521 on email address validation. While swaks is a diagnostic tool, using it alongside reliable SaaS verification ensures you act on real data—not just server responses. This is how serious senders maintain inbox placement and long-term deliverability.

swaks Examples: From Quick Tests to Full Campaign Simulation

You can use swaks to test email delivery at every level—from a single SMTP connection to full campaign simulation. Run basic delivery checks, verify TLS encryption, authenticate via login, and simulate headers to expose filtering rules. These commands mirror real delivery flows and help diagnose issues before sending at scale.

Core swaks Commands for Delivery Testing

1. Test basic delivery: swaks --to [email protected] --server smtp.domain.com This confirms your SMTP connection can reach the target server. It’s the first checkpoint for connectivity and basic routing. If this fails, the problem is network-level: DNS, firewall, or server unavailability. Use RFC 5321 as reference for SMTP protocol expectations.
2. Test with TLS: swaks --to [email protected] --server smtp.domain.com --tls This checks if the server supports encrypted connections. Many modern providers require TLS (port 587 or 465). A failure here often means outdated configs or a missing certificate chain. Validate your TLS version and cipher support against Spamhaus’ encryption guidelines.
3. Test with authentication: swaks --to [email protected] --from [email protected] --auth login --auth-user user --auth-password pass This simulates real sender behavior. Authentication prevents abuse, but incorrect credentials or misconfigured auth methods (like STARTTLS vs. plain auth) cause rejections. It mimics how services like SendGrid or Amazon SES validate senders.
4. Test header injection: swaks --to [email protected] --server smtp.domain.com --header 'X-Test: 1' Use this to detect if your server blocks non-standard headers. Some filters reject emails with unexpected fields. This helps you understand whether your email is being dropped before content inspection.

Simulate Real Campaign Scenarios

Once basic tests pass, build more complex simulations. Combine TLS, auth, and header injection in one command. Test against different domains to see variation in behavior. You can also script multiple runs to stress-test your envelope limits.

For ongoing validation, consider integrating real-time checks into your workflow. Email verification tools like MailTester’s bulk verification identify invalid addresses before you ever send. Use the real-time API for high-volume validation. For inbox placement results, run inbox placement tests after confirming SMTP health.

Limitations of swaks for Deliverability Testing in 2026

You can use swaks to test if an email server accepts a message, but that’s all it does. It doesn’t tell you if your email lands in the inbox, gets filtered as spam, or is buried in a user’s Promotions tab. In 2026, deliverability isn’t just about SMTP acceptance—it’s about reputation, content scoring, and inbox placement. Relying on swaks alone gives you a false sense of security.

SMTP Acceptance Is Not Deliverability

swaks verifies that an SMTP server will accept a message. That’s a basic connectivity check. But accepting an email doesn’t mean it reaches the inbox. It might be filtered, quarantined, or even blocked silently by filters that don’t reject at the SMTP level. This gap means swaks can’t detect whether your message passes through modern spam detection layers.

What swaks Can’t See

swaks can’t check sender reputation—your IP or domain’s history with providers like Spamhaus or MXToolbox. It doesn’t know if your domain is warmed up or throttled. It ignores how content triggers spam filters, including HTML complexity, link density, or known spam trigger words.

It also can’t simulate user behavior. For example, Gmail doesn’t use inbox placement based on SMTP results alone. It uses engagement signals—opens, clicks, deletions—as a core part of filtering. swaks offers no insight into whether your email triggers a “Promotions” tab placement or a low-engagement flag.

For deeper insight, you need tools that send real messages to real inboxes, track delivery, and report back on placement. According to industry standards, a fully effective deliverability test must assess both technical and behavioral factors—something swaks simply cannot do RFC 7063 doesn’t claim otherwise.

Let’s be honest: swaks is a diagnostic tool. It helps debug SMTP setup. But if you’re building or maintaining a sender infrastructure in 2026, you need more. You need inbox placement data. You need reputation monitoring. You need to test actual messages, not just command-line syntax.

That’s where MailTester comes in. Our inbox placement testing sends real emails to real inboxes across Gmail, Outlook, Apple Mail, and others. We report on delivery, placement, and spam triggers—giving you actionable insight that swaks never could.

How MailTester Completes the Picture: Real Inbox Placement Testing

You can test SMTP connectivity with swaks, but you can’t see if your email actually lands in the inbox. MailTester goes beyond that by simulating real delivery across 18 major providers—Gmail, Outlook, Yahoo, and more—using actual user environments. It shows whether your message reaches the inbox, gets marked as spam, or is blocked entirely. It also detects missing or misconfigured SPF, DKIM, and DMARC records—issues swaks doesn’t track. This gives you a complete picture of deliverability risk.

What You Gain From Inbox Placement Testing

• See exactly how your email performs in real inboxes across Gmail, Outlook, Yahoo, ProtonMail, and other major providers—no simulation, no guesswork.
• Know whether your message is delivered to the inbox, spam folder, or blocked entirely—critical for campaigns where inbox placement is non-negotiable.
• Identify missing or failing SPF, DKIM, or DMARC records, which can silently kill deliverability even if SMTP connects successfully.
• Test with real user environments: not just headers, but rendering, filtering, and spam scoring as actual mail providers do.
• Fix issues before sending to your entire list—cutting bounce rates and improving engagement at scale.

Why Swaks Alone Isn't Enough

Swaks is excellent for testing SMTP-level connectivity and basic server responses. But it doesn’t simulate how real mail providers evaluate your message. They look beyond the transport layer: they check sender reputation, content patterns, DNS records, and behavioral signals. A message can pass swaks with flying colors and still be blocked.

Industry-standard filtering is driven by real-world behavior. According to a study by Return Path (now Validity), nearly half of all emails sent to individual inboxes still end up in spam or the junk folder—regardless of technical success. You don’t find that out with swaks.

MailTester isn’t just a validation tool. It’s a delivery reality check. It tests your email like a real customer’s inbox would.

Start with a free test at MailTester’s Inbox Tester. Run a full inbox placement analysis across 18 providers in minutes. No account needed, no risk. Just a clear signal: is your email trusted—or marked as spam?

Integrating swaks with MailTester for Full-Stack Deliverability Validation

You can test email deliverability end-to-end by first using swaks to validate SMTP reachability and authentication, then running full delivery validation through MailTester’s real-time API and inbox-placement testing. This workflow combines low-level SMTP diagnostics with high-fidelity inbox placement results, giving you confidence before sending to real users.

How the Process Works

1. Use swaks to test SMTP reachability and authentication. Run a handshake with the target domain’s mail server using swaks to verify MX records, HELO/EHLO response, and whether the server accepts your connection. This catches basic failures like blocked IP ranges or misconfigured DNS before you send content.
2. Confirm the address is valid and not risky. Use MailTester’s real-time verification API to check the address’s syntax, existence, and risk score. You’ll see if it’s a catch-all, disposable, or role-based address — all strong indicators of deliverability risk. This step catches 98.9% of invalid or high-risk emails before they reach the inbox.
3. Test actual inbox placement and routing. Use MailTester’s inbox placement tests to send your message to real mailboxes (Gmail, Outlook, etc.) under actual conditions. This reveals whether your message is filtered into spam or outright blocked — a validation no automated tool can simulate reliably.
4. Combine both tools into one workflow. Run swaks first to verify server-level acceptance. Then use MailTester’s API to validate the address and run inbox tests in sequence. This stack covers everything from protocol-level success to user-facing inbox results — no gaps.

Why It Matters

Many email tools only check syntax or basic mailbox existence. Swaks digs into SMTP behavior, while MailTester adds real-world inbox feedback. Together, you’re not guessing — you’re measuring actual outcomes.

According to RFC 5321, SMTP is the foundation of email delivery, but many senders ignore its validation layer. A single misconfigured header or rejected handshake can fail delivery even if the address is technically valid.

MailTester’s approach respects the full delivery stack: from DNS and handshake (swaks) to content routing (inbox tests). You can integrate both tools via API with SendGrid, HubSpot, or Klaviyo, so testing is part of your automated send process, not an afterthought.

Start with 100 free verifications at MailTester’s pricing page. Use swaks locally, then scale with MailTester’s bulk verification for large lists. The result? Fewer bounces, better reputation, higher inbox placement.

Conclusion: Use swaks to Build Confidence, Not Just Test Addresses

swaks is not a substitute for a robust email verification or deliverability platform. It’s a tool for understanding the underlying SMTP behavior of an inbox — what happens when your message hits the server, how it responds, and where it fails.

By testing with swaks, you gain visibility into error codes, connection issues, and infrastructure-level barriers. This is critical when diagnosing why emails are being rejected — but it’s not scalable or accurate for list hygiene at scale.

For complete confidence, pair swaks insights with MailTester’s 98.9% accurate bulk verification, inbox placement testing, and real-time API. Only after validating addresses and testing delivery should you trust your list to go live.

Sources

• Benchmark testing of 15 major email service providers found about 10.5% of legitimate emails land in the spam folder and a further 6.4% go undelivered. — EmailTooltester deliverability benchmark (via WarmForge) (2026)
• Gmail requires bulk senders to keep user-reported spam rates below 0.3%, warning that rates above 0.1% already hurt inbox delivery — just 3 complaints per 1,000 emails crosses the line. — Google Email Sender Guidelines FAQ (2024)

Keep reading

• How to test email deliverability, spam score and rendering (complete guide)
• Testing HTML Email Variations for Spam Score Differences
• Testing Tap Target Size and Button Spacing on Mobile Email Clients
• Test Secondary Domain Placement Before Campaigns in 2026
• Prefers-Color-Scheme Media Query Support in Email Clients 2026

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

Can swaks test if an email lands in the inbox?

No. swaks only tests SMTP acceptance. It confirms whether a server accepted the message, not whether it lands in the inbox or is filtered as spam.

Is swaks free to use?

Yes. swaks is open-source and available at no cost. It’s commonly installed via package managers like apt, brew, or yum.

Does swaks work with Gmail and other major providers?

Yes. swaks can connect directly to Gmail’s SMTP server (smtp.gmail.com) using TLS and authentication, but may trigger rate limits or require app passwords.

What is the difference between swaks and MailTester?

swaks tests SMTP-level connectivity; MailTester tests actual inbox placement across real mail clients and validates address health, reputation, and risk.

How do I install swaks on macOS?

Use Homebrew: brew install swaks. If not available, compile from source or use the pre-release version via GitHub.

Can swaks detect if an address is disposable?

No. swaks only checks SMTP acceptance. It cannot determine whether an address is from a disposable provider without additional analysis.

Does swaks test DKIM or SPF?

No. swaks does not validate authentication headers — only the SMTP transaction outcome.

How often should I run swaks tests?

Run swaks tests during setup, after configuration changes, or when diagnosing deliverability drops — not routinely for every email.

Can I use swaks to test bulk list deliverability?

Yes, but it’s inefficient. Use mail verification tools like MailTester for bulk testing instead.

Why does my swaks test fail with 535 authentication error?

This likely means incorrect credentials, missing app password, or two-factor authentication enabled. Ensure you’re using an app-specific password for Gmail and similar services.

What’s the best tool to complement swaks for deliverability?

MailTester offers inbox placement testing, real-time email verification, and AI-assisted insights — ideal for validating full delivery, not just SMTP accept.

How accurate is MailTester’s verification?

MailTester’s email verification accuracy is 98.9%, based on live test data across major email providers and real-world delivery scenarios.