What are “attack surfaces” in email?

An attack surface is anywhere an attacker can poke at your email setup to break in, impersonate you, or get malware in front of your users. The more pieces you run (DNS, mail servers, sending platforms, inboxes, humans), the bigger the surface. Most breaches do not start with some clever zero-day. They start with a boring surface someone forgot to lock down.

Here is how I break it down when auditing a client.

DNS records. Your SPF, DKIM, DMARC, and MX records live in DNS. If an attacker compromises your registrar account or your DNS host, they can rewrite SPF to authorize their own servers, swap your MX to intercept inbound mail, or publish a DKIM key they control. Lock the registrar with strong MFA, turn on registrar lock, and audit who has access. This is the foundation under everything else, which is why DNS sits at the center of how domain owners protect their reputation from spoofing.

SMTP infrastructure. Your sending servers, relays, and inbound MX hosts. Open relays are mostly a 2005 problem, but misconfigured submission ports, weak SASL credentials, and forgotten test mailboxes still get popped. RFC 5321 is the SMTP spec if you want to know exactly what surface you are exposing. Patch the MTA, require TLS on submission, and log everything that authenticates.

Sending platform accounts. ESP logins, API keys, SMTP credentials at Postmark, SendGrid, Mailgun, Brevo, whoever you use. A stolen API key sends from your domain with full SPF and DKIM alignment, which means DMARC passes and the abuse looks like you. Rotate keys, scope them to the smallest permission set, and alert on volume spikes. We have cleaned up after multiple clients whose interns committed a SendGrid key to a public GitHub repo.

Sending domain configuration. Subdomains you forgot about (mail.oldproduct.example.com still has a permissive SPF), parked domains with no DMARC, third-party tools you authorized in SPF five years ago and never revoked. Run a quarterly audit of every include: in your SPF record. If you cannot name what it does, remove it. This overlaps heavily with the broader question of whether SPF or DKIM alone can stop spoofing, and the short answer is no, which is why DMARC matters.

Inbound content processing. The path a message takes from your MX into the inbox. Attachment scanners, link rewriters, preview generators, anything that parses HTML or executes JavaScript. Vulnerabilities here have been used to land remote code execution from a simple preview. Keep the gateway patched and turn on sandboxing for attachments.

Credentials and the humans holding them. Phishing is still the number one way attackers get in. Credential stuffing using leaked passwords from unrelated breaches is number two. Enforce MFA on every mailbox, prefer hardware keys or app-based codes over SMS, and run phishing simulations against your own team. The M3AAWG sender best common practices cover the hygiene side in detail.

The inbox itself. Mail clients have bugs. Outlook, Apple Mail, Thunderbird, mobile clients, webmail. Auto-loading remote images leaks IP addresses and read receipts. Auto-executing calendar invites has been a working attack. Patch clients, turn off remote content by default for unknown senders, and disable macros in Office attachments.

The practical move is to draw your own surface map. List every domain you send from, every ESP account, every DNS host, every person with admin access, every device that holds a credential. Most teams discover three or four surfaces they had completely forgotten about. That is where you start.