Phishing

Phishing is email that impersonates a party the recipient trusts in order to obtain something: login credentials, payment details, or an instruction carried out on the attacker’s behalf. It is the most damaging category of abuse, because it targets the person rather than the software, and no filter is the last line of defence when the last line is a human being under time pressure.

What kinds of phishing exist?

• Credential phishing. A link to a convincing copy of a login page. Mail system credentials are the highest-value target, since a working mailbox unlocks password resets everywhere else.
• Spear phishing. The same idea, aimed at one named person and written with knowledge of their role, their colleagues and their current projects.
• Business email compromise (BEC). A request — apparently from an executive, a supplier or a lawyer — to change bank details or make an urgent transfer. Typically plain text with no link and no attachment, which is exactly why content filters have so little to work with.
• Clone phishing. A genuine message the recipient already received, resent with the link or attachment swapped.
• Thread hijacking. A reply injected into a real, ongoing conversation from a compromised participant. The context is authentic, so the usual cues are absent.

What does a phishing message look like?

Credential phishing is recognisable in the headers more often than in the text:

Return-Path: <bounce@mail-secure-notice.example>
Received: from mail-secure-notice.example ([192.0.2.77])
	by mx1.example.org with ESMTP; Tue, 04 Aug 2026 07:44:11 +0000
From: "IT Service Desk" <support@mail-secure-notice.example>
To: <employee@example.org>
Subject: Action required: your mailbox will be deactivated

Your mailbox has exceeded its storage quota and will be deactivated
within 24 hours. Confirm your account to keep it active:

  https://example-org-mail-verify.example/login

IT Service Desk

The display name claims one identity while the actual address belongs to a domain registered for the occasion, and the link points somewhere else again. BEC has none of this — no link, no unusual domain, often a free mailbox provider and a display name matching a real executive.

Which technical signals help?

• Authentication results. A message claiming to be from your own domain that fails DMARC alignment is a straightforward reject — but only if you publish a p=reject policy.
• Domain age and reputation. Phishing domains are usually registered days before use, so newly seen domains in links deserve extra scoring.
• Lookalike detection. Character-substitution domains and additions such as -secure or -verify against a list of names you care about.
• First-contact heuristics. A first-time external sender making a financial request is the signal that catches BEC, where nothing else does.
• Display name versus address mismatch, particularly when the display name matches an internal person but the address does not.

What actually reduces the damage?

Detection helps, but the controls that change outcomes assume some phishing will succeed:

1. Multi-factor authentication on all mail access. It converts a stolen password from a compromise into a failed login.
2. A DMARC policy at p=reject, so at least nobody can spoof your own domain at your own staff.
3. External sender marking in the mail client, which makes an impersonated internal address visibly external.
4. Out-of-band verification for payment changes. A callback to a known number, never to one in the message. This single process control defeats most BEC regardless of what the filter did.
5. A reporting button that people actually use, with a response that thanks them rather than blames them for clicking. Under-reporting is the bigger problem.
6. Monitoring for the aftermath — unusual authentication sources, sudden outbound volume, new forwarding rules on a mailbox. See access management.

What should you do with a phishing report?

If your users report phishing that reached them, the message belongs to the abuse desk of the network it came from, reported to their abuse@ address, ideally as an ARF report with Feedback-Type: fraud. Include full headers — a report without them is usually unactionable.

If a credential page was hosted somewhere, report it to that host as well. Phishing infrastructure is generally taken down quickly once someone with authority over it is told, and the report is often the only way they find out.

Related reading

• Howto block Google Groups spam in Rspamd — phishing delivered through a reputable provider, where SPF, DKIM and DMARC all pass and a single header check is what stops it.
• Howto block entire TLDs in Postfix — blunt but effective against the throwaway domains phishing runs are registered on.