MailKit: a .NET IMAP, POP3 and SMTP client library built on MimeKit

What MailKit solves for .NET applications that speak mail protocols

The .NET base class library has long shipped System.Net.Mail, and the README's own framing is that MailKit is a mail client library built on top of MimeKit. The distinction matters. MailKit implements the client side of IMAP4, POP3 and SMTP, and it exposes the protocol extensions those servers advertise rather than hiding them behind a single Send method. The IMAP client lists support for IDLE, CONDSTORE, QRESYNC, SORT, THREAD, ACL, QUOTA and a long list of other extensions, each linked to its RFC. If your application needs to keep a live connection open and react to new mail as it arrives, or to synchronise flags and folders incrementally, that is the layer MailKit works at.

The audience is .NET developers building mail-aware software: desktop clients, migration tools, archiving jobs, helpdesk integrations, notification senders. It is a library, not a service. Nothing in the README suggests MailKit delivers mail for you; it connects to a server you already have credentials for. Teams that want an HTTP API and someone else handling IP reputation should look elsewhere, and that is not a criticism of the project, just a boundary of what a client library can be.

How the MimeKit and MailKit split works in practice

MailKit does not parse messages itself. Message construction and parsing live in MimeKit, and MailKit depends on it. That means a typical program touches two packages: MimeKit to build or read a MimeMessage, MailKit to move that message over the wire. The README presents them as separate NuGet packages, and there are also MimeKitLite and MailKitLite variants listed in the package table, which suggests a reduced build for cases where the full dependency set is unwanted.

The transport layer is where the extension support sits. The SMTP client covers SIZE, DSN, AUTH, 8BITMIME, PIPELINING, BINARYMIME, CHUNKING, STARTTLS and SMTPUTF8. The POP3 client covers TOP, UIDL, EXPIRE, LOGIN-DELAY, PIPELINING, SASL, STLS, UTF8, UTF8=USER and LANG. The IMAP client has the longest list. Authentication is handled through SASL mechanisms shared across all three clients: CRAM-MD5, DIGEST-MD5, LOGIN, NTLM, PLAIN, SCRAM-SHA-1, SCRAM-SHA-256 and SCRAM-SHA-512 in their plain and PLUS forms, OAUTHBEARER and XOAUTH2. The repository also contains GMailOAuth2.md and ExchangeOAuth2.md at the top level, which indicates the OAuth paths are documented separately rather than only in the main README.

Proxying is built in, with SOCKS4, SOCKS4a, SOCKS5 and HTTP/S listed. Client SSL/TLS certificates are supported across all three protocols, and SSL-wrapped connections are available through the smtps, pops and imaps protocol names. The README states that all APIs are cancellable and that async APIs are available, which matters if you are writing a service that must honour shutdown signals.

Installing MailKit from NuGet and finding a first working example

The README does not contain an install walkthrough. It links to the NuGet package pages in the badge table, so the package name is the entry point for a .NET project. The README gives no CLI command, no project file snippet and no configuration keys, so there is nothing further to copy from it here.

The repository layout is more useful than the README for a first run. It ships sample projects under samples/, including samples/ImapClientDemo, samples/ImapIdle and mobile variants for Android and iOS. Those are the closest thing to a worked example in the tree, and reading them is a faster route to correct usage than guessing at the API surface. The FAQ.md file at the top level is the other place to look for answers the README does not give.

What the README does establish is the shape of the API: separate clients for SMTP, POP3 and IMAP4, SASL authentication shared across all three, cancellable and async APIs, and SSL-wrapped connections selectable through the smtps, pops and imaps protocol names. Beyond that, the README stops. There is no documented default port, no documented default TLS mode and no quick-start code block. If you need a copy-paste example before you commit to the library, the samples directory is where you will find it, and the README is not.

Where MailKit is the wrong tool

MailKit is a client. It does not run an SMTP server, does not queue mail for retry, does not manage sending IPs and does not process bounces or complaints. If your requirement is transactional email at volume with deliverability reporting, a hosted sending API is the right layer and MailKit is beneath it. You would be reimplementing the parts of that service you actually need.

The second limitation is documentation depth in the repository itself. The README is largely a feature list with RFC links. It does not document rollback behaviour, retry semantics, connection recovery after a dropped socket, or how partial IMAP synchronisation should be resumed. The FAQ.md file exists at the top level and is the place to look before assuming an answer is missing entirely, but the README alone will not tell you how to recover a half-finished mailbox sync. For IMAP work in particular, the difference between a demo and a production synchroniser is almost entirely in that recovery logic, and you will be writing it.

The third is that the extension lists describe what MailKit can speak, not what any given server offers. A provider that does not advertise CONDSTORE or QRESYNC will not give you the incremental sync behaviour those extensions enable. The README does not claim otherwise, but the length of the list can create the wrong expectation.

MailKit compared with System.Net.Mail.SmtpClient

The most common comparison in .NET is against System.Net.Mail.SmtpClient, which is the built-in type that has been in the framework for years. The practical difference is scope. SmtpClient sends messages. It does not implement IMAP or POP3 at all, so if you need to read a mailbox, it is not an option regardless of quality. Its extension coverage is narrower, and the API surface is smaller and less configurable around authentication and TLS negotiation.

MailKit covers three protocols with one consistent client model, supports the full SASL list including OAUTHBEARER and XOAUTH2, and lets you select proxy types and client certificates. It also returns MimeKit message objects rather than the older MailMessage type, which gives you a proper MIME tree to walk when you need to inspect parts, attachments or encodings. The cost is an extra dependency and a larger API to learn. For a one-off notification email, SmtpClient is less code. For anything that reads mail, authenticates with OAuth, or runs behind a proxy, MailKit is the more complete answer.

Maintenance, licensing and what upgrading involves

The repository is not archived, and the last push was on 2026-09-14. That is recent enough that the project is being touched, though the README gives no release cadence and no release notes were available to review. ReleaseNotes.md exists at the top level, so version history is maintained in the repository rather than only on the package feed. The project is MIT licensed, which permits commercial use, modification and redistribution provided the licence text and copyright notice are preserved. That is a permissive arrangement, but it is not legal advice and your own counsel should confirm how it interacts with anything you redistribute.

Upgrade cost depends on how much of the API you touch. The protocol clients and the SASL mechanism list are the stable core. The riskier surface is anything that depends on a server extension, since a change in how an extension is exposed can ripple into your code. The repository includes AotCompatibility/ and a Telemetry.md file, which suggests ahead-of-time compilation and telemetry behaviour are tracked as first-class concerns; if you publish trimmed or AOT-compiled binaries, check those before assuming a version bump is free. The README does not document a migration path between major versions, so ReleaseNotes.md is the file to read before upgrading.

Editorial conclusion

Adopt MailKit if you are writing a .NET application that must talk IMAP, POP3 or SMTP directly and you want the protocol details exposed rather than hidden behind a hosted API. Do not adopt it if you need deliverability tooling, bounce processing or an SMTP relay, because it is a client library and the README describes no such services. Before committing, verify which SASL mechanisms your provider requires, check whether you need MimeKit or the MimeKitLite build, and confirm that your target framework is covered by the packages on NuGet.

Frequently asked questions

Official sources

1. Issues
2. jstedfast/MailKit on GitHub
3. License: MIT
4. Project website
5. README