If you need to send email in Java, the implementation is not complicated, but the production-safe version is more than a single call.

You need correct SMTP authentication, the right TLS mode, sane configuration storage, multipart support for HTML and attachments, and a way to verify the actual received email before shipping changes to users.

This guide shows how to send email in Java with SMTP using Jakarta Mail, how to build plain text and HTML messages, and how to test the inbox outcome safely.

Quick answer

For most Java applications, the reliable path is:

  1. use Jakarta Mail with SMTP
  2. keep SMTP credentials in environment variables
  3. send multipart messages for HTML and attachments
  4. use STARTTLS or implicit TLS consistently with the chosen port
  5. validate the received message in a controlled inbox before release

If you are using Spring Boot specifically, read Spring Boot email integration. This guide stays framework-agnostic and focuses on raw Java mail sending.

Add Jakarta Mail to your project

For Maven:

That gives you the modern Jakarta Mail API without depending on older examples.

Configure SMTP properties in Java

A basic SMTP session setup looks like this:

The important part is not just the code. It is keeping the host, port, username, password, and sender identity configurable across environments.

Related setup guides:

Send a plain text email in Java

Once the session exists, create a message and send it:

That is enough for simple notifications, but most product emails need HTML content and sometimes attachments.

Send HTML email in Java

For HTML content, use :

If you want both plain text and HTML, use a multipart alternative structure so clients have a fallback.

Send email with an attachment in Java

Attachments require multipart handling:

If you send receipts, exports, or reports, also review:

Common Java email sending failures

Most failures are operational rather than language-specific.

SMTP authentication errors

These usually come from:

  • invalid credentials
  • wrong username format
  • sender identity mismatch

TLS and port mismatch

Port usually pairs with STARTTLS. Port usually pairs with implicit TLS. Mixing those expectations can fail before login.

Local success but broken real email

A successful SMTP send does not prove:

  • the HTML rendered correctly
  • the right recipient got the message
  • the reset link exists and works
  • the attachment arrived intact

That is the exact gap teams run into when sending works but release-critical email workflows still regress.

Test Java email at the inbox level

This is where MailSlurp matters. Sending is only half the workflow. You still need to verify the received message before production changes go live.

A safe pattern is:

  1. create an isolated inbox
  2. trigger the Java email workflow
  3. wait for the message to arrive
  4. assert the subject, recipient, links, OTP, or attachment

That gives you evidence about the user-visible result, not just the SMTP transaction.

Useful routes:

Example test workflow after sending

If your release process depends on signup, reset, or notification email, add a check after the send step that validates the actual message in an inbox. That is what turns a code sample into a dependable workflow.

This is especially useful for:

  • account verification
  • password resets
  • magic links
  • invoices and receipts
  • attachment delivery

FAQ

What is the best Java library for sending email?

For straightforward SMTP email sending, Jakarta Mail is still the most common choice.

Should I use this instead of Spring Boot mail support?

If you are already in Spring Boot, use the framework integration. If you want framework-agnostic Java, Jakarta Mail is the direct path.

How do I test Java email safely?

Send to a controlled inbox, wait for the message, and assert the content that matters to the user journey.