Pharming vs phishing

Phishing and pharming can both lead to a fraudulent login page or stolen credentials, but they start differently. Phishing uses a deceptive email, text, social message, or other prompt to persuade someone to act. 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.

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 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. 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.

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

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 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 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.

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 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 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 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.