go-mail for Go SMTP delivery

What go-mail handles for Go applications

wneessen/go-mail addresses the part of an application that sits between application data and an email transport. A Go program must assemble recipients, headers, bodies, encodings, and sometimes attachments or signatures, then hand the resulting message to an SMTP server or local sendmail command. The library presents these operations as a programmatic mail client rather than leaving the application to coordinate each step independently.

The intended audience is Go developers who need everyday transactional email and advanced mail workflows. The README lists attachment and inline embed support, Go templates, DKIM signing, S/MIME signing, middleware, request handling for MDNs and DSNs, EML import and export, file output, and custom SMTP error handling. It also supports several authentication mechanisms, including PLAIN, LOGIN, CRAM-MD5, NTLM, SCRAM variants, and XOAUTH2.

This is broader than a thin wrapper around `net/smtp`. The repository contains separate files for message construction, headers, encodings, templates, delivery clients, signing, EML handling, and errors. The README says the `smtp` package originated from Go's standard-library `net/smtp` package and was extended with authentication methods, logging, and concurrency safety.

go-mail message composition and delivery architecture

The library's architecture follows the stages of email delivery. Message code builds the RFC 5322 message, including address validation, common headers, body parts, attachments, and inline content. The message object implements `io.WriterTo` and `io.Reader`, which gives callers interfaces for producing or consuming the serialized message.

Encoding is handled as part of message generation. The repository includes encoding files and a `Base64LineBreaker`, while the v0.7.3 release notes specifically mention skippable UTF-8 support and improvements to that line breaker. Template support comes from Go's `html/template` and `text/template`, allowing generated content to be used for a body, an alternative part, an attachment, or an embed.

Delivery is separate from composition. The client supports SMTP, implicit SSL/TLS, explicit STARTTLS policies, contexts for cancellation and timeouts, UNIX domain sockets, and custom dial-context functions. The same SMTP connection can be reused concurrently, which avoids repeatedly creating a connection for every message in a suitable workload. A local sendmail command is also supported, giving deployments a transport path that does not require the library to speak directly to an SMTP server.

Signing and serialization add further stages. DKIM support and S/MIME signing with RSA or ECDSA operate on the message before delivery. EML import and export support moves messages between go-mail objects and files for storage or inspection in a mail user agent.

go-mail installation and the documented starting path

The README directs new users to the Getting started guide in the GitHub Wiki, with `go-mail.dev` as an alternative documentation location. The repository's `go.mod` declares the module as `github.com/wneessen/go-mail` and requires Go 1.26.0. It also declares dependencies on `golang.org/x/crypto v0.57.0` and `golang.org/x/text v0.42.0`.

The README does not include an installation command or a complete first-send program. The project says to use its Getting started guide for a quick start, so a precise import, client setup, credential variable, and send call cannot be reproduced from the README without guessing. The verified module declaration is:

module github.com/wneessen/go-mail

go 1.26.0

require (
	golang.org/x/crypto v0.57.0
	golang.org/x/text v0.42.0
)

This file establishes the module identity and dependency floor, but it is not an end-to-end installation tutorial. A first real use should begin with the project's Getting started guide, then configure the transport and credentials for the selected mail provider. The README confirms these capabilities, but it does not state a universal provider hostname, port, credential environment variable, or client initialization option.

SMTP security policies and authentication choices

go-mail makes transport security explicit in several areas. Implicit SSL/TLS and explicit STARTTLS are separate supported modes, and STARTTLS can be configured with different policies. That distinction matters because an SMTP deployment may require encryption from the beginning of the connection or may begin without encryption and upgrade through STARTTLS.

Authentication is not limited to one provider convention. The documented mechanisms cover CRAM-MD5, LOGIN, PLAIN, NTLM, SCRAM-SHA-1 and SCRAM-SHA-1-PLUS, SCRAM-SHA-256 and SCRAM-SHA-256-PLUS, and XOAUTH2. Context support is available for timeout and cancellation control. The README also documents custom dial-context functions, which can support proxying or DNS hooking.

For an application, these features are useful but also create configuration decisions that the library cannot make on the application's behalf. The developer must select the authentication mechanism accepted by the provider, decide whether implicit TLS or STARTTLS fits the server, and decide whether a reusable SMTP connection is appropriate for the workload. The README describes custom delivery error types and a pluggable SMTP error registry, but it does not document retry policy, delivery guarantees, or automatic provider failover. Those behaviors should not be inferred from the presence of an SMTP client.

Advanced message features and their boundaries

The strongest reason to choose go-mail over a minimal mail constructor is its handling of message complexity. Attachments can come from the file system, `io.Reader`, `embed.FS`, or `fs.FS`. Inline embeds support those same content sources. Common headers such as Message-ID, Date, Bulk-Precedence, and Priority can be generated, and middleware can allow third-party code to alter messages before delivery.

DKIM and S/MIME are separate signing paths. The README identifies DKIM signature support separately from S/MIME message signing with RSA and ECDSA. A service that needs domain-level signing can therefore use a signing mechanism, but the developer still has to supply the appropriate configuration and key material. The README does not describe key generation, certificate handling, DNS record deployment, or key rotation procedures, so those parts require separate verification.

EML output and parsing provide another boundary. The message can be written to a file and later opened in a mail user agent, or an EML file can be parsed into a go-mail message. This supports inspection and file-oriented workflows. It does not make go-mail a mailbox management system. The repository describes message generation, serialization, and delivery, not inbox synchronization, searching, threading, or provider APIs for reading email.

Local sendmail support is similarly transport-specific. It can fit hosts that expose a local mail command, but applications still need to configure that command correctly and ensure the local mail transfer agent accepts the generated message.

go-mail compared with Go net/smtp

Go's standard library includes `net/smtp`, and go-mail's own `smtp` package started as a fork of it. That relationship gives a clear comparison point. A project using only `net/smtp` can send SMTP messages, but the README documents additional features in go-mail, including authentication methods, logging, concurrency safety, TLS policy options, contexts, signing, middleware, templates, attachments, EML handling, and local sendmail delivery.

The practical difference is scope rather than a different programming language. go-mail provides a higher-level message model and a larger delivery feature set. It fits application code that needs to generate structured messages with headers, alternative parts, files, embeds, signatures, or templates. The standard SMTP package is the narrower alternative when the application already owns message construction and needs only basic SMTP exchange.

The trade-off is compatibility and dependency surface. go-mail's `go.mod` requires Go 1.26.0 and adds `golang.org/x/crypto` and `golang.org/x/text`. Its feature set is larger, so adoption introduces more API and configuration decisions. The README states that the library follows the official Go release policy and supports the Go versions actively maintained by the Go team. The repository was not archived, and its last push was on 2026-10-13. The latest listed release is v0.8.1 from 2026-07-09.

Maintenance, licensing, and upgrade considerations

The repository is licensed under MIT, and the repository includes a `LICENSE` file and SPDX license identifiers. The license grants the permissions and imposes the conditions stated in that text. The dependency declarations and license files should still be reviewed when distributing an application that vendors the library or its dependencies.

The repository is not archived, and the last push was on 2026-10-13. Recent releases include v0.8.1 on 2026-07-09, v0.8.0 on 2026-07-04, and v0.7.3 on 2026-05-12. The v0.8.0 release title identifies native NTLM and DKIM support. The v0.7.3 release title identifies skippable UTF-8 support, `Base64LineBreaker` improvements, binary size reductions, and fixes.

An upgrade can involve more than a patch-level change because the project is versioned below v1.0 and its releases describe feature additions. Go 1.26.0 is also the stated compatibility floor in `go.mod`. Users should inspect the release notes for behavior changes and confirm the provider's supported authentication and signing configuration before changing a deployment.

Editorial conclusion

Adopt go-mail when a Go service needs programmatic email composition with SMTP delivery, signing, attachments, templates, middleware, or EML handling. Do not choose it for a project that only needs a minimal SMTP client or cannot use Go 1.26.0. Before adoption, verify the mail provider's authentication method, TLS policy, DKIM or S/MIME requirements, delivery error handling, and the operational cost of connection reuse.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. wneessen/go-mail on GitHub