Introduction

JavaMail, now more commonly distributed as Jakarta Mail, performs mail sending synchronously by default. When you call a send method such as Transport.send(...), the current thread waits for the SMTP interaction to complete or fail, so any asynchronous behavior must be added by your application architecture rather than expected from the mail API itself.

What Synchronous Means for Mail Sending

A synchronous send means the calling thread blocks until the work finishes. That blocked time can include:

• resolving the mail host
• opening the TCP connection
• negotiating TLS
• authenticating
• transmitting the message
• waiting for server responses

So if you send mail directly inside a web request, the response time for that request now depends on the mail server.

Here is a normal blocking send:

1import jakarta.mail.Message;
2import jakarta.mail.PasswordAuthentication;
3import jakarta.mail.Session;
4import jakarta.mail.Transport;
5import jakarta.mail.internet.InternetAddress;
6import jakarta.mail.internet.MimeMessage;
7
8import java.util.Properties;
9
10public class MailExample {
11    public static void main(String[] args) throws Exception {
12        Properties props = new Properties();
13        props.put("mail.smtp.host", "smtp.example.com");
14        props.put("mail.smtp.port", "587");
15        props.put("mail.smtp.auth", "true");
16        props.put("mail.smtp.starttls.enable", "true");
17
18        Session session = Session.getInstance(props, new jakarta.mail.Authenticator() {
19            @Override
20            protected PasswordAuthentication getPasswordAuthentication() {
21                return new PasswordAuthentication("user", "secret");
22            }
23        });
24
25        MimeMessage message = new MimeMessage(session);
26        message.setFrom(new InternetAddress("[email protected]"));
27        message.setRecipients(Message.RecipientType.TO, "[email protected]");
28        message.setSubject("Hello");
29        message.setText("This call is synchronous.");
30
31        Transport.send(message);
32        System.out.println("Mail sent");
33    }
34}

The program does not reach the final print statement until Transport.send(message) has completed.

Make the Application Asynchronous, Not the API

If you want the rest of your application to stay responsive, run the blocking mail send in another thread, executor, or job system. That changes the behavior of your application, even though the underlying send call is still blocking inside its own worker thread.

A simple example with CompletableFuture looks like this:

1import java.util.concurrent.CompletableFuture;
2
3CompletableFuture.runAsync(() -> {
4    try {
5        Transport.send(message);
6    } catch (Exception e) {
7        throw new RuntimeException(e);
8    }
9});

Now the caller can continue immediately while the mail is being sent in the background.

In a server application, a managed executor is usually better than spawning ad hoc threads:

1import java.util.concurrent.ExecutorService;
2import java.util.concurrent.Executors;
3
4ExecutorService executor = Executors.newFixedThreadPool(4);
5
6executor.submit(() -> {
7    try {
8        Transport.send(message);
9    } catch (Exception e) {
10        e.printStackTrace();
11    }
12});

This is the right mental model: JavaMail is synchronous, but you can use it asynchronously by offloading the work.

Why This Matters in Web Applications

If a controller or servlet sends mail inline, a slow SMTP server slows the user-facing request. That may be acceptable for administrative tools, but it is often a poor fit for user registration, checkout, or notification-heavy flows.

Once you move mail sending to a background executor, you also change your failure model. A synchronous send throws an exception directly to the caller. An asynchronous send may fail later, after the HTTP response has already been returned.

That means you need an explicit plan for:

• logging failures
• retrying transient errors
• recording delivery attempts
• deciding what user-visible success means

For serious systems, a queue or background job processor is often better than a simple thread pool because it gives you durability and retry control.

Common Pitfalls

The biggest mistake is assuming that because email is network I/O, the library must already be asynchronous. It is not. A network call is still blocking unless the API or your surrounding architecture makes it otherwise.

Another issue is moving mail sending to a background thread without redesigning error handling. Once the result is asynchronous, exceptions no longer reach the original caller in a simple way.

Developers also sometimes create a new raw thread for every email. That can work briefly, but it is harder to manage than using a bounded executor or a real queue.

Finally, do not confuse "non-blocking for the request thread" with "non-blocking protocol implementation." Wrapping a blocking API in background execution changes application responsiveness, not the fundamental nature of the SMTP call.

Summary

• JavaMail mail sending is synchronous by default.
• 'Transport.send(...) blocks the calling thread until the SMTP operation completes or fails.'
• Asynchronous behavior comes from running that blocking call in another thread, executor, or job system.
• Once mail sending is async, you need explicit failure, retry, and observability handling.
• Choose architecture based on user-facing latency and delivery reliability requirements.