Send email from an Android app

Never ship SMTP credentials in an app

Any credential you compile into an APK is public. Decompile, extract, abuse: that is the lifecycle of an SMTP password shipped in an app, and it ends with your domain on a blocklist.

So Android email is two different jobs. When the USER should send mail (feedback, share, contact), hand off to their own mail app with an Intent. When YOUR APP should send mail (receipts, alerts, resets), the send belongs on your backend, one API call away.

Server-side infrastructure gets to be strict in ways an APK never can. On our own forwarding relay, TCP 2525 is firewall-restricted to our API host, TLS and exact SMTP authentication are mandatory, and every single-recipient route and MX snapshot is HMAC-signed, with unsigned or replayed requests rejected outright. Keep the credential where that kind of enforcement exists.

One POST, and the send is handled

val intent = Intent(Intent.ACTION_SENDTO).apply {
    data = Uri.parse("mailto:")
    putExtra(Intent.EXTRA_EMAIL, arrayOf("[email protected]"))
    putExtra(Intent.EXTRA_SUBJECT, "Feedback")
}
startActivity(intent)

For app-generated email, the client calls your backend and the backend makes the same one POST every other page on this guide shows. The key never leaves your server, and delivery events land on your webhook, not in the app.

Scopes bite even when you do keep the key server-side. George, our CEO, hit this inside our own product: our SendGrid connection test probed an endpoint that requires the Sender Authentication scope, so a valid least-privilege Mail-Send key came back 403 and got reported invalid. He swapped the probe to GET /v3/scopes, which any valid key can read while invalid keys still 401, and the regression test went five for five. The lesson for your backend is to test credentials against an endpoint the key is actually scoped for.

Distribution logic applies to your agent tooling too: Codex and ChatGPT now install the email connection with one click through the OpenAI app store. The pattern is the same one you ship by: the store handles trust, the platform handles the work.

Full parameters, responses, and error codes live in the REST API docs and the API reference.

import requests

requests.post(
  "https://api.nitrosend.com/v1/messages",
  headers={"Authorization": f"Bearer {KEY}"},
  json={"to": to, "subject": subj,
        "html": body})

{ "id": "msg_9f2c",
  "status": "accepted" }

And the part no library gives you

The same account exposes an MCP server, so the agent writing your code can also run your email. Point Claude, Cursor, or Codex at api.nitrosend.com/mcp and it composes, previews, and stages sends, with a human approving every one. The API is for your code. The MCP is for your agent. One platform either way.

Every send comes back with a message ID, and delivery events follow on your webhook: delivered, opened, bounced. No dashboard required to know what happened. Mobile sends still answer to the same rules: how to set up SMTP if you keep a mail server in the loop, and SPF, DKIM and DMARC authentication once real users are receiving.

Go deeper

Everything above still assumes your app or your backend is the one composing the request. Increasingly it does not have to be. Describe the notification or the receipt to Claude, Cursor, or Codex and Nitrosend's MCP server drafts and sends it through the same account, no Retrofit call and no Kotlin coroutine to write.

FAQ

How do I send email from an Android app?

For user-composed mail, launch their mail app with an ACTION_SENDTO Intent. For app-generated mail like receipts and alerts, call your backend and let it send through an email API, so no credential ships in the APK.

Can I use SMTP directly from Android?

Technically yes, practically never: credentials inside an APK are extractable, mobile IPs have no sending reputation, and mailbox providers treat that mail as spam. Send from your backend.