Why Email Scams Scale Because of Broken Identity Infra

After every BEC incident, the post-mortem usually looks the same. The employee failed to verify the invoice. The finance team did not follow protocol. Security awareness training was insufficient. And then the organization schedules more training.

This is the convenient answer. It is also the wrong one.

Email scams scale because the infrastructure that should verify sender identity was never designed to do it. The From address on an email is a free-text field. Anyone can put any address there. SPF, DKIM, and DMARC are patchwork additions that help, but they do not close the structural gap. Until organizations treat this as an infrastructure problem, scams will keep scaling regardless of how much training employees complete.

The "Gullible Users" Explanation Is Convenient But Wrong

The training-first narrative is appealing for a simple reason: it puts the responsibility on individuals, not systems. A company can run a phishing simulation and feel like it has done something. Telling employees to "always verify unusual requests" sounds actionable.

The problem is that even highly trained, careful users cannot reliably detect an email impersonation attack when the email infrastructure itself does not tell them whether the sender is legitimate. A well-crafted invoice email that arrives with a spoofed address from a trusted vendor looks identical to a legitimate one. There is no red flag for a human to notice. The infrastructure should surface that signal, and it does not.

Organizations that have run phishing simulation programs for years still get compromised through business email continuity scams. The training did not fail. The training was never the right tool for this problem.

Email Was Never Built to Verify Sender Identity

Email predates the modern internet by decades. The original design assumed a trusted network where senders were known and accountable. There was no concept of an external attacker forging someone else's address.

That assumption is still embedded in the protocol. The From header, which is what recipients see and what most people think of as the sender address, is not authenticated by default. It is a text field that any mail transfer agent or mail client can set to any value. SMTP, the protocol that moves email between servers, does not verify that the sending server has any relationship to the address it claims to be sending from.

This is not a bug in a specific email system. It is a design gap in the protocol itself. The From field tells the recipient who the message is from, but it provides no cryptographic or administrative mechanism to prove that claim is true.

Modern email authentication protocols were added decades later, and they do not retroactively fix the design gap. They create workarounds that require configuration by the receiving and sending domains. When those configurations are missing or misconfigured, the gap remains wide open.

What SPF, DKIM, and DMARC Actually Do (And What They Miss)

Understanding what each protocol does and does not protect requires keeping track of two different sender addresses in every email.

The Envelope-From (RFC 5321 Mail From) is the address the mail transfer protocol uses during the SMTP conversation. It is mostly invisible to end users. SPF validates this address.

The Header-From (RFC 5322 From) is what the recipient sees in their email client. It is what users recognize as the sender. DMARC validates this address.

DKIM adds a cryptographic signature to a message. The signature covers specific headers and the message body. The `d=` tag in a DKIM signature identifies the signing domain, which does not have to match the Header-From domain.

This three-way gap is where most impersonation attacks succeed.

SPF validates the Envelope-From domain. If the Envelope-From is `relay.example.net` and the Header-From is `ceo@yourdomain.com`, SPF checks whether `relay.example.net` is authorized to send mail. It does not check whether `yourdomain.com` authorized the message. If `relay.example.net` is a legitimate email processor that your organization uses, SPF will pass. The impersonator who also uses that relay will also pass SPF.

DKIM validates the signing domain. If the DKIM signature carries a `d=` tag of `mailer.example.net` while the Header-From is `billing@yourdomain.com`, DKIM verifies that `mailer.example.net` signed the message. It does not verify that `yourdomain.com` authorized the message.

DMARC alignment is the bridge between these domains. It asks: does the authenticated sender domain match the From domain the recipient sees? If SPF passes for `relay.example.net` but the From says `yourdomain.com`, there is no alignment and DMARC fails. If DKIM is signed by `mailer.example.net` while the From says `yourdomain.com`, there is no alignment and DMARC fails.

This design is sound when organizations control all the systems that send as their domain. It breaks down when organizations have authorized third parties to send on their behalf and those third parties do not implement DKIM properly or use shared infrastructure that makes alignment impossible.

Why the Attack Surface Is Larger Than Most Organizations Realize

Most organizations do not know how many systems are sending mail as their domain. The first DMARC aggregate report typically surfaces senders the security team did not know existed: an internal HR system that auto-enrolls employees, a legacy ERP that sends payslips through a shared relay, a marketing platform that sends on behalf of the organization without DKIM, a cloud service that authenticates to Microsoft 365 on behalf of the organization but uses its own signing infrastructure.

None of these are attacks. They are normal operations. But they create authorized infrastructure that breaks DMARC alignment, which means the organization's DMARC policy cannot be enforced to p=reject without first fixing those senders. And each one of those invisible senders is a potential vector for an attacker who wants to impersonate the organization.

This is the structural link between infrastructure visibility and scam volume. Organizations that do not know what infrastructure is authorized to send as their domain cannot distinguish between a legitimate email from their vendor portal and an impersonator using the same vendor portal as a launchpad.

DMARCFlow aggregate reports give organizations a full view of every sender claiming their domain, including the ones internal teams forgot about. Without that visibility, enforcing p=reject is a guess. With it, closing the gaps scammers exploit becomes a systematic process rather than a firefighting exercise.

What Actually Reduces Scam Volume

Improving infrastructure is more effective than expanding training. Here is what works, ordered by impact.

Enforce DMARC p=reject. This stops external domain spoofing at the receiving server. When your domain has a DMARC record with p=reject, receiving mail servers are instructed to reject messages that fail alignment. This does not require action from recipients. It shifts the control point to the receiving infrastructure, which is where it belongs.

Use aggregate reports to discover all legitimate senders before enforcement. This is the prerequisite step most organizations skip. Running in p=none mode while collecting aggregate reports tells you every mail server that is currently sending as your domain, including the ones your own teams forgot about. Moving to p=reject without this step will break legitimate mail and create pressure to abandon DMARC entirely.

Authorize third-party senders with proper DKIM or subdomain delegation. If a vendor needs to send as your domain, they should sign with a DKIM key you control, or you should delegate a subdomain to them (for example, `marketing.yourdomain.com` rather than `yourdomain.com`) so they can implement their own authentication without breaking alignment for your primary domain.

Monitor for lookalike domains. Scammers routinely register domains that look like your real domain: `yourdoma1n.com`, `your-domain.com`, `yourdomain.net`. These domains can pass SPF if they have their own SPF record, DKIM if they sign their own mail, and may be used in From addresses that look like your domain in some mail clients. Lookalike domain monitoring is a separate control from DMARC.

Combine authentication enforcement with user awareness. Infrastructure controls and user training address different threat vectors. Authentication stops external impersonation. User awareness helps when attackers use convincing social engineering on top of a legitimate-seeming email. Neither is sufficient alone.

The Infrastructure Fix Is Permanent, the Training Fix Is Not

Security awareness training has a half-life of roughly six months before employees start reverting to habitual behavior. Phishing simulations trained on yesterday's templates do not prepare employees for tomorrow's novel campaigns. Training is expensive to run continuously and its effect degrades.

An infrastructure fix, by contrast, is permanent. A DMARC record at p=reject with full sender visibility stops impersonation attacks at the receiving server, every time, for every recipient, without requiring human judgment. It does not decay. It does not need refreshers. Once it is in place and all legitimate senders are authorized, it works.

The organizations that have reduced BEC exposure most effectively are the ones that invested in the infrastructure side first. Training became a supporting control, not the primary one.

FAQ

If DMARC is at p=reject, can scammers still send email that looks like it comes from our domain?

If a scammer controls a server that is authorized to send as your domain (for example, a compromised internal system, a misconfigured third-party vendor, or a compromised account at a cloud provider that has not implemented proper DKIM), DMARC can still pass. DMARC p=reject stops external impersonators who have no authorized relationship with your domain. It does not detect compromised accounts or trusted infrastructure that has been taken over.

Does implementing DMARC prevent invoice fraud and BEC?

DMARC at p=reject stops external attackers who are not authorized to send from your domain. Invoice fraud that originates from a compromised internal account, a hacked vendor, or a third-party platform that is authorized to send as your domain will not be stopped by DMARC. For those scenarios, you need sign-in logging, tenant-wide anomaly detection, and vendor security assessments.

Why do DMARC aggregate reports show failures from our own marketing platform?

Many marketing platforms send email on behalf of their customers without DKIM signatures that align to the customer's domain. This is a known gap in the email marketing industry. The fix is to work with your marketing platform to implement DKIM keys that are aligned to your domain, or to use a dedicated subdomain for marketing mail that has its own DMARC record.

How long does it take to move from p=none to p=reject?

Most organizations need 4 to 8 weeks to identify all legitimate senders from aggregate reports, authorize or remediate each one, and verify that no legitimate mail is being rejected before moving to p=reject. Organizations with complex sending infrastructure (multiple vendors, legacy systems, internal relays) may need longer.