Fork me on GitHub
Simple Java Mail
Simple API, Complex Emails

Feature Comparison Matrix

Due to the fact most libraries are based on JavaMail / Jakarta Mail, in theory all libraries should be able to do the same things if you start tweaking under hood directly on the related low level components (such as manually setting Session properties). However, since we are comparing Simple Java Mail in the context of its mission, being the easiest to use SMTP library in the world, when a library doesn't support a feature as first class API, it will be marked as not-supported in the matrix below.

Each feature is linked to the appropriate documentation.

All claims below were made objectively with due diligence and in good faith, but if you find any inaccuracies, please raise an issue.

Note 1: In 2023, it is surprising to find only a few major Java libraries for SMTP, next to Simple Java Mail. There seems to be a scarcity of libraries specifically focused on SMTP mailing, with Apache Commons appearing inactive and Spring Mail not receiving enough development as a primary library. Other libraries out there are rarely still active, or are too small and limited compared to Simple Java Mail to be considered a real alternative.

Note 2: As this comparison matrix is taking shape, and the source code of other SMTP libraries is being examined more closely, it is becoming apparent how much Apache Commons Email has been a half-hearted attempt at wrapping JavaMail in a useful API, that lost its momentum completely and ultimately failed as a project and seemingly has been abandoned (last release in 2017 and no meaningful code changes since, last verified Oct 2023). Therefore, remarks on feature differences will be mostly limited simply to "there was an attempt". The fact that they still refer to their Subversion repository on their homepage instead of their GitHub repository is a clear indication of their lack of comittment, let alone some vision for the future. Also, the fact that their home page still refers to JavaMail, which was succeeded by Jakarta Mail in 2019 (and by Angus in 2024), confirms this.

  Simple Java Mail Apache Commons Email Spring Mail
API simplicity

Clean, functional, fluent API

there was an attempt

Exposes low level api
focus on ease of integration,
not on ease of use

Actively maintained?

16 years and still going strong

last released 2017

Mostly just as part of
general Spring maintenance

Quality documentation

Excellent (searchable) with lots of examples

relies on your knowledge of
underlying JavaMail / Jakarta Mail

relies on your knowledge of
underlying JavaMail / Jakarta Mail

Lightweight?

298kb (core)

54kb

4.47Mb spring-context-support + deps
(165kb if you already have Spring)

Support for replying to / forwarding
emails?
CLI support for sending emails?
Can read Outlook .msg files?
Supports properties / property files?

for everything

limited to the most
basic server config

Native / built-in Spring support?
First class authentication?

no OAUTH2

no OAUTH2

Support for (authenticated) proxy?
Robust security?

there was an attempt

limited, moreover it relies
on you for Jakarta Mail properties

Safe-guards against CRLF injection attacks?
Advanced performance tuning?
All configuration can be inspected easily?
Ready for the async world?

only with Spring's @Async
(messy exception handling)

Has robust recipient parsing?

there was an attempt

(but no name defaults/overrides
or support for delimited strings)

Allows custom Session instance?
Custom content (and attachments)
transfer encoding?

2011 ticket (basic support)
finally declined in 2023

Supports custom messageId?
Supports custom sent date?
Basic feature set support
Auto-determines best
MimeMessage composition?
Supports iCalendar vEvent?
Supports DKIM signing?
Supports S/MIME
signing / encryption?
(sending / reading, +attachments)
Delivery / read receipt support?
(dispositionNotificationTo / returnReceiptTo)
Supports bounce address
Quality of Email address validation

delegates to JMail's
excellent (and fast) validation

delegates to JavaMail's / Jakarta Mail's
fallible implementation

delegates to JavaMail's / Jakarta Mail's
fallible implementation

Can be used just to test a server connection?
Emails can be serialized?

(partial support)

Library allows for custom sending logic?
Can set maximum allowed email size?
Support sender-level email defaults / overrides?