Phishing Defense Strategies: Controls That Actually Work

The phishing defenses that work are layered: stop attackers from spoofing your own domains with SPF, DKIM and DMARC at enforcement; filter inbound mail; make stolen credentials useless with phishing-resistant MFA such as passkeys or FIDO2 security keys; put out-of-band checks on payments and other high-value requests; and make reporting a suspicious message a one-click habit that the security team acts on within minutes. Training matters, but some messages will always get through, so the design goal is that one click does not become one breach.

Key takeaways

• Phishing-resistant MFA is the control with the most leverage. Codes and push prompts can be relayed by a proxy login page; passkeys and security keys cannot.
• DMARC at p=reject stops exact-domain spoofing of your brand. It does nothing about lookalike domains, which is why filtering and training still matter.
• The target is usually a session, not a password. Response must revoke sessions and refresh tokens, not just reset the password.
• Business email compromise is a process problem as much as a technical one. Any change of bank details gets verified by phone on a number you already had.
• Measure reporting, not just clicking. A fast report from the first recipient protects everyone else who got the same message.
• Your help desk is part of the attack surface. A strong MFA rollout with a weak account recovery process just moves the phishing to the phone.

What modern phishing is after

Most phishing aimed at companies is after one of three things: a session for a cloud account (email, SSO, code hosting, cloud console), a payment, or a foothold on a device. The lure changes (shared document, voicemail, invoice, HR policy, QR code on a parcel notice), but the objective is stable, and that is what to design against.

The important shift of the last few years is adversary-in-the-middle phishing. Instead of a static fake login page that collects a password, the attacker's page proxies the real sign-in in real time. The victim types their password and their MFA code, the real service accepts both, and the attacker keeps the session cookie. Code-based and push-based MFA do not stop this, because the victim really did complete MFA. That is why the MFA section below matters more than any filter setting.

Layer 1: stop spoofing of your own domain

SPF, DKIM and DMARC protect the people who receive mail claiming to come from you: customers, suppliers and your own staff.

A typical starting set for a company sending through Google Workspace and one transactional provider:

example.com.          TXT  "v=spf1 include:_spf.google.com include:amazonses.com ~all"
_dmarc.example.com.   TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; fo=1"

Then enable DKIM signing in each sending platform with your own domain, not the provider's default, and publish the keys they give you.

The rollout

Move on when the reports show every legitimate source passing, not on a calendar. Aggregate reports are XML and unpleasant to read by hand; use a DMARC report processor, hosted or open source, so you can see sources by volume.

Domains that never send mail should say so explicitly:

parked-example.com.          TXT  "v=spf1 -all"
_dmarc.parked-example.com.   TXT  "v=DMARC1; p=reject"
parked-example.com.          MX   0 .

The last line is a null MX record (RFC 7505), which tells senders the domain accepts no mail.

Where DMARC rollouts break

• The SPF lookup limit. SPF allows at most 10 DNS lookups during evaluation (RFC 7208). Each include: can pull in more. Exceed the limit and SPF returns a permanent error, which counts as a failure. Remove unused senders and prefer DKIM alignment for third-party services.
• Alignment, not just passing. A marketing platform can pass SPF for its own bounce domain and still fail DMARC, because that domain is not yours. Configure custom DKIM (and a custom return path where offered) for every SaaS that sends as you.
• Forwarding and mailing lists. Forwarded mail usually breaks SPF; mailing lists that modify messages break DKIM. Receivers that honor ARC can still accept these, but expect some legitimate edge cases in reports.

Large mailbox providers now require this anyway: since February 2024, Gmail and Yahoo require SPF, DKIM and a DMARC record from bulk senders. If your product sends email at volume, this is a deliverability requirement as well as a security one.

Layer 2: filter what comes in

Inbound filtering catches the bulk. Microsoft Defender for Office 365, Google Workspace's built-in protections and third-party secure email gateways all offer roughly the same controls. Make sure these are on:

• Time-of-click URL checking. Links are rewritten and checked when clicked, not just at delivery, because many phishing pages are benign at delivery and armed later.
• Attachment sandboxing for document types that can carry active content.
• Impersonation protection for executives, finance staff and key suppliers: display names that match a protected person from an address that does not.
• Lookalike domain detection for your own domains and your main suppliers' domains.
• External sender tagging, a visible banner on mail from outside the organization. It is crude and it works, especially on messages pretending to be internal IT.
• QR code inspection. QR codes move the link to a phone, outside your web proxy. Filters now decode them; make sure yours does.

No filter catches everything, and over-tuned filters quarantine invoices and job applications. Treat filtering as volume reduction, not as the last line.

Layer 3: make stolen credentials useless

This is the layer that turns a successful phish into a non-event.

FIDO2 and passkeys resist proxy phishing because the browser binds the credential to the website's origin. A page on a lookalike domain cannot ask for the credential that belongs to the real domain, so there is nothing to relay. CISA's guidance calls FIDO-based authentication phishing-resistant for exactly this reason.

You do not need to switch everyone on day one. Prioritize:

1. Administrators of the identity provider, email, cloud consoles and code hosting.
2. Finance and payroll, who are the target of payment fraud.
3. Engineers with production access.
4. Everyone else, as passkey support in your tools allows.

Then tighten the session side, because a stolen session cookie skips sign-in entirely:

• Require managed or compliant devices for sensitive apps where your identity provider supports it. A session stolen to an attacker's machine fails the device check.
• Use token binding where your identity provider offers it, so a session token only works on the device it was issued to.
• Block sign-in flows you do not use. If nobody signs in with device codes, block the device code flow in your identity policies; it has been abused in consent and code phishing campaigns.
• Restrict OAuth consent. Do not let users grant mailbox or file access to unverified third-party apps. Illicit consent grants survive password resets.

Our identity and access management guide covers rolling out these policies without locking people out, and the zero-trust guide covers device-based access more broadly.

Layer 4: protect the money

Business email compromise often involves no malware and no link. A message from a compromised or lookalike supplier account asks finance to update bank details before the next invoice. Technical controls help, but the reliable control is process:

• Verify every change of payment details out of band, by calling a phone number already on file, never one in the message.
• Require two people to approve new payees and changes to existing ones.
• Treat urgency plus secrecy as a stop sign. "The CEO needs this today and it is confidential" is the pattern, whatever channel it arrives on, including a voice call that sounds right.
• Block automatic forwarding to external addresses at the mail platform. Attackers who get into a mailbox commonly set a rule to forward or hide payment conversations.

Layer 5: people, reporting and simulations

The most valuable human behavior is not spotting every phish. It is reporting quickly. The first person to report a campaign lets the security team pull the same message from every other inbox before the rest of the company reaches it.

Make reporting effortless: the built-in report button in Outlook or Gmail, wired to a mailbox your team or tooling actually triages. Close the loop with the reporter, even with an automated "thanks, this one was malicious and we removed it from every inbox" message, because people repeat behavior that gets acknowledged.

Training works best short, frequent and specific to your environment: what your real sign-in page looks like, how IT will and will not contact staff, how payment changes are verified. Cover phone and text, not just email.

Simulations are useful when they measure reporting and give immediate, respectful feedback. They do damage when they are used to shame individuals or when the lures exploit things people care about, such as bonuses or layoffs, because staff stop trusting real internal messages and stop reporting. Track report rate and time to first report alongside click rate, and look at trends across the organization, not individual scores.

When someone clicks

Treat a report of "I entered my password" or "I approved a prompt I did not expect" as an account compromise and move quickly. The general structure belongs in your incident response playbook; for Microsoft 365 the core steps look like this:

Connect-MgGraph -Scopes "User.RevokeSessions.All","UserAuthenticationMethod.Read.All"
Revoke-MgUserSignInSession -UserId "jane@example.com"
Get-MgUserAuthenticationMethod -UserId "jane@example.com"
 
Connect-ExchangeOnline
Get-InboxRule -Mailbox "jane@example.com" |
  Where-Object { $_.ForwardTo -or $_.ForwardAsAttachmentTo -or $_.RedirectTo -or $_.DeleteMessage } |
  Format-List Name, Enabled, ForwardTo, RedirectTo, DeleteMessage, MoveToFolder

The full checklist:

1. Revoke sessions and refresh tokens, then reset the password. Resetting alone leaves the stolen session working until it expires.
2. Remove MFA methods the attacker registered. Adding their own authenticator is a common first move.
3. Remove inbox rules that forward, delete or hide mail, and check mailbox delegation.
4. Review OAuth app grants made by the user during the window and revoke unknown ones.
5. Read the sign-in logs for the account: where else did that session or password get used?
6. Purge the message from every mailbox that received it, using your platform's search and purge, and block the sender and URLs.
7. Check for internal spread. Compromised mailboxes are used to phish colleagues and customers, because those messages are trusted.

Feed the reported messages and response outcomes into your detection tooling; our SIEM and SOC guide covers alerting on the sign-in and mailbox events that usually follow a successful phish.

Measuring the program

• Share of privileged and finance users on phishing-resistant MFA. The leading indicator that matters most.
• DMARC status of every domain you own, including parked ones.
• Time from first report to purge across all mailboxes.
• Report rate and time to first report for real and simulated campaigns.
• Account compromises from phishing, and for each one, which layer failed.

What goes wrong in production

• DMARC reject drops real mail. The invoicing system, the HR platform or a forgotten server sends as your domain and nobody listed it. Stay in monitoring until reports are clean, and keep watching them after enforcement.
• SPF quietly breaks. Someone adds one more include: for a new tool, the lookup count goes over the limit, and SPF fails everywhere. Check the record in CI or with a scheduled job.
• Strong MFA, weak recovery. The help desk resets MFA for a caller who sounds right, and the attacker enrolls their own key. Make recovery for privileged users require identity verification that cannot be done by voice alone.
• Break-glass accounts become the soft spot. Emergency admin accounts excluded from conditional access are exactly what an attacker wants. Use hardware keys on them and alert on every sign-in.
• Simulation allowlists become a bypass. Filtering exceptions created for the simulation vendor match on something an attacker can reproduce. Scope them tightly and review them.
• The report mailbox is a black hole. Reports pile up unread, staff notice, and reporting stops. Automate triage of reported messages and respond to every reporter.
• Password reset, session survives. The response resets the password and closes the ticket while the attacker's session keeps working. Session revocation is step one, not an afterthought.

Frequently Asked Questions

What is the most effective defense against phishing?

Phishing-resistant MFA, meaning FIDO2 security keys or passkeys, is the single most effective control, because a credential bound to the real website cannot be relayed through a fake one. Combine it with DMARC enforcement on your domains, inbound filtering, out-of-band checks for payment changes and a one-click way for staff to report suspicious messages. Training helps, but it should not be the control that everything depends on.

What are SPF, DKIM and DMARC?

SPF is a DNS record listing the servers allowed to send mail for your domain. DKIM adds a cryptographic signature to outgoing mail that receivers verify with a public key in DNS. DMARC tells receivers what to do when a message fails both checks in alignment with the visible From domain, and sends you reports about who is sending as you.

Does MFA stop phishing?

It depends on the type. One-time codes and push approvals stop attackers who only have a password, but adversary-in-the-middle phishing pages relay the code in real time and steal the session cookie that results. FIDO2 security keys and passkeys resist this because the browser only releases the credential to the genuine domain. Use them at least for administrators, finance and anyone with access to production.

How do I stop someone spoofing my email domain?

Publish SPF and DKIM for every legitimate sender, then a DMARC record, starting at p=none to collect reports. Fix the legitimate services that fail alignment, then move to p=quarantine and finally p=reject. Protect domains that send no mail with an SPF record of v=spf1 -all, a DMARC reject policy and a null MX record.

What should you do if an employee clicks a phishing link?

Thank them for reporting, then treat the account as compromised if they entered credentials or approved a prompt. Revoke all sessions and refresh tokens, reset the password, remove any MFA methods or mailbox rules the attacker added, review OAuth app grants and sign-in logs, and purge the same message from every other mailbox. Speed matters more than blame.

Do phishing simulations work?

They help when they measure and reward reporting, give immediate and respectful feedback, and run alongside technical controls. They backfire when they are used to shame people or when the lures are cruel, such as fake bonus or layoff notices, because staff stop trusting internal communications and stop reporting. Track report rate and time to first report rather than click rate alone.

Need help hardening against phishing?

We set up the controls that make a successful phish boring: DMARC at enforcement without losing real mail, phishing-resistant MFA rolled out without a help desk meltdown, and the logging and response steps for the day someone clicks anyway. Senior engineers do the work, and if we built it, we're on the pager for it.

• Cybersecurity and compliance
• Talk to an engineer