A leaked email delivery API key lets an attacker send mail as your organisation, from your authenticated domains and with your sender reputation, so phishing sent with it passes SPF, DKIM and DMARC checks that your recipients rely on. SendGrid, Mailgun and Mailchimp keys are created by developers and marketing teams, pasted into web applications, WordPress plugins and CRM integrations, and rarely appear in a secrets inventory. Most default to full account access, which also exposes contact lists, suppression data and message logs. This guide explains how each platform's keys, roles and restrictions work, how to scope keys to sending only, how to detect a leak or abuse, and how to respond. It is written for application security, email and messaging owners and secrets management teams. For the general SaaS key lifecycle see the SaaS API Token Security Guide; this page covers what is specific to email delivery platforms.
Key takeaways
- Email keys are impersonation keys. Mail sent through your account carries your domain's DKIM signature, so domain authentication proves the mail came from your provider account, not that you sent it.
- Use the narrowest key each platform offers. SendGrid Custom Access keys, Mailgun Domain Sending Keys and Mailgun RBAC roles can all be limited; Mailchimp Marketing and Transactional keys carry full account access, so isolate them by integration.
- Restrict by network where you can. SendGrid IP Access Management covers the UI, API and SMTP relay, and Mailgun supports an API IP allowlist.
- The formats are detectable. GitHub secret scanning has push protection and validity checks for SendGrid, Mailgun and Mailchimp keys, and Gitleaks has rules for each.
- Volume and destination are the abuse signals. Sudden sending spikes, new recipient domains, rising bounces and complaints, and campaigns nobody scheduled are how stolen keys show up.
How identity and access work on email delivery platforms
All three platforms separate the human login (with two-factor authentication and, on higher plans, single sign-on) from the API keys that applications use. The key types differ more than their names suggest.
| Platform | Key type | Access | How it is sent | Notes from vendor docs |
|---|---|---|---|---|
| Twilio SendGrid | API key: Full Access | All endpoints | Authorization: Bearer | Shown once; limit of 100 keys per account; a key cannot exceed its creator's permissions |
| Twilio SendGrid | API key: Custom Access | Endpoints and access levels you choose (for example Mail Send only) | Authorization: Bearer | Use for every application |
| Twilio SendGrid | Billing Access, Email Address Validation Access | Billing endpoints only; validation endpoints plus read access to reporting | Authorization: Bearer | Billing calls need their own key |
| Mailgun | Primary account / account API key | Full CRUD on all endpoints and all sending domains | HTTP Basic, username api | Shown once |
| Mailgun | Domain Sending Key | POST to /messages and /messages.mime for one domain only | HTTP Basic | Created under the domain's sending keys settings |
| Mailgun | RBAC key | Admin, Developer, Analyst or Support role | HTTP Basic | Enterprise and some Business plans; role fixed at creation |
| Mailchimp | Marketing API key | Full account access, limited by the creating user's role | API key with data centre suffix | Shown once; keys created on or after 22 June 2026 expire after one year |
| Mailchimp | Transactional (Mandrill) key | Full Transactional account access | "key" field in the JSON body | Shown once; treat like a password |
Two behaviours matter for offboarding. On Mailchimp, revoking a user's access removes the API keys that user generated, which protects against leavers but can break integrations a leaver set up; create integration keys from a dedicated, documented user. SendGrid's documentation does not say that removing a teammate deletes the keys they created, so check the key list and delete them explicitly when someone leaves. SMTP is a parallel path: SendGrid's SMTP relay authenticates with an API key as the password, and Mailgun SMTP credentials are separate secrets per domain, so inventory both.
Admin roles and privileged access
| Platform | Role | Privilege level | Control |
|---|---|---|---|
| SendGrid | Admin teammate | Full access, can create other admins, manage teammates and billing, impersonate subusers | Two or three named people; SSO where the plan allows |
| SendGrid | Restricted teammate (Developer, Marketer, Accountant presets or custom) | Only the features granted | Default for staff and agencies |
| SendGrid | Read-only teammate | View only | Auditors and support |
| Mailgun | Admin | Full administrative access to all endpoints | Restrict; prefer Developer for engineers |
| Mailgun | Developer, Analyst, Support | Technical endpoints; read-only metrics; mostly read with some management writes | Match role to job |
| Mailchimp | Admin | Can see API keys other users generated | Review key list quarterly |
| Mailchimp | Manager | Can generate own API keys | Limit who holds Manager |
- Enforce 2FA for every login: SendGrid password teammates set up 2FA during onboarding, subusers set up their own, and once 2FA is on SendGrid stops accepting username and password Basic authentication for API calls. The 2020 wave of hacked SendGrid accounts, sold and used to send phishing that many organisations' filters let through, came from cracked and reused passwords.
- Use SSO for large teams: SendGrid SSO teammates are available on Pro and Premier plans and can be limited to specific subusers.
- Separate tenants: SendGrid subusers and Mailgun subaccounts let you split brands or business units so one key cannot send for every domain.
Integrations, API tokens and service accounts
Choosing the right key
| Use case | SendGrid | Mailgun | Mailchimp |
|---|---|---|---|
| Application sends transactional mail | Custom Access key with Mail Send only | Domain Sending Key for that domain | Transactional key in its own account or subaccount |
| Reporting or analytics tool | Custom Access, read-only stats | RBAC Analyst key | Key created by a user with a limited role |
| Infrastructure automation (domains, webhooks) | Custom Access with the specific settings scopes | RBAC Developer key | Dedicated integration user |
| Third-party plugin or SaaS connector | Separate Custom Access key per plugin | Domain Sending Key | One named key per integration |
Where keys leak
- Web and CMS plugins: SMTP and mailer plugins store provider keys in the CMS database and settings screens. The Gravity SMTP CVE-2026-4020 case exposed stored mail API keys and SMTP passwords through an unauthenticated REST endpoint, with Mailgun credentials confirmed leaked at one host.
- Front-end code and mobile apps: Mailchimp explicitly does not support client-side CORS calls or embedding keys in mobile apps. Any key in a browser bundle is public.
- Repositories and environment files: SendGrid's docs recommend an environment variable named
SENDGRID_API_KEYand warn against committing keys; scanners still find them in.envfiles and sample code. - The provider itself: in the Mailchimp breach attackers used a hijacked internal support tool to obtain customer API keys, which Mailchimp then disabled, and affected customers' lists were used for phishing. Per-integration keys make that kind of forced revocation survivable.
- Screenshots and tickets: Mailchimp notes that blurring a key in a screenshot or video is not enough.
Store keys in a secrets manager and inject them at run time; see the Secrets Management Guide. The Twilio Credentials Security Guide covers the wider Twilio account, which SendGrid accounts may sit under when using Twilio Unified Login.
Webhooks are credentials too
Event webhooks deliver bounces, opens and inbound mail to your endpoints. Mailgun signs each webhook: concatenate the timestamp and the 50-character token, compute an HMAC-SHA256 with your webhook signing key, and compare the hex digest with signature. Mailgun recommends caching tokens to reject replays, optionally rejecting stale timestamps, and its webhook requests carry a TLS client certificate with the Common Name webhooks.mgsend.net. A leaked signing key lets an attacker forge events, for example fake unsubscribes or bounces, so store it with the API keys.
Logging and detection
Secret scanning coverage
| Credential | GitHub secret type | Push protection | Validity check | Gitleaks rule and anchor |
|---|---|---|---|---|
| SendGrid API key | sendgrid_api_key | Yes | Yes | sendgrid-api-token, prefix SG. |
| Mailgun API key | mailgun_api_key | Yes | Yes | mailgun-private-api-token, key- followed by 32 hex characters near the word mailgun |
| Mailgun SMTP credential | mailgun_smtp_credential | No (public repositories only) | No | None specific |
| Mailgun webhook signing key | None | n/a | n/a | mailgun-signing-key |
| Mailchimp API key | mailchimp_api_key | Yes | Yes | mailchimp-api-key, 32 hex characters plus a data centre suffix such as -us12 |
| Mailchimp Transactional key | mandrill_api_key | No (public repositories only) | No | None specific |
Only the SendGrid key has a fixed prefix; Mailgun and Mailchimp rules rely on nearby keywords, so keys stored under neutral variable names can be missed. Add custom patterns or a generic high-entropy rule; see the Generic API Key Detection Guide and the Git Secret Scanning Guide.
Abuse signals
- Sending volume: hourly sends per key or sending domain against a baseline; abuse is usually bursty and out of hours.
- Recipients and content: new recipient domains, mail to large free-mail lists, and new templates or campaigns nobody scheduled.
- Deliverability: sharp rises in bounces, spam complaints and blocklist hits, and DMARC aggregate reports showing your provider's IPs sending unusual volume for your domain.
- Configuration changes: new API keys, new teammates, new sending domains, changed webhook URLs and IP allowlist changes.
- Access attempts: SendGrid's IP Access Management shows recent access attempts, including blocked ones.
DMARC aggregate reporting is the external control: the DMARC, SPF and DKIM Guide explains how to read it and how to keep provider include records limited to the providers you actually use.
Metrics: number of full-access keys in use (target zero for applications); share of keys mapped to an owner and integration; keys older than the rotation period (Mailgun suggests at least quarterly, Mailchimp at least yearly); mean time from leak alert to revocation; share of accounts with IP restrictions enabled.
Hardening baseline
- Inventory: list every key, SMTP credential, webhook signing key and teammate across all accounts, subusers and subaccounts, with owner and integration. Remove keys with no known user.
- Enforce login security: 2FA for every user, SSO where available, two or three admins only.
- Reissue narrow keys: for each integration create a SendGrid Custom Access key, a Mailgun Domain Sending Key or RBAC key, or a dedicated Mailchimp key. Deploy, confirm sends succeed, then delete the old key. SendGrid and Mailchimp cannot restore a deleted or revoked key, so keep the old key until the new one is proven, and use a staging subuser or domain to test first.
- Restrict networks: enable SendGrid IP Access Management or the Mailgun IP allowlist for fixed egress addresses. Add the administrator's own IP first: SendGrid warns that removing it can lock you out and that recovery needs identity verification through support.
- Segment domains: send marketing and transactional mail from different subdomains and accounts so one key cannot send as the corporate domain.
- Turn on detection: push protection, scanning of CMS databases and backups, and alerts on sending spikes and configuration changes.
- Rotate on a schedule and on every staff change for anyone who could see keys.
Small organisations with one website and a newsletter should at least use a sending-only key for the site, 2FA on every login and push protection. Larger organisations should centralise provider accounts, ban full-access keys in applications by policy and monitor sending through the SOC.
Leak response
- Delete or revoke the key at the provider immediately; deleting it in the plugin or application alone does nothing.
- Review sends since the earliest possible exposure: recipients, templates, links and volume. If phishing went out, warn recipients and your own users.
- Check for persistence: new keys, teammates, sending domains, webhook URLs and changed suppression lists.
- Issue a narrow replacement, then rotate any SMTP credential and webhook signing key stored in the same place.
- Follow the Phishing Incident Response Playbook where malicious mail was delivered.
Framework mapping
| Control area | NIST SP 800-53 Rev 5 | NIST CSF 2.0 | ISO/IEC 27001:2022 Annex A | MITRE ATT&CK |
|---|---|---|---|---|
| Key inventory, scope and rotation | IA-5, AC-6 | PR.AA-01, PR.AA-05 | A.5.17 Authentication information | T1552.001 Credentials In Files |
| Admin and teammate access | AC-2, IA-2 | PR.AA-05 | A.8.2 Privileged access rights | T1586.002 Email Accounts |
| Network restriction | AC-17 Remote Access | PR.AA-05 | A.8.20 Networks security | T1078.004 Cloud Accounts |
| Sending and configuration monitoring | SI-4, AU-6 | DE.CM-09 | A.8.16 Monitoring activities | T1566 Phishing |
Common misconfigurations
- Full Access or account keys in web applications: a site that only sends password resets holds a key that can export contacts and create new keys.
- One key shared across plugins, environments and agencies: revocation becomes an outage, so it is postponed.
- Keys stored only in the CMS: plugin vulnerabilities and database backups expose them; nobody rotates them because nobody knows they exist.
- Logins without 2FA: a cracked password gives the attacker the console and the ability to mint fresh keys.
- Unverified webhooks: endpoints that accept unsigned events can be fed forged bounces and unsubscribes.
- Over-broad SPF and DKIM delegation: leftover provider records let any account on a provider you no longer use send as your domain.
Practitioner checklist
- Inventory keys, SMTP credentials and webhook signing keys across all accounts, subusers and subaccounts.
- Replace application keys with SendGrid Custom Access (Mail Send) keys or Mailgun Domain Sending Keys.
- Create one named Mailchimp key per integration from a dedicated user, and track the one-year expiry.
- Require 2FA for all users and SSO where the plan allows; keep admins to a named few.
- Enable SendGrid IP Access Management or the Mailgun IP allowlist for fixed egress IPs.
- Verify every webhook signature and reject replayed tokens.
- Enable push protection and scan CMS databases, backups and front-end bundles for keys.
- Alert on sending spikes, new keys, new teammates and new sending domains.
- Remove SPF includes and DKIM records for providers you no longer use.
Standards and references
- Twilio SendGrid: API keys
- Twilio SendGrid: IP Access Management
- Mailgun: API key management and RBAC
- Mailgun: Webhooks and signature verification
- Mailchimp: About API keys
- Mailchimp Developer: Transactional API quick start
- GitHub Docs: Supported secret scanning patterns
- Krebs on Security: SendGrid under siege from hacked accounts
Related NHI Mgmt Group resources: SaaS API Token Security Guide · Email Authentication for Developers Guide · API Key Management Guide · Email Identity and BEC Guide