The email arrives from Amazon’s own servers, passes every standard authentication check your security gateway runs, and looks completely legitimate — because it came from a real Amazon service that an attacker bought access to with stolen AWS credentials.
The Mechanics of Legitimate Phishing
Amazon Simple Email Service (SES) is AWS’s bulk email platform, used legitimately by millions of businesses to send transactional notifications, marketing emails, newsletters, and automated communications. It operates from Amazon’s IP address ranges and is configured to generate properly signed email with valid SPF, DKIM, and DMARC authentication records.
These three protocols — SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), and DMARC (Domain-based Message Authentication, Reporting, and Conformance) — are the primary technical mechanisms by which email security systems verify that a message came from where it claims. A legitimate Amazon SES email will pass all three checks, every time, because it genuinely originated from Amazon’s infrastructure.
Attackers abuse this by obtaining legitimate SES access. The methods vary: compromised AWS credentials purchased from initial access brokers, credentials stolen through prior malware campaigns or phishing attacks on cloud users, misconfigured SES sandbox environments, or trial accounts that have been escalated beyond their intended sending limits. In each case, the result is the same — the attacker controls a sending environment with Amazon’s trust signals attached.
Why SPF, DKIM, and DMARC Cannot Block Amazon SES Phishing
Most enterprise email security gateways evaluate incoming mail through a hierarchy of signals. At the top of the trust stack is authentication: does the email’s origin match what the sending domain has declared it should be? Amazon SES email passes this check unconditionally. Below that, the gateway evaluates sender reputation: is this IP address associated with spam or malicious activity? Amazon SES IP ranges have high reputation scores maintained by AWS, built on the collective behavior of millions of legitimate senders.
This creates a structural blind spot. An email gateway that has correctly identified Amazon SES as a high-reputation sender with valid authentication will weight SES-originated email favorably — reducing the friction that might otherwise flag a suspicious message.
The downstream consequence is increased click rates. Recipients of phishing emails from SES see messages that arrive without security warnings, display correctly in mail clients, and lack the visible signals that trained users associate with phishing — suspicious sender domains, failed authentication headers, or reputation warnings injected by their email security tool.
The Broader Pattern: Trusted Infrastructure Turned Against Defenders
Amazon SES is part of a systematic attacker pattern, not an isolated abuse case. Microsoft Azure Communication Services, Twilio SendGrid, Mailchimp, and other legitimate high-reputation email infrastructure providers have all experienced systematic abuse in recent years for the same underlying reason: attackers can achieve higher delivery rates and lower detection rates by sending from trusted infrastructure than by operating their own email servers.
The economics make the approach compelling. SES pricing is approximately $0.10 per thousand emails — at that scale, attackers can send millions of phishing messages for a few hundred dollars. The cost of legitimate infrastructure that defeats email security defenses is lower than the cost of building and maintaining equivalent malicious infrastructure that doesn’t.
The pattern also means that blocking Amazon SES as a mitigation is not viable. Organizations receive enormous volumes of legitimate email from SES daily — transactional confirmations, receipts, automated notifications from the SaaS products they use. Blocking the sending infrastructure would disrupt critical business communications.
SES Abuse as a Signal of Broader AWS Compromise
One underappreciated aspect of SES abuse is what it indicates about the attacker’s overall cloud access. SES access does not exist in isolation — it is a capability within an AWS account. An attacker who has obtained valid SES credentials has, at minimum, AWS console or API access to an account configured for email sending.
That account may also have access to S3 buckets, EC2 instances, Lambda functions, or other AWS services, depending on the credentials involved and the account configuration. SES abuse detected by a security team may therefore be a visible indicator of a broader AWS account compromise that extends well beyond phishing campaigns into data storage, compute resources, and connected infrastructure.
Organizations that identify SES abuse originating from their own AWS accounts should treat it as an IAM compromise incident requiring full credential audit and access review, not merely an email policy enforcement issue.
Detection Approaches When Authentication Signals Can’t Be Trusted
Defending against SES-based phishing requires shifting detection layers. Authentication signals are effectively useless for distinguishing legitimate from malicious SES email. The relevant detection approaches are:
Content analysis and URL reputation. The body of a phishing email, regardless of where it originated, typically contains indicators — unusual URL patterns, mismatched domain names, credential harvesting page characteristics — that content-based filters can identify. Investing in content analysis engines that do not rely on sender authentication as a primary trust signal is necessary for this threat class.
Behavioral anomaly detection. Baseline what legitimate SES email looks like for your organization — which SaaS services send from it, what content patterns they use, what call-to-action patterns appear in legitimate messages. Deviations from baseline are higher-fidelity signals than authentication checks alone.
AWS account monitoring for SES abuse. Organizations using SES from their own AWS accounts should monitor for unusual sending volumes, new recipient domains, and geographic origination patterns in SES sending statistics. CloudWatch metrics and CloudTrail logs provide the data; automated alerting on anomalies provides the detection.
Report compromised SES accounts to AWS. Amazon actively investigates and suspends accounts engaged in SES abuse. Security teams who identify phishing email originating from SES can report it through AWS’s abuse reporting channels, accelerating the takedown of the sending account.
Recalibrating Email Defenses After Amazon SES Authentication Fails to Protect Against Phishing
SES phishing abuse is accelerating and is not an edge case — it is an established tactic with growing adoption because it works against defenses that organizations have invested heavily in building.
Email security programs that have been tuned to trust highly-authenticated senders need to recalibrate. The threat model has shifted: authentication is now a necessary but insufficient filter, and detection must operate further down the content and behavioral stack.
The connection between SES abuse and broader AWS credential compromise means cloud security posture management — specifically monitoring for unexpected SES activity in AWS environments — belongs in incident detection playbooks alongside the more traditional email security tooling.
