Start

Why Simple Java Mail

Your code should describe the email, not build a MIME tree. See what Simple Java Mail handles and where Jakarta Mail still fits.

The gap it fills

Jakarta Mail is a solid foundation. Application code still needs something higher-level.

Sun JavaMail—and now Jakarta Mail—gives Java applications standards-aware messages, sessions, and transports. That machinery is valuable, but low-level: your code still has to turn a message into addresses, multipart structures, properties, connection management, and error handling.

Simple Java Mail was created to move that plumbing behind a usable API. The Jakarta transition changed stewardship and namespaces; it did not change the low-level way you work with mail. That is still the gap this library fills.

Library comparisons often miss the MIME layer. Supporting HTML, inline images, and attachments separately is not the same as combining them correctly in one message.

Why MIME structure matters

What the library takes care of

Describe the message. Let Simple Java Mail assemble it.

This is not about saving a few keystrokes. It is about keeping MIME parts, session properties, and transport cleanup out of your application code.

With Jakarta Mail directly, your code handles

  • Session properties and authentication
  • Address parsing and recipient types
  • Multipart/alternative and multipart/mixed nesting
  • Body parts, content IDs, filenames, and encodings
  • Transport connection and exception paths

That level of control is useful when you need it. You should not have to take it on just to send an attachment.

Application intentSimple Java Mail
Email email = EmailBuilder.startingBlank()
    .from("Sender", "sender@example.org")
    .withRecipients(recipient)
    .withSubject("Quarterly report")
    .withPlainText("Report attached.")
    .withHTMLText("<p>Report <b>attached</b>.</p>")
    .withAttachment("report.pdf", reportData)
    .buildEmail();

The same mailer, all the way through

It keeps helping when email gets difficult.

A friendly message builder only gets you so far. Simple Java Mail also handles reusable configuration, security, delivery choices, and troubleshooting through the same mailer API.

  1. 01
    Compose

    Declare content and recipients; the library chooses and builds the MIME structure.

  2. 02
    Configure

    Keep server settings, defaults, overrides, and validation on a reusable mailer.

  3. 03
    Protect

    Add transport verification, OAuth2, DKIM, or S/MIME at the appropriate layer.

  4. 04
    Deliver

    Use a single send, async results, an open connection, pools, or keyed clusters.

  5. 05
    Diagnose

    Test connections, inspect the final settings, route debug output, and read server replies.

  6. 06
    Extend

    Supply a Session, raw properties, generated MimeMessage, or custom sending operation.

Add complexity only when needed

New requirements stay with the mailer.

The first send stays readable. Later, configure signing, validation, proxies, pools, or clusters once instead of repeating them for every message.

ConnectwithSMTPServer(host, port)Anonymous or locally trusted SMTP
ProtectwithTransportStrategy(SMTP_TLS)Credentials, timeouts, verified transport
DefaultswithEmailDefaults(defaults)Validation, overrides, default signing
ScalewithClusterKey(workload)Async work, pooled connections, routing

Where the library goes deeper

Advanced features use the API you already know.

These are not separate integrations bolted onto the side. They are part of the same message and mailer model.

Direct control remains available

Jakarta Mail is still there when you need it.

Angus Mail implements Jakarta Mail underneath. Simple Java Mail focuses on sending; it does not replace Jakarta Mail's IMAP or POP support.

When you need lower-level control, supply a Jakarta Session, set raw properties, inspect the generated MimeMessage, or keep the Email builder while providing your own send operation.

Explore the extension points

Where it fits

When Simple Java Mail makes sense.

A good fit when

  • You are sending application email and need more than the basics.
  • You want one place for security, message rules, and sending configuration.
  • You configure through Java, properties, Spring, or a supplied Session.
  • You have unusual SMTP network or throughput constraints.

Probably not the fit when

  • You are building a mailbox client around IMAP or POP.
  • You intentionally want to construct every Jakarta Mail object directly.
  • You only use a provider-specific HTTP API and do not need to move messages between mail systems—unless custom sending makes the message builder useful.

Judge it by the code

See the API in context.

Compare the approaches, browse the full feature reference, or send one message and see how the API feels in your own project.