Mastering AWS SES Security: Preventing Unauthorized Cross-Account Access

Overview

Amazon Simple Email Service (SES) is a powerful tool for managing marketing, transactional, and operational email at scale. Its flexibility allows organizations to delegate sending permissions to other AWS accounts, a feature essential for multi-account strategies and third-party vendor integrations. However, this same flexibility introduces a significant security and financial risk if not governed properly.

The core problem lies in SES Sending Authorization Policies, which are resource-based policies attached directly to a verified email identity (like your company’s domain). When these policies are configured too permissively—for example, by granting access to unknown accounts or using wildcards—they create a security vulnerability. This misconfiguration effectively turns your trusted corporate domain into an open relay, allowing unauthorized entities to send emails on your behalf.

This article explores the FinOps implications of improper AWS SES cross-account access. We will cover why this matters, common scenarios that lead to risk, and the guardrails necessary to protect your organization from reputation damage and unnecessary operational costs.

Why It Matters for FinOps

From a FinOps perspective, misconfigured SES policies represent a significant source of risk and potential waste. The consequences extend far beyond simple resource consumption, impacting the entire business. An unauthorized party sending spam or phishing emails from your domain can lead to immediate and long-term financial damage.

First, there is the risk of direct financial loss through phishing campaigns that target your employees or customers, leading to invoice fraud or Business Email Compromise (BEC). Second, your domain’s reputation can be permanently damaged. If your domain is blacklisted by major email providers, legitimate business communications like invoices, password resets, and customer support replies will fail to deliver, disrupting operations and increasing support costs. Recovering a tarnished domain reputation is a slow, costly, and manual process. Finally, this type of security lapse can lead to non-compliance with frameworks like SOC 2 and PCI DSS, resulting in significant regulatory fines.

What Counts as “Idle” in This Article

In the context of AWS SES security, we define "idle" or wasteful configurations as any sending authorization policy that grants permissions beyond the absolute minimum required for a business function. These are not idle in the sense of an unused server, but rather represent latent risk and a failure of governance.

Signals of a risky or wasteful policy include:

  • Policies granting sending permissions to a wildcard principal ("Principal": {"AWS": "*"}).
  • Permissions granted to AWS account IDs that are no longer in use, such as those belonging to a former marketing agency or a decommissioned development environment.
  • Policies that lack specific condition keys to restrict access, even when the principal is a trusted AWS service.
  • Permissions that allow a delegate to send from any address on a domain (*@company.com) when only a specific address (marketing@company.com) is required.

Common Scenarios

Scenario 1

A marketing team hires a third-party agency to manage an email campaign. To enable them, an administrator adds the agency’s AWS Account ID to the SES identity policy. When the contract ends six months later, the offboarding process fails to remove this permission, leaving the agency with the permanent ability to send emails as the company.

Scenario 2

An organization uses a centralized "Shared Services" AWS account to manage SES identities. The identity policy grants sending permissions to various development, staging, and production accounts. A developer, for testing purposes, temporarily adds their personal sandbox account to the policy and forgets to remove it, creating an unmonitored and ungoverned access path.

Scenario 3

To simplify testing, a development team is granted permission to use the production domain (company.com) from their lower-security development account. A security breach or a simple bug in the development environment could lead to accidental spam being sent from the production domain, immediately damaging its reputation.

Risks and Trade-offs

The primary challenge is balancing business agility with robust security. Disabling all cross-account access is not practical, as it’s a necessary feature for many modern architectural patterns. The trade-off is between enabling teams and vendors to operate efficiently and implementing strict controls to prevent abuse.

Locking down policies too aggressively without proper communication can break legitimate workflows, causing operational delays for marketing or development teams. Conversely, a lack of governance creates an unacceptable risk of domain hijacking, phishing, and brand damage. The key is to establish a clear process for requesting, approving, and auditing these permissions, ensuring that every grant of access is known, justified, and time-bound.

Recommended Guardrails

Effective governance requires a multi-layered approach that combines clear policies with automated enforcement. Organizations should implement the following guardrails to manage SES cross-account access securely.

  • Ownership and Tagging: Every SES identity should have a clear business owner assigned via tags. All cross-account policies must be associated with a ticket or business justification.
  • Principle of Least Privilege: Always use specific AWS Account IDs instead of wildcards. If possible, use condition keys to restrict delegates to sending from specific email addresses.
  • Approval Workflows: Institute a formal review process for any change to an SES identity policy. This ensures that a security or cloud governance team vets all new cross-account permissions.
  • Budgets and Alerts: While the delegate account is typically billed for sending, you can set up alerts using AWS services to monitor for anomalous activity or policy changes, providing an early warning of potential misuse.

Provider Notes

AWS

AWS provides several native tools to manage and secure SES sending authorization. The policies themselves are a form of resource-based IAM policy and can be enhanced with granular IAM condition keys like aws:SourceArn or ses:FromAddress to enforce the principle of least privilege. For continuous monitoring, organizations should use AWS Config to create rules that automatically detect and alert on overly permissive SES identity policies, ensuring that any insecure change is flagged for immediate remediation.

Binadox Operational Playbook

Binadox Insight: An improperly secured SES identity policy turns a valuable corporate asset—your domain—into a shared, uncontrolled resource. The true cost of this misconfiguration isn’t measured in AWS service fees, but in the potential for catastrophic brand damage and the operational chaos of recovering a blacklisted domain.

Binadox Checklist:

  • Systematically audit all SES identity policies across all AWS regions and accounts.
  • Create an inventory of all external AWS Account IDs found in policies and verify their ownership and business justification.
  • Remove any policies that grant access to wildcard (*) principals or unknown accounts.
  • Implement strict Infrastructure as Code (IaC) practices for managing SES policies to ensure changes are reviewed and versioned.
  • Configure AWS Config rules or similar monitoring to continuously scan for and alert on non-compliant SES policies.
  • Establish a periodic review cycle (e.g., quarterly) to re-validate all existing cross-account permissions.

Binadox KPIs to Track:

  • Number of SES policies containing wildcard principals.
  • Count of unknown or unverified AWS Account IDs with send-as permissions.
  • Mean Time to Remediate (MTTR) for alerts related to insecure SES policies.
  • Percentage of SES identities with a clearly tagged and documented business owner.

Binadox Common Pitfalls:

  • "Set and Forget" Permissions: Failing to remove permissions for third-party vendors or old projects after they are no longer active.
  • Policy Copy-Paste: Developers copying policy examples from online tutorials without replacing placeholder account IDs or removing wildcards.
  • Breaking Production Isolation: Granting development or test accounts access to send from production-verified domains.
  • Lack of Central Visibility: Failing to aggregate policy configurations from multiple AWS accounts, leading to a fragmented and incomplete view of risk.

Conclusion

Securing AWS SES is a critical FinOps and cloud governance function. By treating SES identities as valuable resources and applying rigorous IAM principles, organizations can prevent costly security incidents and protect their brand reputation.

The next step is to move from reactive clean-up to proactive governance. Implement automated monitoring to detect risky policies as they are created and establish clear ownership and review processes. This ensures that you can continue to leverage the power of SES for business communication without exposing the organization to unnecessary financial and operational risk.