Application Email Credentials: SMTP Relay and Keys

Every web application, monitoring tool, CRM, WordPress site and line-of-business script that sends email holds a credential that lets it send as your domain, and most of those credentials have no owner, no expiry and no scope. They take several forms: a Google Workspace user password or app password typed into an SMTP setting, an Amazon SES SMTP password derived from an IAM access key, a Mailgun per-domain SMTP login, or a SendGrid API key used as an SMTP password. Because mail sent with them is signed and authenticated by your own provider account, a stolen credential produces phishing that passes SPF, DKIM and DMARC. This guide treats application email credentials as non-human identities: how each relay path authenticates, how to choose the least risky one, how to inventory, scope, rotate and monitor them. It is for email administrators, application owners and NHI and secrets teams. Microsoft 365 SMTP AUTH and its Basic authentication retirement have their own page, the Exchange Online SMTP AUTH Basic Auth Retirement guide, and printers and scanners are covered in the Printer, Scanner and Copier Service Accounts Guide.

Platforms are listed alphabetically; order is never a ranking. Product facts come from each provider's public documentation as checked in November 2026.

Key takeaways

An email credential is an impersonation credential. Whoever holds it can send authenticated mail from your domains, so treat it with the same ownership, scoping and rotation rules as a cloud access key.
Pick the authentication method before the credential. IP-restricted relay with no password, a scoped API key, OAuth and a stored SMTP password carry very different blast radii; choose per sender, not per platform.
Personal mailbox passwords are the worst option. Google turned off legacy password sign-in for SMTP, IMAP and POP on 14 March 2025, and its own help page says app passwords are not recommended and unnecessary in most cases.
Scope at the provider, not just in the app. SES IAM conditions such as ses:FromAddress and ses:Recipients, Mailgun domain-level credentials and SendGrid Custom Access keys with IP Access Management limit what a leaked credential can do.
Patching a leaky app does not revoke its secrets. Plan bulk rotation per provider in advance, because the procedure differs: SES needs a new IAM user or access key, Mailgun resets per domain, SendGrid replaces the key.

Why application email credentials are a distinct NHI class

Application email credentials sit at the junction of three teams: email administrators own the domain and DNS, developers or marketing own the sending application, and nobody owns the credential itself. That gap creates predictable properties:

Long-lived by design: SMTP passwords and sending keys rarely expire. Amazon SES documents no in-place SMTP password rotation; to change it you delete the SMTP user in IAM and generate a new set. SendGrid and Mailgun keys are shown once at creation and live until deleted.
Stored in awkward places: plugin settings tables, .env files, CI variables, appliance menus and container images. ATT&CK T1552.001 Credentials In Files is the usual collection route.
High trust at the recipient: the message leaves your provider with your DKIM signature. Abuse of a legitimate sending account maps to ATT&CK T1586.002 Email Accounts (resource development) when attackers use your account to phish others.
Invisible to identity governance: an SES SMTP user is an IAM user, a Google Workspace relay sender is a licensed user, and a Mailgun SMTP login lives only in the Mailgun console. None of them is likely to appear in your IGA or NHI inventory unless you add it.

The Gravity SMTP case shows the pattern at scale: an unauthenticated WordPress REST endpoint returned a diagnostic report containing the mail provider API keys, OAuth tokens and SMTP credentials configured in the plugin, and abuse continued after patching because the keys were not rotated. See the Gravity SMTP CVE-2026-4020 breach analysis.

The authentication methods compared

Every application sender uses one of five methods. The method decides what an attacker gets if the host is compromised.

Method	What the sender holds	What a thief can do with it	Best fit
IP-restricted relay (no password)	Nothing secret; the provider trusts the source IP	Send only from the trusted network, so the attacker needs a foothold there	Fixed-IP servers and an internal relay host that fronts many apps
SMTP AUTH with a user password	A real user's mailbox password	Send mail, and often sign in to the mailbox and other services	Avoid; migrate away
SMTP AUTH with an app password	A 16-character Google app password tied to a user	Send and read mail as that user until the password is revoked or the user's password changes	Legacy devices only, on a dedicated account
SMTP AUTH with a provider-issued SMTP credential	An SES SMTP password, Mailgun domain SMTP login or SendGrid key used as SMTP password	Send from anywhere unless network-restricted, within the credential's scope	Applications that only speak SMTP
HTTPS API with a sending key, or OAuth	A scoped API key, or a token issued to a registered client	Whatever the key scope allows; OAuth tokens expire and can be revoked centrally	Applications you build or can configure

Transport: whichever method you use, require TLS. RFC 8314 (Proposed Standard, January 2018) prefers Implicit TLS on port 465 for submission, keeps STARTTLS on 587 for a transition period, and says there is no significant security difference when both sides require TLS before authentication. It also says providers should deprecate cleartext submission as soon as practical. See the SMTP Security, STARTTLS and MTA-STS Guide for server-to-server transport.

Platform notes

Amazon SES

Identity model: each SMTP user is an IAM user. The SMTP user name is the access key ID and the SMTP password is derived from the secret access key with an HMAC-SHA256 chain that includes the Region, so credentials are unique to each AWS Region. AWS says not to derive SMTP credentials from temporary security credentials, which SES does not support for SMTP, and recommends a separate IAM user dedicated to SMTP.
Permission: the SMTP interface needs ses:SendRawEmail. Credentials created in the console on or after 6 September 2024 are placed in the group AWSSESSendingGroupDoNotRename, which carries the AmazonSesSendingAccess policy; older ones carry an inline policy and an InvokedBy=SESConsole tag, and AWS documents a migration to the group model.
Scoping: the default policy allows ses:SendRawEmail on "Resource": "*". Narrow it with SES condition keys: ses:FromAddress, ses:Recipients, ses:FromDisplayName and ses:FeedbackAddress, plus the global aws:SourceIp. A per-application user with a fixed From address and source IP turns a leaked password into a narrow tool.
Creating credentials is privileged: the console flow needs iam:PutGroupPolicy and iam:AddUserToGroup, which AWS classes as Permissions management, its highest IAM access level. Limit who can run it.
Rotation: delete the SMTP user (or its access key) and generate a new set. The password cannot be viewed again after the creation dialog closes. See the AWS IAM Roles vs IAM Users guide for why API senders on AWS should use roles instead.

Google Workspace

SMTP relay service: applications connect to smtp-relay.gmail.com, on port 587 with TLS. Without TLS, SMTP authentication is not available and IP address authentication must be used. The admin settings are an Allowed senders choice ("Only registered Apps users in my domains", "Only addresses in my domains" or "Any addresses (not recommended)"), authentication by "Only accept mail from the specified IP addresses" and/or "Require SMTP Authentication", and an optional "Require TLS encryption".
What SMTP authentication checks: the relay validates a Workspace user's email address and password, so a relay set to require SMTP authentication needs a user account behind every authenticated sender. Create a dedicated, non-personal account for that purpose, and prefer IP authentication from a fixed relay host.
Legacy password sign-in: Google's transition page states that from 14 March 2025 less secure app access was turned off for all Google Accounts, and CalDAV, CardDAV, IMAP, SMTP and POP stopped accepting legacy passwords. For scanners and devices it offers three options: configure OAuth, use another way to send, or configure an app password.
App passwords: a 16-digit passcode that requires 2-Step Verification, unavailable when 2-Step Verification uses security keys only or the account has Advanced Protection, and revoked when the account password changes. Google states they are not recommended and unnecessary in most cases.
Limits as a control: Google applies per-user relay limits (10,000 messages and 10,000 unique recipients per 24 hours) and a 100-recipient limit per SMTP transaction, based on the envelope sender. Separate senders keep one application's abuse from consuming another's quota. The Gmail Security Settings Guide for Workspace Admins covers the wider routing settings.

Mailgun

Identity model: SMTP credentials are set and managed per domain, under Send, Sending, Domain settings, SMTP credentials, so a credential cannot send for another domain in the account. Create one SMTP login per application rather than sharing the default.
Endpoint: smtp.mailgun.org; port 465 uses TLS from the start, and ports 25, 587 and 2525 accept STARTTLS. Mailgun recommends 587.
API alternatives: Domain Sending Keys allow only POST calls to the /messages and /messages.mime endpoints for the domain they were created under. Account API keys can carry roles, though Mailgun states Free and Basic plans can use only the Admin role.
Rotation: SMTP passwords are reset per credential with Reset password; the new value is displayed once. Account and sending keys are replaced by creating a new key, updating the application, then retiring the old key.

SendGrid

Identity model: SMTP to smtp.sendgrid.net uses the literal user name apikey and an API key as the password, so every SMTP sender is an API key. Create it with Custom Access and only the Mail permissions the sender needs, never Full Access.
Endpoint: ports 25, 2525 or 587 with STARTTLS, or 465 for TLS; SendGrid recommends 587 with TLS and advises using the hostname rather than hard-coded IP addresses.
Network restriction: IP Access Management, once the first IP is added, limits the UI, API and SMTP relay to allowed addresses (up to 1,000 entries in CIDR). Add your own administrative IP first, because removing it can lock you out.
Rotation: keys are shown once and cannot be retrieved; replace by creating a new key, updating the application and deleting the old one, after which calls with the deleted key are rejected. Accounts are limited to 100 API keys, which makes one key per application practical.

Key scoping, webhook signing and leak detection for SendGrid and Mailgun API keys are covered in depth in the SendGrid, Mailgun and Mailchimp API Keys Security Guide; this page focuses on their SMTP use.

Choosing the right design

Use this order of preference for each sender, and record the reason when you settle lower down the list.

No credential: the application sends to an internal relay (Postfix or similar) that accepts only named source hosts, and the relay authenticates to the provider by IP or a single tightly scoped credential. One secret to protect instead of fifty. Harden the relay itself with the Exim and Postfix Mail Server Hardening Guide.
Scoped API key or OAuth: where you control the code, use the provider's HTTPS API with a key limited to sending for one domain (Mailgun Domain Sending Key, SendGrid Custom Access) or an IAM role for SES, with no static key at all on AWS workloads.
Provider-issued SMTP credential: one per application, scoped (SES conditions, Mailgun per-domain login, SendGrid Mail-only key), network-restricted where the platform allows, stored in a secrets manager.
Dedicated account with app password: only for a device that supports nothing else, on a non-personal account with no other access, with a replacement date.

Situation	Small organisation	Large organisation
Few senders, one provider	One scoped credential per app in a password manager or vault; quarterly review	Not typical; still one credential per app
Many internal apps and devices	Provider IP relay from the office or a single cloud host	Central relay tier with per-source allow lists; apps hold no provider secret
Third-party SaaS sending as your domain	Use the SaaS vendor's own sending with domain authentication instead of handing over your credentials	Same, recorded in the sending sources register with an owner
Marketing and transactional mail	Separate keys or subaccounts for each stream	Separate subdomains, accounts and keys per stream, so reputation and blast radius stay apart

Implementation: a phased rollout

Inventory (weeks 1 to 3): list every sending source from SPF includes, DKIM selectors and provider consoles, then map each to the credential it uses: SES IAM users in the sending group, Workspace relay settings and accounts with app passwords, Mailgun SMTP logins per domain, SendGrid keys. Record owner, host, method, scope and creation date in the Email Sending Sources Inventory Template.
Assign ownership: every credential gets a named human owner and a system. Credentials nobody claims after a deadline are candidates for disabling. The approach in How to assign owners to orphaned service accounts applies directly.
Split shared credentials: replace any credential used by more than one application with one per application, so you can rotate or revoke without an outage elsewhere.
Scope and restrict: add SES conditions, move Mailgun senders to per-domain logins, change SendGrid keys to Custom Access, add IP restrictions, and set the Workspace relay to require TLS and limit allowed senders to addresses in your domains.
Move secrets into a vault: remove credentials from plugin settings, repositories and images, and inject them at runtime. See the Secrets Management Guide.
Test in a pilot: change one low-volume sender first, send to a seed mailbox, and confirm delivery and DKIM alignment. Keep the old credential active but monitored for a short overlap window.
Cut over and revoke: switch the remaining senders, then delete old credentials. Rollback is the overlap window: if delivery fails, revert the application setting while the old credential still exists, never by recreating a broad credential.
Rehearse bulk rotation: write the per-provider procedure and time it, because a plugin vulnerability or repository leak can force rotation of every credential at once. The Credential Rotation at Scale guide covers the mechanics.

Detection and measurement

Abuse of an application credential looks like normal sending from the provider's side, so detection relies on baselines per sender.

Volume and recipient anomalies: a sender that normally mails 200 internal users suddenly mailing thousands of external addresses, or hitting provider limits such as the Workspace per-user relay limits.
New From addresses or display names: transactional senders should use a fixed From; a new display name such as an executive's is a strong signal.
Bounce and complaint spikes: sudden rises in hard bounces or spam complaints often precede reputation damage.
Source changes: authentication from a new IP or ASN, visible in SendGrid's Recent Access Attempts list and in your relay logs.
Credential lifecycle events: creation of SES SMTP users and access keys in CloudTrail, app password creation in Workspace audit logs, new keys in provider consoles. See the Google Workspace Audit Log Detection Guide.
Leaks: secret scanning on repositories and build output for provider key formats; triage per the Developer Secret Scanning Triage guide.

Metric	Target	Why it matters
Sending credentials with a named owner	100%	Unowned credentials are the ones that survive offboarding
Credentials shared by more than one application	0	Shared credentials cannot be rotated safely
Senders using a personal mailbox password or app password	Falling to 0, each with a replacement date	Tracks the riskiest method
Credentials with sender, recipient or network restriction	Above 90%	Measures blast radius reduction
Median age of SMTP passwords and sending keys	Within your rotation standard	Shows rotation actually happens
Time to rotate all credentials for one provider (drill)	Hours, not days	Readiness for a mass leak

Where identity fits

An application email credential is a non-human identity with three linked objects: the credential, the account it belongs to (IAM user, Workspace user, provider login or key), and the domains it can send for. Govern all three. Include them in access reviews, disable them when the owning application is retired, and record them in your NHI inventory with the same fields as any other service credential. The NHI Inventory Reconciliation guide shows how to keep that inventory matched to what the providers actually hold.

Framework mapping

Framework	Reference	How it applies
NIST SP 800-53 Rev. 5	AC-2 Account Management	Owner, purpose and review for every sending account and SMTP user
NIST SP 800-53 Rev. 5	IA-5 Authenticator Management	Storage, rotation and revocation of SMTP passwords, app passwords and keys
NIST SP 800-53 Rev. 5	SC-8 Transmission Confidentiality and Integrity	Require TLS for submission and relay
NIST SP 800-53 Rev. 5	AU-6 Audit Record Review, Analysis, and Reporting	Review sending baselines and credential lifecycle events
MITRE ATT&CK v20	T1552.001 Credentials In Files; T1586.002 Email Accounts; T1110.003 Password Spraying	Theft of stored credentials, abuse of sending accounts, spraying of password-based SMTP endpoints

Common failure patterns

One credential for everything: a single SMTP login shared by the website, the CRM and a monitoring tool means a leak in any of them forces an outage in all of them, so it never gets rotated.
Patching without rotating: the Gravity SMTP case showed exposed provider keys being used after the plugin was fixed; one abused sending domain belonged to a former customer whose credentials were still active.
Wide default scope: SES users left on "Resource": "*" with no conditions, SendGrid Full Access keys used for SMTP, Workspace relay set to allow any address.
Personal accounts as senders: an application authenticates as an employee's mailbox, so the credential leaves with the employee or breaks when they change their password.
Cleartext or optional TLS: submission on port 25 without TLS to an internal relay that forwards with a credential, exposing the credential on the wire.
Third parties given your credentials: a vendor asks for SMTP details to send on your behalf, and the credential then lives outside your control indefinitely.

Practitioner checklist

Every sending source is in the register with method, credential, owner, host and creation date.
No application authenticates with a personal user's password; app passwords exist only on dedicated accounts with a replacement date.
Each application has its own credential; none is shared.
SES SMTP users carry ses:FromAddress and, where possible, aws:SourceIp conditions.
Mailgun senders use per-domain SMTP logins or Domain Sending Keys; SendGrid SMTP keys use Custom Access with IP Access Management.
Workspace SMTP relay limits allowed senders to your domains and requires TLS, with IP authentication from fixed hosts.
Credentials live in a secrets manager, not in plugin settings, repositories or images.
Per-sender baselines for volume, recipients and From addresses alert on deviation.
A bulk rotation runbook exists per provider and has been timed in a drill.

Application Email Credentials Guide: Securing SMTP Relays, App Passwords and Sending Keys