# Pharming vs phishing

> Pharming redirects people to a fraudulent site through technical means. Phishing lures them there with a deceptive message. Learn the difference.

Phishing and pharming can both lead to a fraudulent login page or stolen credentials, but they start differently. [Phishing](https://www.nist.gov/itl/smallbusinesscyber/guidance-topic/phishing) uses a deceptive email, text, social message, or other prompt to persuade someone to act. [Pharming](https://csrc.nist.gov/glossary/term/pharming) uses technical redirection to send someone to a fraudulent site, including after they use a legitimate address or trusted route. A real incident can include both, so classify the initial path without assuming the exact cause of a redirect.

## Quick takeaways

- Phishing is message-led social engineering. The attacker wants a person to click, download, reply, or sign in after seeing a convincing prompt.
- Pharming is redirection-led. The attacker changes the path to a fraudulent site through technical means, which NIST says can involve infrastructure such as DNS or the person's endpoint.
- A fake page alone does not tell you which term applies. Ask how the person first reached it.
- Stop before entering credentials, then verify through a separately obtained route rather than the message or page already in front of you.
- [Email spoofing](/learning/what-is-spoofing), phishing, and pharming can appear in the same campaign, but they describe different pieces of it.
- Public SPF, DKIM, and DMARC checks can be useful for a domain owner, but they cannot explain an unexpected browser redirection.

## What phishing changes

Phishing is the lure. NIST describes it as convincing messages that trick a person into opening a harmful link, downloading malicious software, transferring funds, logging in, or providing sensitive information. The delivery channel can be email, text messaging, social media, or another electronic message. The common feature is that the attacker needs the person to believe a request and take the next step.

That is why the first evidence in a suspected phishing event is usually the communication itself. Preserve the sender identity, the request, the destination it named, and the action it tried to prompt. An urgent request that arrives through an unexpected channel deserves an independent check. NIST recommends using known contact information or a public company site to verify a request instead of relying on information inside the message.

The existing [phishing definition](/learning/what-is-phishing) covers the broader attack category and email-focused protections. This page stays narrower: it helps distinguish a lure from a technical redirection that may put a person on an almost identical fraudulent page.

## What pharming changes

Pharming changes the route. NIST defines it as using technical means to redirect users to a fake site that masquerades as a legitimate one. Its current glossary also says the redirection can arise from a compromised infrastructure service, such as DNS, or from the subscriber's endpoint. That mechanism matters because a person can start with a familiar address and still arrive somewhere untrustworthy.

The word does not prove that DNS was attacked. A browser, endpoint, router, network, or infrastructure investigation may be needed to identify what happened. Do not diagnose a DNS incident from a page that merely looks suspicious, and do not dismiss a redirection simply because no phishing email is available. The useful observation is that the user entered or followed a route they had reason to trust and was sent elsewhere.

For a deeper look at one possible infrastructure path, see [how DNS poisoning can redirect traffic](/learning/dns-poisoning-redirects-prevention). That is a separate technical diagnosis, not a substitute for this classifier.

## The lure-versus-redirection classifier

The shortest reliable question is: **How did the person first reach the fraudulent site?** A deceptive prompt that urges an action points to phishing. A legitimate address or trusted route that sends the person to a different place points to pharming. If the incident contains both, record both mechanisms instead of forcing it into one label.

```text
classification_record:
  first path: deceptive message or prompt
  label: phishing
  first path: legitimate address or trusted route redirected elsewhere
  label: pharming
  result: combined campaign if the observed evidence supports both
```

![Vertical decision diagram classifying a deceptive message or prompt as phishing and a legitimate address redirected elsewhere as pharming, with a note that both can occur together.](/images/editorial/pharming-vs-phishing/pharming-vs-phishing-classifier.svg "800x1500")

*Source: Original Palisade diagram based on [NIST's pharming glossary](https://csrc.nist.gov/glossary/term/pharming) and [NIST phishing guidance](https://www.nist.gov/itl/smallbusinesscyber/guidance-topic/phishing). It labels the initial mechanism and does not diagnose the technical cause of a redirect. [Open the full-size diagram](/images/editorial/pharming-vs-phishing/pharming-vs-phishing-classifier.svg).*

## How phishing and pharming can overlap

The terms are related because attackers often want the same outcome: a person submitting credentials or other sensitive data to a fraudulent site. [NIST's explicit comparison](https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=907707) explains the difference as a lure versus a redirection. In the phishing case, an attacker creates a fraudulent site and tries to get people there. In the pharming case, the attacker redirects a person from a legitimate site to the fraudulent site without that person's knowledge.

That leaves room for a combined incident. A deceptive message can lead someone to a counterfeit site. A message can also be the first step in compromising an endpoint or a network component, after which a later visit is redirected. The article does not need to guess whether that chain occurred. State the evidence you have: a message, a typed address, an unexpected destination, or more than one of those facts.

This distinction also keeps related terms from becoming interchangeable. [Spoofing](/learning/what-is-spoofing) is identity impersonation. It can make a phishing message more convincing, but it does not by itself establish that a visitor was redirected. Pharming describes the route to a fraudulent site, while phishing describes the deceptive prompt used to obtain an action.

## What to do first

The first response is the same whether the event seems like phishing, pharming, or both: stop before entering credentials, downloading a file, or approving a request. Then verify the organization through a route you obtain separately, such as a saved address, a verified contact number, or an independently located official site. Do not use a phone number, link, or chat prompt supplied by the suspicious message or page to perform that verification.

Separate the immediate safety action from the later technical investigation. A suspicious message gives a security team message and sender evidence to review. An unexpected redirect can require browser, endpoint, router, network, or DNS evidence. Treat the latter as a separate investigation boundary rather than changing records or credentials based on a guess from a lookalike page.

![Response map: stop before entering credentials, verify independently, then separate message evidence from unexpected-redirection evidence.](/images/editorial/pharming-vs-phishing/pharming-vs-phishing-response-map.svg "800x1660")

*Source: Original Palisade response map based on [NIST phishing guidance](https://www.nist.gov/itl/smallbusinesscyber/guidance-topic/phishing) and [NIST's pharming definition](https://csrc.nist.gov/glossary/term/pharming). It provides a safe triage boundary, not incident-response instructions or proof of a redirect's root cause. [Open the full-size diagram](/images/editorial/pharming-vs-phishing/pharming-vs-phishing-response-map.svg).*

If you already entered credentials or approved an unexpected request, use your organization's incident-reporting process and the real provider's established account-recovery route. This article cannot determine whether a device, account, resolver, or network was compromised. It can help you describe the event clearly enough that the right investigation starts with the right evidence.

## What email authentication can and cannot address

SPF, DKIM, and DMARC concern email identity and message handling. [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html) defines DMARC as a way for a domain owner to publish requested handling for messages that fail DMARC validation, while the receiver ultimately applies local policy. Those controls can reduce exposure to unauthorized use of a sending domain, but they are not browser, endpoint, router, or DNS-resolver forensics.

That boundary is important after a phishing report. A message that uses a forged sender identity may create a domain-authentication question. An unexpected visit after typing a familiar address creates a redirection question. The same incident may contain both questions, but a successful public record lookup does not prove that the page was legitimate, that a browser was not redirected, or that a receiver would handle a future message in a particular way. See [what DMARC does and does not do](/learning/what-is-dmarc) before using a mail-authentication result as evidence about a web destination.

## Review the public email-security signals you control

If you manage the domain an attacker impersonated, use the [Email Security Score](/tools/email-security-score) to review its public SPF, DKIM, DMARC, and related email-security signals before changing outbound authentication. That can help you separate an email-domain control question from a report about a fraudulent page.

A public check cannot identify why a browser was redirected, remove a fraudulent site, or prove that an individual message or site was safe. Keep any browser, endpoint, router, or DNS investigation on its own evidence path.

## Sources and further reading

- [NIST glossary: Pharming](https://csrc.nist.gov/glossary/term/pharming)
- [NIST small business guidance: Phishing](https://www.nist.gov/itl/smallbusinesscyber/guidance-topic/phishing)
- [NISTIR 7770, section 7.3.2: Phishing/Pharming](https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=907707)
- [RFC 9989: DMARC](https://www.rfc-editor.org/rfc/rfc9989.html)

## Frequently asked questions

### Can pharming happen without an email?

Yes. Pharming is about technical redirection to a fraudulent site, so a deceptive email is not required. NIST's glossary gives infrastructure and endpoint compromise as possible routes. If no message was involved, focus on how a familiar destination became an unexpected one rather than looking for a phishing email that may not exist.

### Is pharming a type of phishing?

No, not when you are classifying the initial mechanism. Phishing is a deceptive lure that asks a person to act. Pharming redirects a person to a fraudulent site through technical means. Both can seek the same credentials, and a campaign can include both, but the terms identify different parts of the path.

### Can a correct URL still lead to a fraudulent site?

Yes. That is the risk the pharming definition describes: a person can use a legitimate address and be redirected to a fraudulent destination through technical means. Do not enter credentials after an unexpected destination just because the original address looked familiar. Verify through an independent route.

### Do SPF, DKIM, and DMARC stop pharming?

No. SPF, DKIM, and DMARC address email authentication and the handling of email that fails validation. They can help a domain owner reduce certain sender-identity abuse, but they do not investigate or repair a browser, endpoint, router, or DNS redirection. Keep the two evidence paths separate.

### Can one campaign use phishing and pharming together?

Yes. A deceptive message can bring a person to a fraudulent site, and an attacker can also use technical redirection to send a trusted visit there. Record the message evidence and the redirect evidence separately. That preserves the distinction without pretending the terms are mutually exclusive.