defensiva
spoofing
email spoofing
ARP spoofing

What is spoofing: types, examples and prevention techniques

What is spoofing in cybersecurity: types (email, ARP, DNS, IP, caller ID, GPS), detection techniques and defensive controls for business.

SecraJune 8, 202614 min read

Spoofing is the technique by which an attacker forges the origin of a communication in order to impersonate a legitimate identity and, under that appearance, gain trust, access or evasion. In cybersecurity the term describes a broad family of attacks that share one principle: making a system, a person or a protocol believe they are talking to someone they are not. An email that appears to come from the CFO, a WiFi access point that copies the corporate SSID, an ARP reply claiming to be the network gateway, a phone call showing the bank's number. All of them are spoofing.

Unlike attacks that break a cipher or exploit a software vulnerability, spoofing exploits the fact that many communication protocols were designed without robust authentication of origin. SMTP, ARP, DNS, IP, the legacy telephone system, even certain components of TLS assume the sender is who they say they are. This guide walks through the spoofing variants that matter inside a company, how email has built three defensive layers (SPF, DKIM, DMARC), why the internal network is still vulnerable to ARP and DNS poisoning, and how all of this maps to NIS2 and GDPR obligations.

The essentials: spoofing is the source impersonation mechanism; phishing and other attacks are the end goal stacked on top of it. Defending a company against spoofing requires three simultaneous fronts: email (SPF, DKIM, DMARC in reject mode), corporate network (DHCP snooping, Dynamic ARP Inspection, 802.1X) and human procedures (out of band verification for payment orders and sensitive changes).

What is spoofing: definition and difference with phishing

Spoofing is the technical act of forging the apparent origin of a communication. An email with a From: ceo@company.com header that did not originate at the company server is spoofing. An ARP frame claiming "my MAC is the gateway's" is spoofing. A phone call whose Caller ID shows the bank's number but actually leaves an arbitrary VoIP gateway is spoofing.

Phishing, by contrast, is the fraud objective the attacker pursues when they convince a victim to hand over credentials, click a malicious link or authorise a payment. The relationship is hierarchical: phishing very often uses spoofing as a delivery mechanism, but not every spoofing attack ends in phishing. An attacker may use ARP spoofing only to sniff internal traffic, or GPS spoofing to divert a drone, without asking the user for anything.

The distinction matters for defence: blocking spoofing requires protocol level controls (cryptographic authentication, segmentation, validation), while phishing is also fought with training, human verification and process rules. An organisation that only trains its employees without hardening email leaves the door ajar; one that only configures SPF and DMARC without teaching staff how to verify urgent transfers out of band also does. Both defences are complementary and are covered in depth in the types of phishing guide and the how to avoid phishing one.

Main spoofing types

The catalogue of variants has grown with every new communication technology. These are the ones that show up regularly in corporate incidents.

Email spoofing

The most widespread. SMTP does not require the sender declared in the From header to match the server domain that delivers the email. Without SPF, DKIM and DMARC in place, any server can send a message claiming to be anyone@company.com. Common techniques include forging the visible From header, manipulating Return-Path, look-alike domains (such as company-corp.com) and compromising legitimate accounts to relay internal messages with valid headers. This last case, Business Email Compromise, accounts for most of the email related fraud documented in mid-sized and large enterprises.

IP spoofing

Forging the source IP address of TCP/IP packets. Useful to hide the real origin of an attack, build DDoS reflection or bypass controls based on trusted IPs. Its usefulness as a direct intrusion vector is limited because the TCP response goes back to the spoofed IP, except in blind attacks or when the attacker sits on the path.

ARP spoofing

In switched local networks, ARP associates IPs to MAC addresses. An attacker on the same VLAN sends unsolicited ARP replies claiming the gateway's MAC is theirs. Devices update their tables and route traffic toward the attacker, creating a Man in the Middle across the subnet. It is one of the first moves in internal red team work when the defender has not deployed Dynamic ARP Inspection.

DNS spoofing and DNS cache poisoning

The attacker manipulates DNS responses so that a legitimate domain resolves to an IP under their control. The classic vector poisons the cache of an internal resolver; the modern one includes compromise of home routers. Covered in depth in the pharming guide.

Caller ID spoofing (vishing)

Manipulation of the phone number displayed on the victim's screen. VoIP gateways allow the source number to be declared almost freely, which is exploited both for mass fraud and for targeted vishing against employees. Regulators in the United States (STIR/SHAKEN) and the European Union are working on authentication frameworks, but coverage is still partial.

GPS spoofing

Injection of fake GPS signals so a receiver believes it is in a different position. Documented applications include interference with civilian and military drones, vessel diversion and manipulation of geolocation systems to bypass geographic access controls. A specific vector for defence, transport and logistics.

HTTPS and TLS spoofing

Although TLS protects against impersonation when the certificate chain is validated correctly, there are scenarios where an attacker installs a rogue root certificate on the victim machine, forces downgrade attacks or exploits hostname validation flaws in poorly written applications. Use of a malicious or compromised CA is the best known historical case.

SMS spoofing

Forging the alphanumeric sender of an SMS to impersonate a bank, a public administration or a delivery service. Some carriers allow declaring the sender name without cryptographic verification, which makes targeted smishing easier.

WiFi and Evil Twin AP

A malicious access point clones the SSID and configuration of a legitimate one. Client devices set to reconnect to known networks connect to the attacker's AP, which captures traffic, intercepts credentials and runs MITM on connections that do not enforce strict TLS.

MAC address spoofing

Forging a network interface's MAC to bypass MAC based access controls, evade captive portals or impersonate an authorised device on networks that only authenticate by MAC. The right defence is 802.1X instead of MAC based control.

Real enterprise cases

Spoofing shows up regularly in documented incidents.

BEC and CEO impersonation. An email appearing to come from the CEO or CFO, sent to a treasury manager, requesting an urgent and confidential transfer to a new supplier. Aggregate figures published by the FBI on BEC place this vector among the largest sources of economic loss from cybercrime in mid-sized and large companies.

Targeted spear phishing. Campaigns that combine email spoofing with prior reconnaissance on LinkedIn and public records. The attacker sends an email to a specific profile (IT, HR or finance lead) from a look-alike domain or a compromised account of a real supplier.

Targeted DNS poisoning. Attacks against internal resolvers to redirect queries to fake authentication portals. Documented against webmail portals, admin panels and internal SaaS services.

Internal ARP spoofing during red team. Once the offensive team gains access to a network jack or a client machine, ARP poisoning allows capturing NTLM credentials, Kerberos hashes and internal sessions. Mitigated with DAI, still not deployed in many organisations.

Email spoofing in detail

Email is the front where the most effective controls are available. Three defensive layers operate at complementary levels.

SPF (Sender Policy Framework) publishes in DNS which servers are authorised to send mail on behalf of the domain. The receiver verifies whether the sending server's IP is authorised. It fails when mail is forwarded (forwarders break SPF unless they rewrite the envelope) and when the visible From header differs from the envelope domain.

DKIM (DomainKeys Identified Mail) cryptographically signs headers and body with the sending domain's private key. The receiver verifies the signature with the public key in DNS. It fails when an intermediate gateway modifies headers or body, or when the domain does not sign all outbound flows.

DMARC combines SPF and DKIM with alignment on the visible From domain and publishes a policy (none, quarantine, reject). DMARC with reject is the only configuration that actively rejects forged mail from the header domain. Deployment requires a prior observation period with p=none, fixing unaligned legitimate flows and only then moving to reject.

BIMI is the next step: it requires DMARC at reject and a VMC to display the corporate logo in compatible clients (Gmail, Apple Mail). It does not add direct technical security but reinforces visual identity and discourages impersonation.

Microsoft 365 and Google Workspace include SPF for their infrastructure. DKIM has to be enabled explicitly per domain. DMARC requires publishing the record in DNS and monitoring aggregate reports. A proper initial audit detects SaaS providers that send on behalf of the domain without being in SPF, and flows not signed with DKIM.

ARP and DNS spoofing in corporate networks

LAN traffic remains the other front where spoofing is effective.

ARP spoofing on the LAN. The reference defence is Dynamic ARP Inspection (DAI) on access switches, complemented by DHCP snooping that builds the table of authorised IP to MAC mappings. Without DAI, any device plugged into a port can poison ARP tables for the segment. In addition, port security limits the number of MACs per port and 802.1X authenticates the device before letting it enter the network. This hardening layer is covered in detail in the network and system hardening guide.

DNS spoofing on the corporate network. The internal resolver (typically Active Directory in Windows shops) should run with DNSSEC enabled to validate responses from signed zones. Adopting DoH (DNS over HTTPS) and DoT (DNS over TLS) encrypts the channel but does not sign the response, so it covers confidentiality and not integrity on its own. A solid architecture combines both: DNSSEC for origin integrity, DoT or DoH for channel encryption.

Detecting anomalous traffic on these layers requires passive monitoring (Zeek or equivalents) that logs sudden changes in ARP tables, spikes of unsolicited DNS responses or unexpected TTL drops on critical zones.

Spoofing detection

Indicators worth monitoring:

  • Email gateway analytics. Aggregate DMARC reports, share of rejected messages, new sender domains, spikes of messages with inconsistent headers.
  • IDS and IPS rules. Signatures for suspicious gratuitous ARP, DNS responses not tied to previous queries, packets with forged source IP entering through unauthorised interfaces.
  • Network monitoring. Zeek, Suricata or equivalents capture raw traffic and allow custom rules (sudden RTT drop to a key host, DNS responses with unusually low TTL, flows toward hosts that are not in inventory).
  • GeoIP anomaly detection. SaaS logins from impossible locations relative to the last access, useful when the attacker has combined spoofing with cookie or token exfiltration.
  • Controlled sniffers to detect unusual traffic or ARP poisoning attempts. The sniffer and network traffic analysis guide covers the workflow.

Effective prevention

The measures that actually defend against the most relevant spoofing categories:

  • Email: strict SPF without +all mechanisms, DKIM signing all outbound flows, DMARC at p=reject after an observation period, BIMI once DMARC is already strict.
  • Internal network: 802.1X on access ports, DHCP snooping, Dynamic ARP Inspection, port security, VLAN segmentation, passive monitoring.
  • DNS: DNSSEC enabled on own zones, DNSSEC validation in the internal resolver, encrypted channel with DoT or DoH to the upstream.
  • WiFi: WPA3-Enterprise with certificate based authentication, rogue AP detection, no open SSIDs in the office.
  • Procedures: out of band verification for payment orders and sensitive changes, periodic BEC training, segregation of duties in transfer authorisation.
  • Hardware-backed MFA. WebAuthn security keys (YubiKey and similar) prevent an attacker holding credentials and cookies from impersonating the user, neutralising many vectors that combine spoofing with session theft.

Fit with NIS2 and GDPR

Spoofing has direct impact on regulatory obligations.

NIS2 article 21 requires technical and organisational security measures, including controls on electronic communications. An organisation within the NIS2 scope that has not deployed SPF, DKIM and DMARC on its email, nor layer 2 controls against ARP spoofing, can hardly argue that it has applied the state of the art required by the directive.

GDPR article 32 mandates appropriate technical and organisational measures to ensure confidentiality and integrity of personal data. If a BEC incident triggers exfiltration of personal data (customers, employees, candidates), the data controller is required to notify the supervisory authority within 72 hours and, if the risk is high, also the data subjects. Absence of DMARC and of dual control over payments often appears in enforcement files as an aggravating factor.

Frequently asked questions

Is SPF alone enough to prevent email spoofing?

No. SPF validates the sending server's IP against the envelope domain (MAIL FROM), but it does not check the visible From header. An attacker can send mail with a MAIL FROM from a domain under their control (which passes SPF) and put the target domain in the visible From. Only DMARC enforces alignment between the two fields.

Can DMARC in reject mode break legitimate mail?

It can, if applied without a prior observation period. The correct procedure is to publish DMARC at p=none for several weeks, analyse the aggregate reports, identify every SaaS provider and internal flow sending on behalf of the domain and authorise them in SPF and DKIM. Only when all legitimate flows are aligned, you move to quarantine and finally to reject.

It depends on usage and jurisdiction. In most European countries and in the United States, modifying caller ID with fraudulent intent is illegal. Legitimate use cases exist (PBXs showing the company's main number, privacy services). The problem is that many international gateways allow declaring caller ID without verification.

Can ARP spoofing be detected without deploying DAI?

Partially. Endpoint tools (arpwatch, scripts monitoring the local ARP table) flag unexpected MAC changes for the gateway. Network IDS detect abnormal gratuitous ARP. This is reactive detection: the attack is already in progress. The real preventive defence is DAI on the switches.

Does a VPN prevent spoofing?

It prevents some vectors and not others. A properly configured VPN protects traffic to the concentrator, so it mitigates ARP spoofing on the local network, MITM on public WiFi and, if it forces DNS to the concentrator, also local DNS spoofing. It does not prevent email spoofing, GPS spoofing, BEC or anything that happens once the traffic leaves the tunnel.

Who implements DMARC in an organisation?

The technical configuration is owned by the mail administrator (sysadmin, IT team). Report analysis and the decision to tighten policy should be shared with the security lead and, in larger organisations, with marketing. An external consultancy specialising in mail audit speeds the process and reduces the risk of breaking legitimate flows during the transition to reject.

Email and network audit with Secra

Secra audits your organisation's SPF, DKIM and DMARC configuration, identifies unsigned flows and unauthorised SaaS providers, and accompanies the transition from p=none to p=reject without breaking legitimate mail. On the network layer, we assess defence against ARP and DNS poisoning, validate deployment of DAI, DHCP snooping and 802.1X, and run red team exercises with real spoofing techniques to measure the SOC's detection and response capability. If your organisation falls under NIS2 or needs to substantiate GDPR article 32 measures, this work delivers direct documentary evidence.

For an initial assessment with no commitment, write through contact and we will schedule a session to review the current state of your email and internal network.

About the author

Secra Solutions team

Ethical hackers with OSCP, OSEP, OSWE, CRTO, CRTL and CARTE certifications, 7+ years of experience in offensive cybersecurity, and authors of CVE-2025-40652 and CVE-2023-3512.

Share article