How do attackers gain access to sending infrastructure?

Attackers who want to send spam or phishing from legitimate infrastructure have several proven routes in. Each exploits a different weakness in how sending systems are secured.

Credential theft is the most common starting point. ESP accounts get compromised through phishing attacks against the account holders, password reuse (someone's LinkedIn breach password works on their Mailchimp account), or weak passwords on accounts with no MFA. Once inside an ESP account, an attacker has access to sending infrastructure, existing subscriber lists, and established domain reputation. That's extremely valuable for phishing campaigns.

API key exposure is a specific version of the same problem. Marketing teams often hardcode API keys into repositories, paste them into internal Slack messages, or leave them in config files that end up public. Exposed API keys allow sending without needing full account access. They're also harder to notice because the account isn't technically "logged in."

Direct server compromise is less common but higher impact. If an attacker gains access to the mail server itself (through SSH brute-force, unpatched vulnerabilities, or stolen admin credentials), they can configure new sending domains, modify DKIM keys, or route traffic through the compromised system. This typically affects organizations running their own mail servers rather than cloud ESP customers.

Subdomain takeover is a subtler attack. If a company sets up a subdomain for a third-party service (mail.example.com pointing to an ESP that the company later stops using), and doesn't remove the DNS record, an attacker can claim that subdomain on the ESP and send email that passes subdomain-based authentication checks.

For email senders, the practical defenses: enable MFA on your ESP account, rotate API keys regularly and don't hardcode them in code, monitor your sending domains with DMARC reports to detect unauthorized use, and audit your DNS for abandoned subdomain records.