Authentication, Spoofing, Phishing, and Business Email Compromise
Email remains the single most exploited attack vector in cybersecurity. Not web applications. Not exposed APIs. Not misconfigured cloud storage. Email. The FBI's Internet Crime Complaint Center reported that business email compromise alone cost organizations over $2.9 billion in 2023, and the number has only climbed since. When you add credential phishing, malware delivery, and account takeover attacks that start with a compromised inbox, email is responsible for the initial access step in the majority of breaches we investigate.
Most organizations believe they have email security covered because they have SPF, DKIM, and DMARC records published in DNS. Those three protocols are necessary, but they are not sufficient. Our email security assessments consistently reveal gaps between what organizations think their email authentication does and what it actually enforces. A DMARC record set to p=none does nothing to stop spoofed emails from reaching inboxes. An SPF record with too many includes silently fails. A DKIM key that has not been rotated in three years is a liability, not a control.
This article covers what we test in email security assessments, why the standard authentication stack leaves gaps, how business email compromise works at a technical level, and what a comprehensive email security program actually looks like. If you are interested in the broader social engineering picture, our guide on social engineering in penetration testing covers phishing, vishing, and pretexting methodologies in depth.
Why email is still the number one attack vector
Email is uniquely dangerous because it combines universal reach with inherent trust. Every employee has an inbox. Every inbox accepts messages from the outside world. And unlike a web application that requires an attacker to find it, enumerate its endpoints, and craft specific exploits, email delivers the attack directly to the target. The attacker does not need to bypass your perimeter. Your mail server invites the payload inside.
The economics favor the attacker. A phishing campaign targeting 500 employees costs virtually nothing to execute. If two percent of recipients click, that is ten compromised credentials. One of those credentials might belong to a finance team member, a system administrator, or someone with access to your CI/CD pipeline. The return on investment for email-based attacks is orders of magnitude higher than scanning random IP ranges for vulnerabilities.
The numbers tell the story clearly. Verizon's Data Breach Investigations Report consistently finds that phishing and pretexting account for over 40 percent of social engineering breaches, and email is the delivery mechanism in the vast majority of those. Business email compromise losses exceeded $2.9 billion in the most recent FBI reporting period, a figure that only counts reported incidents. The actual number is substantially higher because many BEC losses go unreported or are classified under different categories.
The email problem is not getting better. AI-generated phishing emails are grammatically perfect, contextually relevant, and increasingly difficult to distinguish from legitimate communications. The days when typos and awkward phrasing were reliable indicators of phishing are over. Attackers now use large language models to craft emails that match your organization's communication style, reference real projects, and include plausible details harvested from LinkedIn and corporate websites.
SPF, DKIM, and DMARC: what they do and what they do not
Before examining what goes wrong, it is important to understand what each protocol is designed to do and where its protection ends. These three protocols form the foundation of email authentication, but each one addresses a specific and limited problem.
SPF (Sender Policy Framework)
SPF allows a domain owner to publish a DNS TXT record listing the IP addresses and mail servers authorized to send email on behalf of that domain. When a receiving mail server gets a message, it checks whether the sending server's IP address matches the SPF record for the domain in the MAIL FROM (envelope sender) field.
What SPF does: It validates that the sending server is authorized by the envelope sender's domain. If your SPF record says only Google Workspace and SendGrid are allowed to send as your domain, a message from an unauthorized server will fail SPF.
What SPF does not do: SPF does not validate the From header that users actually see in their email client. An attacker can send an email with a MAIL FROM of attacker-domain.com (which passes SPF for their domain) while setting the display From header to [email protected]. The recipient sees the CEO's name and email address. SPF passes because the envelope sender is legitimate for the attacker's domain. This is the fundamental gap that most people do not understand.
DKIM (DomainKeys Identified Mail)
DKIM adds a cryptographic signature to outgoing emails. The sending server signs a hash of specified email headers and the message body using a private key. The corresponding public key is published in DNS. Receiving servers verify the signature to confirm that the message was not modified in transit and that it originated from a server holding the private key.
What DKIM does: It proves message integrity and authenticates the signing domain. If the signature validates, you know the message was not tampered with after signing and that the signing domain authorized it.
What DKIM does not do: DKIM does not tell you anything about the relationship between the signing domain and the From header domain. An attacker can sign a phishing email with DKIM using their own domain. The signature will be perfectly valid. DKIM alone does not prevent spoofing because it does not enforce alignment between the signing domain and the visible sender.
DMARC (Domain-based Message Authentication, Reporting, and Conformance)
DMARC ties SPF and DKIM together by adding an alignment requirement and a policy directive. It checks whether the domain in the From header aligns with either the SPF-authenticated domain or the DKIM-signing domain. If neither aligns, DMARC applies the policy specified by the domain owner: none (monitor only), quarantine (send to spam), or reject (block delivery).
What DMARC does: When properly configured with p=reject, DMARC prevents attackers from sending emails that appear to come from your domain. It closes the gap that SPF and DKIM leave open individually.
What DMARC does not do: DMARC only protects your exact domain. It does not prevent lookalike domains (payrol1-yourcompany.com), display name spoofing ("CEO Name" <[email protected]>), or compromised accounts sending from your legitimate infrastructure. It also does nothing if the policy is set to p=none, which is where we find the majority of organizations stuck.
The alignment problem in practice: We regularly find organizations with SPF and DKIM properly configured but DMARC set to p=none with no plan to enforce. They have been collecting DMARC reports for months or years but never analyzed them or moved to enforcement. In these cases, the organization has done 80 percent of the work but gets zero percent of the protection. Attackers can still spoof the domain freely because p=none is purely observational.
What we test in email security assessments
Our email security assessments go well beyond checking DNS records. We actively test whether email authentication controls work as intended by attempting the same techniques that real attackers use. Here is what a comprehensive assessment covers.
SPF alignment and enforcement
We analyze the SPF record for correctness, check for common misconfigurations like exceeding the 10-DNS-lookup limit, and test whether the receiving infrastructure actually enforces SPF failures. Many organizations have valid SPF records but their mail gateway is configured to soft-fail or ignore SPF results entirely. We send test emails from unauthorized servers to verify whether SPF failures result in message rejection, quarantine, or delivery to the inbox.
DKIM signing and key strength
We verify that outgoing mail is DKIM-signed, check the key length (1024-bit keys are still common and considered weak; 2048-bit is the minimum recommendation), and look for stale selectors that may indicate keys have not been rotated. We also check whether DKIM signatures survive forwarding and mailing list processing, which is important for organizations that rely on distribution lists.
DMARC policy enforcement
We test the DMARC policy by sending spoofed emails with your domain in the From header from an unauthorized server. This reveals whether DMARC is set to reject, quarantine, or none, and whether the receiving infrastructure honors the published policy. We also check the sp= tag for subdomain policy, the pct= tag for percentage enforcement, and the rua/ruf tags for reporting configuration.
Subdomain spoofing
Even organizations with strong DMARC policies on their primary domain often forget about subdomains. If your DMARC record does not include sp=reject, attackers can spoof emails from hr.yourcompany.com, support.yourcompany.com, or any subdomain that does not have its own DMARC record. We enumerate subdomains and test each one for spoofability.
Lookalike domain analysis
We identify domains that are visually similar to your primary domain using character substitution (l vs 1, rn vs m), homoglyph attacks (using Unicode characters that look identical to ASCII), and common typosquatting patterns. We check whether these domains are registered, whether they have MX records, and whether your organization is monitoring for them. A domain like yourc0mpany.com or yourcompany-portal.com can be registered by anyone and used to send perfectly authenticated phishing emails.
Mail server TLS configuration
We test your mail server's TLS configuration, including supported protocol versions, cipher suites, and certificate validity. We also check for MTA-STS (Mail Transfer Agent Strict Transport Security) and DANE (DNS-based Authentication of Named Entities), which prevent TLS downgrade attacks during mail delivery. Without MTA-STS or DANE, an attacker in a man-in-the-middle position can force email delivery over unencrypted connections and read messages in transit.
Header injection and relay testing
We test for email header injection vulnerabilities in web applications that send email (contact forms, registration pages, password reset flows). If an application concatenates user input into email headers without sanitization, attackers can inject additional recipients, modify the From address, or add arbitrary headers. We also test whether your mail server allows open relay, which would let anyone send email through your infrastructure.
The phishing attack flow
Understanding the sequence of a real phishing attack helps contextualize why each test matters. Here is the typical progression we simulate.
Recon: The attacker researches your organization, identifies targets, learns your email platform, and studies your communication patterns. Spoof Setup: They register a lookalike domain, configure SPF/DKIM for it, and set up phishing infrastructure. Phishing Email: A crafted email that passes authentication checks arrives in the target's inbox. Credential Harvest: The victim enters credentials on a cloned login page. Account Access: The attacker logs into the real account, often setting up forwarding rules and deleting traces before the victim notices.
Phishing simulations versus real phishing
Most organizations run phishing simulations through platforms like KnowBe4, Proofpoint, or Cofense. These simulations are useful for measuring awareness baselines and training employees, but they systematically undercount real risk for several reasons.
Simulations are allowlisted. Your email security gateway knows the simulation platform's sending infrastructure. The simulation emails bypass the same filters that would catch or flag real phishing attempts. This means the click rate you measure includes people who would never have seen the email in a real attack because the gateway would have caught it. Paradoxically, it also means employees never see whether their gateway actually works against real threats.
Templates are generic. Simulation platforms use template libraries designed for broad applicability. They do not include real reconnaissance about your organization, reference actual projects your team is working on, or mimic the specific communication style of your executives. Real attackers invest time in making their emails indistinguishable from legitimate internal communications.
Simulations do not test the full chain. A simulation measures whether someone clicks a link or submits credentials on a fake page. It does not test what happens next: whether your SOC detects the credential compromise, whether your identity provider flags an anomalous login, whether forwarding rules would be caught, or whether lateral movement from the compromised account would be detected.
Real phishing uses evasion. Threat actors use techniques specifically designed to bypass email security gateways: URL rewriting with redirects through trusted services, delayed payload delivery where the link is benign at scan time but malicious when clicked, HTML smuggling, QR codes embedded in images, and attachment-based payloads that execute only after user interaction. Simulations typically do not test any of these evasion techniques.
Our recommendation: Continue running phishing simulations for awareness training purposes, but supplement them with an annual phishing penetration test that uses real-world techniques, bypasses your security controls, and tests your full detection and response chain. The two assessments measure fundamentally different things. Simulations measure employee awareness. Phishing pentests measure your actual resilience against a motivated attacker.
Business email compromise: the attack that does not use malware
Business email compromise is the most financially damaging form of email-based attack, and it is the one that technical controls are least equipped to stop. BEC attacks do not contain malicious links, infected attachments, or exploit code. They contain carefully crafted text that convinces a human to take a specific action, usually transferring money or changing payment details. Because there is nothing technically malicious in the email, traditional security controls like sandboxes, URL analysis, and attachment scanning are completely ineffective.
CEO fraud
The attacker impersonates the CEO or another senior executive and sends an urgent request to a finance team member. The email might read: "I need a wire transfer processed before end of day. This is for the acquisition we discussed in the board meeting. I will send the details. Please keep this confidential until the announcement." The email creates urgency, invokes authority, and pre-empts verification by requesting confidentiality. If the attacker has done their homework (and they have, using LinkedIn, press releases, and SEC filings), the request feels entirely plausible.
Vendor impersonation
The attacker studies your vendor relationships through public procurement records, partnership announcements, or compromised email threads. They then send an email appearing to come from a known vendor, informing you that banking details have changed. The next legitimate payment goes to the attacker's account. These attacks often arrive during real invoice cycles, referencing actual purchase orders and using the vendor's exact email formatting.
Account takeover and forwarding rules
The most sophisticated BEC variant involves actually compromising a legitimate email account, typically through credential phishing or password spraying. Once inside, the attacker does not immediately act. They set up mailbox rules to forward copies of all incoming email to an external address. They monitor communications for weeks, learning the organization's processes, payment schedules, and approval chains. When a large transaction is pending, they insert themselves into the email thread with modified payment instructions. Because the email comes from the real account of a real person in an ongoing conversation, the chance of detection before the money moves is extremely low.
Lawyer or attorney impersonation
Attackers impersonate outside counsel or attorneys during acquisitions, settlements, or legal proceedings. They send urgent requests for wire transfers related to "closing costs" or "settlement payments" that require immediate processing. The legal context adds an additional layer of authority and confidentiality that discourages verification.
BEC defense requires process controls, not just technology. No email filter can reliably detect a plain-text email requesting a wire transfer. Defense against BEC requires out-of-band verification procedures (calling a known number, not the one in the email), dual-authorization for payments above a threshold, and awareness training specifically focused on BEC scenarios. Our social engineering testing includes BEC simulations that test whether your financial controls actually hold up against realistic impersonation.
Common email misconfigurations we find
Across hundreds of email security assessments, certain misconfigurations appear with remarkable consistency. These are the issues we find in the majority of engagements.
DMARC stuck at p=none
This is the single most common finding. Organizations publish a DMARC record during initial setup, set it to p=none to avoid disrupting legitimate email, and then never move to enforcement. Some have been at p=none for years. During that entire period, anyone can spoof the domain with no consequence. Moving from p=none to p=quarantine and then to p=reject requires analyzing DMARC aggregate reports to identify all legitimate sending sources, but many organizations never allocate the time for this analysis.
Overly permissive SPF records
We frequently find SPF records that include broad IP ranges, legacy third-party services that are no longer used, or the +all mechanism that authorizes literally every IP address on the internet. We also find records that exceed the 10-DNS-lookup limit, which causes SPF to return a PermError that many receiving servers treat as a pass or ignore entirely. An SPF record should be as restrictive as possible, including only the specific services that currently send email for the domain.
Missing DKIM for subdomains and third-party senders
Organizations configure DKIM for their primary mail platform but forget about marketing platforms, transactional email services, CRM systems, and support ticketing tools that also send email using their domain. Each sending service needs its own DKIM selector and key. Without it, those messages fail DKIM checks, and if DMARC is enforced, they get rejected, which creates operational pressure to weaken the DMARC policy.
No MTA-STS or DANE
MTA-STS and DANE prevent TLS downgrade attacks on email in transit. Without them, an attacker in a network position between two mail servers can strip TLS and intercept email in plaintext. Despite being relatively simple to implement (MTA-STS requires a DNS record and a small policy file hosted over HTTPS), adoption remains extremely low. We find it missing in over 90 percent of assessments.
Legacy TLS versions on mail servers
Mail servers running TLS 1.0 or 1.1, protocols with known cryptographic weaknesses, remain surprisingly common. Some organizations disable TLS entirely on their mail servers to avoid compatibility issues with older sending servers. This leaves all email delivered to that server unencrypted and readable by anyone with network access.
No inbound email filtering for internal-to-internal spoofing
Many email gateways only apply anti-spoofing rules to emails arriving from external sources. An attacker who has already compromised one internal account or who can inject email into the internal mail flow can spoof any internal sender without triggering DMARC checks. This is particularly dangerous in environments where lateral phishing from compromised accounts is a likely attack scenario.
Building an email security program
A complete email security program layers technical controls, process controls, and human controls. No single layer is sufficient on its own. The following table compares the controls, what they protect against, and their limitations.
| Control | Protects Against | Limitations |
|---|---|---|
| SPF (strict) | Unauthorized servers sending as your domain | Does not validate the visible From header; breaks with forwarding |
| DKIM (2048-bit) | Message tampering; authenticates the signing domain | Does not prevent spoofing if attacker signs with their own domain |
| DMARC (p=reject) | Domain spoofing on the exact domain | Does not cover lookalike domains or display-name spoofing |
| MTA-STS / DANE | TLS downgrade and man-in-the-middle during delivery | Requires HTTPS hosting; low adoption means limited cross-org benefit |
| Email gateway filtering | Malicious URLs, attachments, known phishing patterns | Cannot detect zero-day phishing or plain-text BEC |
| Lookalike domain monitoring | Typosquatting and homoglyph-based spoofing | Reactive; domains must be detected before they are used in attacks |
| Phishing-resistant MFA | Credential harvesting and account takeover | Does not prevent initial phishing; only limits post-compromise impact |
| Out-of-band payment verification | BEC wire fraud and vendor impersonation | Requires consistent process adherence; fails if employees skip the step |
| Security awareness training | Human susceptibility to social engineering | Effectiveness degrades over time; does not scale to AI-generated phishing |
The key insight from this table is that no single control addresses more than one or two attack types. DMARC at p=reject stops domain spoofing but does nothing about BEC from a compromised account. An email gateway catches known malicious payloads but misses novel evasion techniques. Training helps employees spot phishing but cannot keep pace with AI-generated content. Effective email security requires all of these controls working in parallel, with regular testing to verify that each one is functioning as expected.
If you are evaluating your overall security posture beyond email, our guide on the OWASP Top 10 in real-world penetration tests covers the most common web application vulnerabilities we find alongside email security gaps.
Email security is not a configuration-and-forget exercise. Authentication protocols need ongoing monitoring and enforcement. Phishing techniques evolve faster than training programs. Business email compromise exploits human trust in ways that no filter can catch. The organizations that maintain strong email security are the ones that test regularly, analyze what they find, and treat email as the high-risk attack surface that it is rather than a solved problem.
If you have not had your email authentication stack tested recently, or if your DMARC policy is still set to p=none, those are the two most impactful steps you can take immediately. Everything else builds on that foundation.
Assess Your Email Security Posture
Our email security assessments test SPF, DKIM, DMARC enforcement, phishing resilience, and BEC susceptibility using real-world attack techniques. Find out what gets past your filters before an attacker does.
