Phishing protection: five places an attack can still fail

Phishing protection is usually presented as a product. It is better understood as a series of points at which an attack can still fail, and the useful question for any control is which point it covers and which it leaves open. A message has to be delivered, believed, acted on, and then converted into something valuable. Each step has a different defence, and no single product covers all of them.

Five places an attack can still fail

Stage	The attacker needs	Controls that act here
Delivery	The message reaches the inbox	Filtering, domain authentication, impersonation protection, blocking dangerous attachments
Belief	The recipient trusts the message	External marking, clear sender display, training, lookalike-domain defence
Action	The recipient clicks, signs in, or approves	Link checking, MFA that cannot be relayed, restricted app consent, reporting
Conversion	The stolen access or approval becomes value	Conditional access, session controls, mailbox monitoring, payment verification
Recovery	The damage is contained	Fast reporting, response runbook, revocation, notification

Filtering usually gets the most attention. Filtering is necessary and it will miss some messages, so the later rows decide how bad a miss is.

Delivery: what a filter can and cannot do

A filter scores messages on content, sender reputation, links and attachments, and increasingly on how unusual the sender is for that recipient. It is good at bulk and known-bad traffic. It is weakest against a short, plausible, one-off message from a compromised or newly created account, because there is nothing recognisably bad to match.

Practical settings that raise the bar without much cost:

• Apply the platform’s recommended preset policies rather than leaving defaults. These tighten several settings together.
• Name your high-value targets, usually owners, executives and finance, as protected users so impersonation of them is judged more strictly.
• Block or quarantine attachment types you never legitimately receive by email, such as executables and script files.
• Treat password-protected archives from outside as suspicious by default; scanners cannot look inside them.
• Make sure link protection and attachment detonation are on if your plan includes them, and confirm what they do to the user experience before you switch them on for everyone.

Domain spoofing, display-name spoofing and lookalikes

Three forgery techniques get confused, and they have different cures.

Exact-domain spoofing sends mail that claims to be from your real domain, for example ceo@example.com. DMARC enforcement stops this once receivers apply it. See SPF and DKIM and the DMARC rollout guide.

Display-name spoofing uses a free address with the executive’s name as the display name:

From: "Dana Whitfield (CEO)" <dana.whitfield.ceo@mail-service.example>

Authentication passes for the free service. The domain is real; the name is not. DMARC cannot help, because the From domain is not yours. What helps is a filter rule that flags a known executive’s name arriving from outside, the external-sender banner, and a staff habit of looking at the address and not just the name, particularly on a phone, where the address is often hidden.

Lookalike domains register a name close to yours: examp1e.com, example-billing.com, exarnple.com (where rn imitates m). The attacker owns the domain and can pass SPF, DKIM and DMARC for it. Here too DMARC on your domain is irrelevant. Defences are:

• Register the obvious variants of your name that are cheap to hold, and publish the non-sending records on them (v=spf1 -all, a reject DMARC policy, and a null MX).
• Watch for newly registered lookalikes, with a monitoring service or with the periodic searches of certificate-transparency logs that some tools automate.
• Add known lookalikes to impersonation protection.
• Teach finance staff that a payment request from a domain they have not paid before is, by definition, a new relationship that needs verification.

Belief: what makes people trust a message

Phishing works by borrowing trust from context. These are the contextual signals you control:

• Mark external mail with a short consistent tag, so a message that looks internal but is not stands out.
• Show the sender address where your mail clients allow it.
• Reduce your own spoofable surface. If staff are used to marketing mail arriving from no-reply@ addresses that are not authenticated, then an unauthenticated message does not look odd to them.
• Avoid training people to expect odd requests. If a legitimate process sends links to sign in and “verify your account”, a phisher’s message is indistinguishable from it.

Action: the credential page, the approval and the app

Three different “click” outcomes need three different defences.

Credential phishing sends the user to a page that collects the password. MFA reduces the damage, but a proxy-style page can relay both the password and an app code or SMS code to the real service in real time and capture the session. Only phishing-resistant sign-in, such as a security key or passkey bound to the genuine site, defeats that. Conditional access can also limit what a stolen session can do, for example by requiring a managed device for sensitive apps.

MFA fatigue bombards a user with approval prompts until one is accepted. Number matching, where the user must enter a number shown on the sign-in screen, makes blind approval impossible. Train staff that a prompt they did not trigger should be denied and reported, not approved to make it stop.

Consent phishing asks the user to grant a malicious application access to their mail. No password changes hands and MFA is satisfied by the user themselves. The cure is a tenant setting that stops users consenting to unknown applications without approval; see mailbox security.

QR-code phishing is the same attack with a different carrier: a QR code in an email or a document sends a phone, which is outside your corporate protections, to a credential page. Treat an unexpected QR code as you would an unexpected link.

Reporting: the control that scales

A staff member who reports a suspicious message within minutes gives you the only chance to remove the same message from every other mailbox before it is acted on. Three things make reporting work:

1. One step. A report button in the mail client. If reporting takes a forward-as-attachment ceremony, it will not happen.
2. An owner. Someone triages reports each working day and tells the reporter the outcome, even if it is “that was fine”. Silence trains people to stop.
3. No punishment. People who fear blame hide clicks. The first report of a click is the most valuable report you will get.

A triage routine for a reported message

When you open a reported message, work through the same checks every time:

1. From address: exact domain, character by character. Display name vs address.
2. Reply-To: does it point somewhere other than the sender?
3. Authentication-Results: spf / dkim / dmarc, and for which domains.
4. Links: hover or expand; do the real destinations match the claimed ones?
5. Attachments: type, and whether the message needed you to open them.
6. Who else received it? Search for the same sender or subject.
7. Did anyone click or reply? Check sign-in logs for those users.

A worked example of step 3 on a made-up header:

Authentication-Results: mx.receiver.example;
  spf=pass smtp.mailfrom=mail-service.example;
  dkim=pass header.d=mail-service.example;
  dmarc=pass header.from=mail-service.example

Everything passes, and it still proves nothing about the message you care about: the From domain is mail-service.example, not your supplier’s. Authentication confirms who sent it, not whether to trust what it says. Passing checks on an unknown domain are normal for attackers, who set them up correctly.

Training that is worth the time

The aim of awareness training is not to turn staff into analysts. It is to make three behaviours automatic:

• Look at the real sender address before acting on a request.
• Treat a request that mixes urgency with money, credentials or secrecy as a reason to slow down and verify.
• Report anything odd, quickly, without shame.

Short and regular beats long and annual. Use real examples drawn from what your own filters caught, and show the signal that gave each one away. Simulated phishing exercises can help you see where staff are, but they can also erode trust if they are punitive or deceptive in ways that feel unfair. Measure what matters operationally: how quickly suspicious mail is reported, not how many people “failed”.

Process controls: when the technology misses

When a message gets through everything above, the last defence is a procedure. Payment-detail changes verified by phone, a second approver for new payees, and a rule that no one is ever asked to buy gift cards or move money on the strength of an email are not security products. They are the controls that determine whether a successful phish costs you a password reset or a wire transfer. The runbook and the sample rule are in business email compromise.

How this fails

• Believing the filter is the control. A miss is inevitable. If the response to a miss depends on a perfect filter, it will fail.
• Passing authentication treated as trustworthy. It only shows the sender controls their domain.
• No owner for reports. Staff report once, hear nothing, and stop.
• Training that blames. It suppresses the one behaviour you most need.
• Protecting the domain and forgetting the people. DMARC does not help against display-name tricks or lookalikes.
• Approvals that were never designed. Prompts, consent screens and “just approve this” requests all assume the user knows when to say no.

What to do next

Pick the row in the table above where you have the weakest control and fix that one first. The email security readiness assessment will show which of your answers describe a gap in filtering, people or response. If your domain has no policy yet, start with SPF, DKIM and DMARC, and if the concern is money, read business email compromise.