# What exactly is spoofing and how can you stop it?

> Spoofing is impersonation that makes a message, call, website, or network request appear trusted. Learn how to identify and limit spoofing for your domain.

Spoofing is an impersonation technique that makes a message, call, website, or network request appear to come from a trusted source. Attackers use it to make a request look familiar before trying to obtain credentials, money, information, or access. You stop spoofing with controls matched to the channel: verify unusual requests independently, protect DNS and network paths, and use SPF, DKIM, and DMARC to limit unauthorized use of your email domain.

## Quick takeaways

- Spoofing falsifies or imitates an identity, address, or signal so a target trusts it.
- Phishing is the deceptive request or lure, while spoofing is often the impersonation technique that makes that lure believable.
- A familiar display name, logo, caller ID, or domain is not proof of identity.
- Email authentication can help receivers identify mail that is not authorized to use a visible From domain.
- DMARC does not stop look-alike domains, compromised accounts, fraudulent phone calls, or every phishing message.
- The safest response to an unusual request is to verify it through a separate, known contact path.

## How spoofing works

The [NIST glossary definition of spoofing](https://csrc.nist.gov/glossary/term/spoofing) describes it as falsifying data to make it appear to come from a trusted source. The falsified element depends on the channel. An attacker can imitate an email address, a website's appearance, a caller ID value, a DNS response, or an IP source address.

Spoofing works because people and systems often use visible identifiers as shortcuts. A display name that says "Accounts payable" can look familiar even when the underlying email address is unrelated. A web page can copy a legitimate brand's colors and sign-in form while using a different domain. A caller ID can display a number that appears local or known.

Phishing and spoofing overlap, but they are not identical. The [US Cybersecurity and Infrastructure Security Agency's phishing guidance](https://www.cisa.gov/topics/cyber-threats-and-advisories/malware-phishing-and-ransomware/phishing-guidance) describes phishing as deceptive messages intended to persuade recipients to take an action. Spoofing can support phishing by making the sender, site, or caller appear legitimate. Spoofing can also occur in network traffic without a phishing message.

Email spoofing has a defined technical defense path. [RFC 9989](https://datatracker.ietf.org/doc/html/rfc9989) specifies DMARC, which evaluates whether SPF or DKIM passes with a domain aligned to the visible Header From domain. A DMARC policy lets a domain owner publish requested handling for messages that fail that evaluation. The receiving mail system still makes its own final delivery decision.

For more detail on the controls involved, see the [email authentication learning hub](/learning).

## When the answer changes

The right defense changes with the identity being impersonated and the evidence you have.

- If the concern is a suspicious email, inspect the full sender address, destination URLs, and the delivered message's authentication results. Do not rely on the display name.
- If the concern is a website, enter the known address yourself or use a saved bookmark. Check the complete domain before entering credentials.
- If the concern is an unexpected call or text, end the interaction and contact the organization using a number or app you already know is legitimate. The [Federal Communications Commission's caller ID spoofing guidance](https://www.fcc.gov/spoofing) explains that caller ID information can be manipulated.
- If the concern is a network request or DNS response, use network and DNS logs to investigate. A public email-authentication lookup cannot explain a packet-level or resolver-level incident.

A useful decision rule is this: validate the identity through evidence that the alleged sender did not provide. For an email, that can include authentication headers and a separate contact channel. For a payment request, use the supplier contact record your organization already maintains. For a website, use a bookmarked domain or a trusted password manager entry.

> Do not change a domain's DMARC policy solely because of one suspicious message. First determine whether the message used your domain, whether it failed DMARC, and whether legitimate production senders would be affected.

## A worked email spoofing example

Suppose a message displays `Billing Team <billing@yourdomain.com>`. The display name and visible address can look valid, but the received message contains evidence that shows what the receiving system evaluated.

```text
Authentication-Results: mx.example.net;
  spf=fail smtp.mailfrom=mailer.example-attacker.com;
  dkim=none;
  dmarc=fail header.from=yourdomain.com
```

This is an illustrative example, not a header from a real message.

[RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html) defines the `Authentication-Results` header field used by message-handling systems to record authentication assessment results. In this example, SPF failed for the envelope sender, no DKIM result is present, and DMARC failed for `yourdomain.com`.

That result supports a narrow conclusion: this receiver found no aligned SPF or DKIM pass for the visible From domain. It does not prove who sent the message, whether every receiver reached the same result, or whether the sender's account was compromised.

![Flow showing how a suspicious email is checked through the visible From domain, authentication results, and independent verification](/images/editorial/what-exactly-is-spoofing-and-how-can-you-stop-it/what-exactly-is-spoofing-and-how-can-you-stop-it-spoofing-check-flow.webp "1200x829")

*Source: Palisade.*

If your domain appears in the visible From address, collect the raw headers from a delivered copy and compare them with DMARC aggregate-report data once reports have accumulated. This distinguishes a public DNS record from the actual production message path.

## What to do next, based on the evidence

Start with the evidence closest to the event.

- For a suspicious request received by a person, do not reply, click, or use contact details in that request. Verify the request through a separate trusted channel.
- For a suspicious website, preserve the URL and report it through your organization's security process. Change passwords only through the legitimate site's known address.
- For mail that claims to be from your domain, save the raw headers and inspect `Authentication-Results`. Check whether SPF or DKIM authenticated with the visible From domain.
- For a domain you manage, publish and maintain SPF and DKIM for authorized sources, then use DMARC reporting to identify sources and alignment failures before considering a stronger policy. The related guide on [stopping spoofing attacks](/learning/what-exactly-is-spoofing-and-how-can-you-stop-it) covers the email-focused response in more depth.
- For network-address impersonation, investigate firewall, router, DNS, and application logs. [IP spoofing has separate network-level controls](/learning/how-does-ip-spoofing-work-and-how-can-you-stop-it).

Validate an email-authentication change at four layers. Query authoritative DNS and a public resolver. Confirm the sending provider's current authentication status. Send a real message through the exact production path and inspect its raw headers. Then review DMARC aggregate reports after data accumulates. A DNS result alone does not prove that an application is signing mail or using the configured return path.

## Check the DMARC record behind email-domain spoofing

If a suspicious message uses a domain your organization manages, inspect the published DMARC record before changing its policy. Compare the lookup with the raw message headers and the approved DNS configuration.

[Check the domain's DMARC record](/tools/dmarc)

A public DMARC lookup cannot prove why one receiver handled a message a certain way, identify a caller or website, or show every production sender that still fails alignment. Palisade is agent-first DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and proposes prioritized remediation work. A human reviews the evidence and applies any DNS or policy change.

When reports show recurring unknown sources or alignment failures across domains, [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=email_authentication&utm_content=what-exactly-is-spoofing-and-how-can-you-stop-it).

## Sources and further reading

- [NIST Computer Security Resource Center glossary: spoofing](https://csrc.nist.gov/glossary/term/spoofing)
- [CISA phishing guidance](https://www.cisa.gov/topics/cyber-threats-and-advisories/malware-phishing-and-ransomware/phishing-guidance)
- [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://datatracker.ietf.org/doc/html/rfc9989)
- [RFC 8601: Message Header Field for Indicating Message Authentication Status](https://www.rfc-editor.org/rfc/rfc8601.html)
- [FCC caller ID spoofing guidance](https://www.fcc.gov/spoofing)

## Frequently asked questions

### Is spoofing the same as phishing?

No. Spoofing is the imitation or falsification of an identity or source. Phishing is a deceptive attempt to persuade someone to take an unsafe action. A phishing email often uses spoofing, but a spoofed network address does not necessarily involve phishing.

### Can DMARC stop all email spoofing?

No. DMARC helps receivers evaluate unauthorized use of the visible From domain when SPF or DKIM does not pass with alignment. It does not stop look-alike domains, compromised legitimate accounts, or every phishing message that uses another domain.

### Does a sender display name prove an email is legitimate?

No. Display names are easy to copy. Inspect the complete sender address, raw message headers when available, and the request itself. Verify unusual payment, credential, or account-change requests through a separate known contact channel.

### Can a caller ID be spoofed?

Yes. The FCC states that caller ID information can be manipulated. Treat an unexpected call as unverified, especially when it asks for a password, verification code, payment, or remote access.

### Can SPF alone prevent email spoofing?

No. SPF checks the envelope sender against published authorization, while DMARC evaluates aligned SPF or DKIM against the visible Header From domain. A complete email-domain protection plan normally needs properly configured SPF, DKIM, and DMARC.