Guide

Send Email from Jenkins Pipelines

Jenkins email usually means the Email Extension plugin plus an SMTP server you configure globally — and an app password that breaks when a provider tightens auth. The CLI offers a simpler route: call nylas email send from a post block and let the build notify people over API. No plugin, no SMTP host, no mailbox password in Jenkins config. This guide adds email to a declarative pipeline, scopes it to failures, and keeps the API key in Jenkins credentials.

Written by Prem Keshari Senior SRE

Verified — CLI 3.1.16 · Gmail, Outlook · last tested June 8, 2026

Command references used in this guide: nylas email send, nylas auth config, and nylas auth whoami.

How do you send email from a Jenkins pipeline?

You send email from Jenkins by calling nylas email send in a sh step, typically inside a post block so it runs after the build. The CLI sends over HTTPS with an API key, so the agent needs no SMTP server and the controller needs no Email Extension plugin. One shell line replaces the global mail configuration most Jenkins setups carry.

The contrast with the standard approach is the maintenance. Jenkins' Email Extension plugin requires an SMTP host, port, and credentials configured at the system level, and a mailbox password there breaks when the provider disables basic auth. The CLI moves auth to an API key in Jenkins credentials and sends over API, which survives those provider changes.

// Jenkinsfile (declarative) — notify on failure
pipeline {
  agent any
  environment { NYLAS_API_KEY = credentials('nylas-api-key') }
  stages {
    stage('build') { steps { sh 'make build' } }
  }
  post {
    failure {
      sh '''
        curl -fsSL https://cli.nylas.com/install.sh | bash
        export PATH="$HOME/.config/nylas/bin:$PATH"
        nylas auth config --api-key "$NYLAS_API_KEY"
        nylas email send --to oncall@example.com \
          --subject "FAILED: $JOB_NAME #$BUILD_NUMBER" \
          --body "See $BUILD_URL" --yes
      '''
    }
  }
}

How do you store the API key in Jenkins?

Store the key as a Jenkins credential of type “Secret text” and bind it with the credentials() helper, which exposes it as an environment variable masked in the build log. Reading $NYLAS_API_KEY in the sh step then authenticates the CLI with nylas auth config --api-key. The secret never appears in the Jenkinsfile or the console output.

This keeps the credential out of source control and scoped to the jobs that need it via folder-level credentials. Confirm the binding worked with nylas auth whoami during setup, then drop it once the pipeline is stable. Rotate the key if a build log ever exposes it, and prefer a dedicated key for CI so you can revoke it without affecting other integrations.

How do you control when the email sends?

Control timing with the post conditions Jenkins provides: failure for broken builds, fixed for the first green build after a failure, unstable for test regressions, and always if you genuinely want every run. Using failure plus fixed is a common pairing — you hear when it breaks and when it recovers, and nothing in between.

Put the build context in the message using the environment variables Jenkins injects: $JOB_NAME, $BUILD_NUMBER, and $BUILD_URL. A subject like “FAILED: deploy-prod #482” with the build URL in the body tells the on-call engineer what broke and links them straight to the logs, which is the entire point of a failure email.

  post {
    failure { sh './notify.sh FAILED' }
    fixed   { sh './notify.sh RECOVERED' }
  }
  // notify.sh wraps: install, auth config --api-key, nylas email send --yes

Next steps