Application-Sent Emails are a Blind Spot

Email security checklists are written to keep bad mail out. They tell you to filter spam, sandbox attachments, enforce multi-factor authentication, and train employees to spot phishing. That advice is sound. But there is a second way email hurts your organization: an attacker sends mail as you, through an application, an API key, or an email-sending service account you authorized. That mail is authentic in every technical sense, and none of the checklists we reviewed treat that as a risk to control.

We tested that assertion against 15 published email security checklists. This bulletin reports what we found, how we scored them, why the gap matters, and what to add to your own checklist.

Key findings

• 0 of 15 checklists treat a compromised application, a leaked API key or SMTP password, or a compromised email service provider (ESP) account as a way your domain can be abused.
• 13 of 15 touch outbound mail in some way, mostly by publishing SPF, DKIM, and DMARC records, throttling user mailboxes, or filtering outgoing spam from compromised employee accounts.
• 4 of 15 acknowledge that applications or third-party services send mail as your domain, but only as senders to authorize so their mail passes authentication. None names a compromised application, API key, or ESP account as a risk.
• 14 of 15 include employee training or phishing simulations.
• 10 of 15 cover SPF, DKIM, or DMARC, and 11 of 15 cover some form of mail logging, monitoring, or DMARC reporting.

The premise holds. Typical checklists invest heavily in teaching people to recognize suspicious mail. The systems that send as your domain appear only as something to authorize, never as something that can be compromised.

How we reviewed the checklists

We searched for “email security checklist” and related terms in early October 2026 and selected 15 distinct, publicly readable documents: eight from security and email vendors, two from managed service providers (MSPs), two from governments, two from nonprofits, and one checklist template. We read each one in full and searched it for terms like third-party, API, SMTP, application, marketing, outbound, credential, and compromised so that a passing mention wouldn’t be missed.

We excluded checklists available only behind a download form, pages that blocked automated access or no longer existed, end-user tip sheets, compliance-only checklists, and buyer’s guides for evaluating email security products. Two government documents are titled “best practices” or “guide” rather than “checklist”; we included them because they serve the same purpose for the organizations they address.

Each checklist was scored on four criteria, using only what the document itself says:

• A. App and ESP-sent mail abuse. Full means the checklist names the risk that an authorized sending path is abused (a compromised application or website, a leaked API key or SMTP credential, or a compromised ESP or marketing platform account) and gives at least one control for it. Outbound only means it covers outbound mail without that risk: publishing SPF, DKIM, and DMARC, listing third-party senders so they authenticate, outbound filtering or throttling of user mailboxes, preventing open relays, or compromised user accounts sending spam. None means outbound mail isn’t mentioned.
• B. Employee training on recognizing phishing, spam, or scams, including phishing simulations and direct advice to users.
• C. SPF, DKIM, or DMARC. Sender Policy Framework, DomainKeys Identified Mail, and Domain-based Message Authentication, Reporting and Conformance are the DNS-published standards that let receivers check whether mail claiming to be from your domain came from a system you authorized.
• D. Outbound logging or monitoring, including mail logs, traffic monitoring, or reviewing DMARC aggregate reports.

Results: 15 email security checklists scored

All documents were accessed on October 4, 2026.

Totals across all 15 checklists: A. App/ESP abuse: 0 Full, 13 Outbound only, 2 None. B. Training: 14 Yes. C. SPF/DKIM/DMARC: 10 Yes. D. Monitoring: 11 Yes.

What the checklists did say about outbound mail

The near misses are instructive, because they show the blind spot isn’t ignorance that applications send mail. It’s that the checklists don’t connect those applications, or their credentials, to an attacker.

• UpGuard, and the checklists from Guardian Digital and Process Street that follow the same structure, recommend rejecting internet mail that claims to be from your own domain. UpGuard then lists “web application forms that trigger emails sent from an internet web server” and “cloud services set to send as domain users” as legitimate exceptions to allow. Separately, it recommends a throttling policy so you can “prevent a compromised account or server from damaging your domain’s reputation,” and suggests “a remailer service such as SendGrid” for bulk mail. It never connects throttling, or any other control, to the web applications and cloud services it allows as senders, or to the credentials they hold. Process Street makes the same throttling point (“even if your account is compromised, this won’t cause any lasting damage to your reputation”) with the same gap.
• Libraesva’s outbound item warns that “some email security solutions automatically exempt an email from further checks if a domain or IP address is authorized – this can create a security risk for your organization.” That’s a real insight: authorized senders deserve scrutiny too. But the item is about filtering employee mail, and it doesn’t name applications, API keys, or ESP accounts.
• mailfloss asks you to “list every email service provider and third-party tool that sends email on your behalf” and to confirm that “no unauthorized sending services appear in DMARC reports.” Both are good practice. Neither helps when the sender is authorized and an attacker is using it.
• Adaptive Security warns that “compromised accounts represent one of the most dangerous outbound email threats,” meaning employee mailboxes. Its mentions of third-party senders are about authorization and deliverability: its SPF item lists every “third-party service permitted to send email,” it asks you to inventory “third-party integrations,” and it notes that forgetting their DKIM keys “causes the most delivery problems.”
• The Canadian Centre for Cyber Security recommends reviewing DMARC reports to “highlight any unauthorized senders attempting to spoof” your domain. Again, the threat is someone outside your authorized senders.

The guidance does exist, just not in the checklists. Email providers publish it for their own customers: Mailgun’s email security best practices cover IP allowlists for API keys, key rotation, and send-only keys per domain so that “if one application is compromised, the rest won’t be impacted.” MailChannels’ SMTP relay authentication guidance calls for unique credentials per application, logging every SMTP login, and suspending accounts that show abuse. Some institutions build outbound control into policy, too. Stanford, for one, limits outbound mail to registered servers that meet its security standards, list a 24/7 administrator, and keep mail logs for at least a year. None of that has made it into the general-purpose checklists most organizations reach for.

Why the blind spot matters

SPF, DKIM, and DMARC answer one question: did this message come from a system the domain owner authorized? When an attacker sends through your application, your API key, or your ESP account with your domain set up, the answer is yes. The message is signed with your DKIM key, leaves from servers your SPF record lists, and passes DMARC. Your recipients’ filters, and the phishing training their own employees received, are looking for mail that doesn’t come from you.

Attackers go looking for exactly this kind of access:

• A joint CISA and FBI advisory describes the Androxgh0st malware targeting .env files in Laravel web applications for credentials to services including Amazon Web Services (AWS), SendGrid, and Twilio. Its functions include abusing the Simple Mail Transfer Protocol (SMTP), “such as scanning and exploiting exposed credentials and application programming interfaces (APIs).”
• In 2025, Wiz observed an attacker use leaked AWS keys to send tax-themed phishing through a victim’s Amazon Simple Email Service (SES) account. In that case the attacker sent from its own domains and from third-party domains with weak DMARC protection, but Wiz is explicit about the wider risk: “If SES is configured in your account, attackers can send email from your verified domains.”
• KrebsOnSecurity reported a seller advertising “a large supply of cracked Sendgrid accounts,” valued because SendGrid’s reputation with mailbox providers gets mail into the inbox.

Our earlier article, Email Delivery Introduces Security Risk Exposure, walks through these and other incidents by risk vector: the provider, integration code, dependencies, credentials, and webhooks.

When your sending access is abused, the costs land on your account: the mail sent on your bill, abuse complaints against your account, and damage to the reputation of your sending domain and IP addresses. Wiz adds that mail sent from your verified domains “enables phishing that looks like it came from you.”

Add these items to your email security checklist

If your checklist came from one of the documents above, it probably needs a section on outbound application and service mail. Start with these items:

1. Inventory every system that sends as your domain, including applications, website forms, marketing platforms, CRMs, help desks, and invoicing tools, with a named owner for each. Your SPF record and DMARC reports are a good place to start.
2. Treat sending credentials as high-value secrets. Store API keys and SMTP passwords in a secrets manager, never in source control, client-side code, or mobile apps. Use one credential per application, scoped to sending only, and rotate them on a schedule and after any incident.
3. Restrict where credentials work. Where your provider supports it, allowlist the IP addresses that may use each key, and restrict each application to the sender addresses it needs.
4. Protect ESP and marketing platform accounts with phishing-resistant multi-factor authentication, least-privilege roles, and regular access reviews.
5. Set per-application sending limits based on normal volume, and alert on spikes, new recipient domains, or unexpected sender addresses.
6. Log every message your applications send: which application, which sender, which recipient, when, and the delivery result. Keep the logs where your security team can search them.
7. Review DMARC aggregate reports for your authorized senders too, not just unauthorized ones. A sudden jump in volume from a legitimate service is a signal.
8. Write an incident runbook for a leaked sending credential: how to revoke it, how to stop a single application from sending without stopping everything, and who notifies customers.

How a security-owned outbox server closes the gap

Most of those items are hard to do when every application talks to its email provider directly. Each team holds its own keys, sets (or doesn’t set) its own limits, and logs in its own way. The fix is architectural: route all application mail through one internal relay, or outbox server, that your security team owns. Applications hand messages to it over your internal network, and it is the only system that holds provider credentials.

That’s separation of concerns applied to risk: the application decides what to send, and the outbox server owns how it’s delivered safely. It also makes the outbox server a single point of enforcement for the checklist items above. A relay in this position can provide:

• Central credentials. Provider keys live in one hardened place with one rotation process. A leaked .env file or a compromised app no longer exposes a key that can send as your domain from anywhere on the internet.
• Sender allowlists. Each application may send only from the addresses and domains it’s approved for, so a compromised app can’t impersonate your CEO or your billing department.
• Logging and audit. Every message from every application is recorded in one place, giving your security team the observability that scattered provider dashboards don’t.
• Rate limits and anomaly alerts. Per-application limits stop one compromised app from turning into a spam cannon, and alerting on its records surfaces unusual volume or recipients.
• A kill switch. Because every application sends through one place, you can stop a single application from sending there, without rotating shared provider keys or redeploying anything.

OutboxServer is a self-hosted outgoing email service your applications call instead of an email provider. It holds the provider credentials, so applications never do. It enforces allowed senders, per-application rate limits, and recipient rules, and it records which application sent what, to whom, and whether it was delivered, bounced, or flagged as spam, with telemetry you can view directly or feed into the tools you already use.

An outbox server doesn’t remove the need for good practice. Applications still need to authenticate to it, the server itself must be hardened and monitored, and it doesn’t replace inbound filtering or employee training. What it does is turn a scattered set of internet-facing integrations, each with its own keys and habits, into one internal service your security team can see and control.

Limitations of this review

This is a sample of 15 checklists, not a census. Search results favor vendor content, and we excluded gated downloads, so checklists behind a sign-up form or inside paid frameworks may do better. The scores reflect what each document says, not what its publisher’s products do. One reviewer applied the rubric, and the criteria are published above so you can check our work against the linked sources.

Bottom line

The checklists most organizations start from teach people to distrust suspicious mail, and that training is nearly universal. The mail they don’t prepare you for is the kind nobody has reason to distrust: authentic messages from your own domain, sent through your own applications and email services by someone who shouldn’t be using them. Add outbound application and service mail to your checklist, and give your security team one place to enforce it.