Email infrastructure security encompasses the protection of both the sending domain (against spoofing, phishing, and brand impersonation) and the sending infrastructure itself (against unauthorized access, abuse, and credential theft). For commercial email programmes, security failures in either area carry significant consequences: domain spoofing attacks damage customer trust and brand reputation; compromised sending credentials can result in spam campaigns sent from legitimate infrastructure, causing immediate deliverability damage and potential blacklisting. This guide documents the security practices that protect commercial email infrastructure across both threat vectors.
Authentication as the Security Foundation
Email authentication (SPF, DKIM, DMARC) is simultaneously a deliverability tool and a security tool — they address the same underlying problem from different angles. From a deliverability perspective, authentication proves that a message was sent by an authorised source, improving inbox placement for legitimate email. From a security perspective, authentication makes it harder for attackers to successfully impersonate the domain in phishing and spoofing attacks.
DMARC at p=reject is the most impactful email security control available to domain owners. A domain with DMARC at p=reject instructs receiving servers to reject (not deliver to spam — reject outright) any email claiming to be from that domain that fails authentication. This means phishing emails that attempt to use the protected domain in the From: address are rejected before reaching the intended victims. The proportion of phishing attacks against an organisation that can be prevented by DMARC p=reject varies by the organisation's domain visibility and attack targeting — high-profile domains (major financial institutions, large enterprises) see more attempted domain spoofing and benefit more from the protection. All organisations benefit from p=reject to some degree.
DKIM key security: DKIM private keys are cryptographic secrets — if compromised, an attacker can generate valid DKIM signatures from any server, bypassing DMARC authentication for fraudulent email. DKIM private keys must be: stored with filesystem permissions readable only by the MTA process (chmod 600, owned by the MTA service account), not stored in shared configuration management systems without encryption, rotated annually as a standard security practice, and rotated immediately if any suspected compromise of the server storing the key occurs.
Domain Spoofing Protection
Domain spoofing — fraudulent emails that claim to be from a legitimate domain — is the most common email-based attack targeting commercial organisations. DMARC p=reject is the primary protection, but complete spoofing protection requires a multi-layer approach:
DMARC enforcement across all owned domains: Not just the primary sending domain, but every domain the organisation owns — including parked domains that are not actively used for email. Parked domains (brandname.io, brand-name.com, brand.net) are frequently used in phishing attacks because the parent brand's DMARC protection does not cover different domain names. Publish DMARC p=reject on all owned domains, including those that do not send email.
DMARC on non-email subdomains: Subdomains can be used in phishing attacks even if the parent domain has DMARC enforcement. The DMARC sp= (subdomain policy) parameter extends enforcement to all subdomains. Set sp=reject alongside p=reject to cover the full domain namespace: v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@brand.com
Lookalike domain monitoring: Attackers frequently register lookalike domains (brand-secure.com, brandbank.net, brand-support.co) for phishing campaigns. Domain monitoring services (BrandShield, PhishLabs, Recorded Future) monitor the internet for newly registered domains that resemble the protected brand's domain and alert on potential typosquatting or lookalike registrations before they are used in campaigns. This proactive monitoring allows the brand's security team to take down lookalike domains before significant phishing activity occurs.
Email Infrastructure Access Control
Access control for email infrastructure (PowerMTA or Postfix servers, DNS management, ESP admin accounts) must follow the principle of least privilege — each user has access only to the components needed for their specific role, not blanket administrative access to all systems.
PowerMTA/Postfix server access: SSH access to email infrastructure servers should be limited to named individuals with documented business need. Use SSH key authentication rather than password authentication — disable password-based SSH login. Maintain an access log and review it monthly for any unexpected access. The email infrastructure team members who manage the servers have SSH access; the email marketing team who use the infrastructure do not need server-level access.
DNS access control: DNS records are the security foundation of email authentication — an attacker who can modify DNS records can remove DMARC protection, replace DKIM keys, and add themselves as authorised SPF senders. DNS provider access must be protected with MFA and restricted to the specific individuals who manage DNS changes (typically IT/platform team, not email marketing team).
ESP admin account access: ESP accounts (Mailchimp, Klaviyo, Postmark, Mailgun) have admin access levels that include: API key management, sending domain management, and potentially access to the full subscriber list. Admin-level ESP access should be restricted to 2-3 named individuals. Use role-based access controls where the ESP supports them — giving campaign managers the ability to create and send campaigns without giving them access to API key management or billing.
API Key and Credential Management
ESP API keys are the credentials that allow applications to send email on behalf of the account. A compromised API key allows the attacker to send unlimited email from the account's sending infrastructure — generating deliverability damage, incurring usage costs, and potentially exposing subscriber data. API key security practices:
Minimum necessary permissions: Create API keys with the minimum permissions required for the specific use case. An API key used only for sending transactional email should have "send messages" permission only — not the ability to access subscriber lists, modify account settings, or view billing data. Most major ESPs (Mailgun, SendGrid, Postmark) support scoped API keys with granular permission sets.
Never commit API keys to code repositories: API keys embedded in application code that is committed to GitHub, GitLab, or any other version-controlled repository are exposed to anyone who can access the repository — and are often scraped by automated bots that monitor public repositories for credential patterns. Use environment variables or secrets management services (HashiCorp Vault, AWS Secrets Manager, GitHub Secrets) to store credentials, never hardcode them.
Regular API key rotation: Rotate ESP API keys quarterly or after any team member who had access to the key leaves the organisation. Most ESPs support creating a new key before deactivating the old one — ensuring zero-downtime key rotation.
IP restriction on API keys: Many ESPs support restricting API key usage to specific IP addresses. Configure API keys to only accept requests from the application servers that legitimately use them — any attempt to use the key from an unauthorised IP is rejected. This limits the damage from credential theft: a stolen API key without the associated authorised IP address cannot be used.
Sending Account Security
The ESP accounts that manage sending, the DNS provider accounts that manage authentication records, and the email addresses used for bounce processing and DMARC reporting are all targets for credential theft attacks. Account security requirements:
Multi-factor authentication (MFA) on all accounts: Enable MFA on every ESP account, DNS provider account, domain registrar account, and any other account that manages email infrastructure. Use authenticator app MFA (TOTP) rather than SMS MFA where possible — SMS MFA is vulnerable to SIM swapping attacks. Hardware security keys (YubiKey) provide the strongest MFA protection for highest-risk accounts (DNS providers, DMARC monitoring tools).
Unique strong passwords: Every account should use a unique, randomly generated password stored in a password manager. Reusing passwords across accounts means a breach of one service exposes all accounts that share the password. Password manager tools (1Password, Bitwarden, LastPass) generate and store unique passwords for all accounts without requiring team members to memorise them.
Account breach monitoring: Services like HaveIBeenPwned (haveibeenpwned.com) allow monitoring email addresses for appearance in known data breaches. Set up notifications for all email addresses associated with infrastructure accounts — if an email address used for an ESP account appears in a breach, the password for that account must be changed immediately.
Monitoring for Email Infrastructure Abuse
Email infrastructure abuse — sending from compromised credentials or hijacked server access — is difficult to detect without active monitoring because the outbound email volume metrics that reveal abuse (unexpected volume spikes, unexpected destination patterns, unexpected content) require real-time monitoring to catch before significant damage occurs.
ESP usage monitoring: Configure alerts in the ESP account for unusual API usage patterns — specifically, volume spikes above normal sending patterns and sends initiated from unexpected IP addresses. Most commercial ESPs (SendGrid, Mailgun, Postmark) provide webhook notifications or API endpoints for send event monitoring that can be integrated into security monitoring systems.
PowerMTA/Postfix log monitoring: Monitor the MTA's accounting log and mail log for unusual injection sources, unexpected bounce rate spikes (indicating a new list segment was injected without verification), and unexpected destination domain patterns (sending to domains outside the programme's normal recipient geography suggests compromised injection credentials).
DMARC monitoring for spoofing attempts: DMARC aggregate reports show all sources that claim to be from the monitored domain — including unauthorized senders who are spoofing the domain in phishing attempts. A spike in unauthenticated sources claiming to send from the domain in DMARC aggregate reports indicates an active spoofing campaign. This is the early warning system for phishing attacks against the brand — often detectable through DMARC reports before the phishing attack is widely reported by victims.
Security Incident Response for Email
When a security incident involving email infrastructure is suspected (unusual sending volume, unexpected bounce patterns, blacklist listing from unknown sending activity, customer reports of phishing email from the brand domain), the response protocol:
▶ Email Security Incident Response
Third-Party ESP and Tool Security
The security of email infrastructure is only as strong as the weakest vendor in the stack. Every third-party service that has access to sending credentials, subscriber data, or DNS management is a potential attack vector. The vendor security assessment should consider: (1) Does the vendor enforce MFA on admin accounts? (2) Does the vendor support IP-restricted API keys? (3) What data does the vendor store and how is it encrypted? (4) Has the vendor experienced relevant security breaches, and how did they respond? (5) Does the vendor's terms of service and security practices meet the applicable data protection regulations (GDPR, CCPA)?
For HIPAA-regulated organisations, the vendor security requirements extend to Business Associate Agreements that specify the vendor's security obligations for PHI protection. For financial services organisations, vendor security requirements may be specified in regulatory frameworks (FFIEC guidance, FINRA rules) that define minimum security standards for third-party service providers handling sensitive financial data.
Email security is ultimately about protecting two things: the trust of the people who receive email from the domain (by preventing phishing attacks that impersonate the brand) and the operational integrity of the sending programme (by preventing unauthorized use of the sending infrastructure). Both protections require the same foundational investments: authentication enforcement, access control, MFA everywhere, credential management discipline, and active monitoring. These investments are not optional overhead -- they are the security baseline that makes email a safe and reliable channel for both the programme and the people it communicates with.
Email security for commercial senders is not a specialised domain separate from deliverability operations -- it is the same discipline viewed through a security lens rather than a performance lens. The authentication infrastructure that maximises inbox placement (DMARC p=reject, DKIM, SPF) simultaneously maximises domain spoofing protection. The access controls that prevent unauthorised use of sending infrastructure simultaneously protect deliverability from reputation damage caused by abuse. Build the security practices documented in this guide not as a security project separate from deliverability operations, but as an integrated part of the deliverability programme that produces better outcomes in both dimensions simultaneously.