Phishing Defence for Small Businesses in Berlin: Technical Controls and User Training That Actually Work

Phishing is responsible for over 80% of initial access in SMB breaches. The attackers targeting Berlin small businesses are not sophisticated nation-state actors deploying zero-days — they are organised criminal groups running industrialised phishing campaigns at scale, targeting the predictable gaps in SMB security: no MFA, unconfigured email authentication, and users who cannot distinguish a spoofed sender from a real one.

This guide covers both the technical controls that remove entire attack categories and the user training that changes the probability of successful social engineering — because neither works in isolation.

Why Phishing Still Works Against SMBs in 2025

Three structural factors make small businesses disproportionately vulnerable to phishing:

Email domain reputation and authentication gaps. Most Berlin SMBs that came online before 2018 have partial or absent DMARC/DKIM/SPF configuration. This means their domain can be spoofed — an attacker can send email that appears to come from their CEO’s address to a supplier, or from a trusted vendor to their staff. Without DMARC enforcement (p=quarantine or p=reject), this category of attack remains open regardless of user training.

No MFA on business email. A successful phishing attack that captures a user’s Microsoft 365 credentials grants immediate access to email, SharePoint, Teams, and any connected SaaS applications — unless MFA is enforced. Without it, credential phishing has a 100% success rate post-click.

Users trained once, then never again. Security awareness training delivered as a one-hour annual video produces no durable change in user behaviour. Phishing simulation campaigns run quarterly — where users receive fake phishing emails and see immediate feedback when they click — produce measurably better outcomes because they create salient learning moments at the point of failure.

Layer 1: Email Authentication (Non-Negotiable Foundation)

Before any other phishing control, ensure your sending domain has correct SPF, DKIM, and DMARC records. These three DNS records form the technical foundation that prevents your domain from being spoofed and signals to receiving mail servers how to handle unauthenticated email.

SPF (Sender Policy Framework) lists the IP addresses and mail services authorised to send email from your domain. For a business using only Microsoft 365 for outbound email:

v=spf1 include:spf.protection.outlook.com -all

DKIM (DomainKeys Identified Mail) applies a cryptographic signature to outbound email that receiving servers can verify. Enable DKIM signing for your domain in the Microsoft 365 Defender portal under Email & Collaboration > Policies & Rules > Threat Policies > DKIM.

DMARC ties SPF and DKIM together and tells receiving servers what to do with email that fails both checks. A phased deployment approach: start with p=none (monitoring only) for 2–4 weeks to review the DMARC reports, then move to p=quarantine, then p=reject once you are confident all legitimate mail sources are covered.

Once you have p=reject deployed, email sent from your domain via an unauthenticated source will be rejected by receiving mail servers. This eliminates the category of attacks where an attacker impersonates your CEO to your finance team.

Layer 2: Microsoft Defender for Office 365 — Anti-Phishing Controls

M365 Business Premium includes Defender for Office 365 Plan 1, which provides several phishing-specific controls beyond the default Exchange Online Protection:

Anti-phishing policies. In Microsoft 365 Defender > Email & Collaboration > Policies & Rules > Threat Policies > Anti-phishing, configure: impersonation protection for your key users (CEO, CFO, HR manager), impersonation protection for your domain, mailbox intelligence (uses AI to model each user’s normal communication patterns and flag anomalies), and spoofing intelligence to review and classify who is spoofing your domain.

Safe Links. Rewrites URLs in email at click time — checking the destination against Microsoft’s threat intelligence before allowing access. This catches credential harvesting sites that appear clean at delivery time but go live after scanning. Enable Safe Links for all users and configure it to track user clicks (critical for incident response — you need to know who clicked what).

Safe Attachments. Detonates email attachments in a sandbox before delivery. Critical for document-delivered malware (malicious macros, PDF exploits, LNK files). Enable for all users with “Dynamic Delivery” to minimise delivery delay for legitimate attachments.

Layer 3: Conditional Access and MFA as a Phishing Kill Switch

Here is the operational reality: a user who clicks a phishing link and submits their Microsoft 365 credentials to a fake login page has been compromised — unless MFA is enforced. With MFA, the attacker has a harvested password that is useless without the second factor. Without MFA, they have immediate, unrestricted access to everything the user can access.

Enable MFA for all users. This is the single most effective phishing mitigation available, and it is included in your Microsoft 365 licence. Security Defaults (Entra ID > Properties > Manage Security Defaults) enables MFA for all users with a single toggle. For organisations with more complex requirements, deploy Conditional Access policies requiring MFA for all users on all cloud apps.

One important nuance: legacy authentication protocols — SMTP AUTH, IMAP, POP3, Exchange ActiveSync for older clients — bypass MFA entirely. Blocking legacy authentication is mandatory for MFA to be effective as a phishing control. Security Defaults blocks legacy auth automatically. If you are using Conditional Access instead, create an explicit policy blocking all legacy authentication protocols.

Layer 4: User Training That Changes Behaviour

Technical controls handle the automated threat categories. But sophisticated spear-phishing — targeted emails that use personalised context, appear to come from known contacts, and request plausible actions — still requires human judgement to detect. Training is the mitigation.

Effective security awareness training for SMBs has three characteristics:

It is simulation-based, not lecture-based. Microsoft Attack Simulator (included in M365 Business Premium via Defender for Office 365) lets you run phishing simulations against your own staff — sending them realistic fake phishing emails and capturing who clicked, who submitted credentials, and who reported the email. Users who click are immediately enrolled in targeted training. This converts training from a passive compliance activity into an active behaviour-change mechanism.

It focuses on recognition patterns, not generic advice. “Don’t click suspicious links” is not actionable. Specific patterns are: verify wire transfer requests via phone before processing, regardless of email sender; check the actual reply-to address on any email requesting credentials (not the display name); treat any unexpected invoice or shipping notification as suspicious until verified. These are the specific social engineering patterns used in Berlin SMB attacks.

It is reinforced with short, frequent reminders. A 5-minute monthly security tip delivered via Teams or email — covering one specific, current threat — is more effective than an annual two-hour training module. Monthly phishing simulation campaigns maintain alertness without the awareness decay that occurs between annual training events.

Layer 5: Incident Response Readiness

Phishing defence is not just prevention — it is also detection and response. For every Berlin SMB, define in advance:

What a user should do when they suspect a phishing email. Report it using the Microsoft Report Message add-in (submit to Microsoft and your security team simultaneously). Do not forward it to colleagues asking “is this real?” — that propagates the threat. Do not click any links to verify the sender’s legitimacy.

What happens when a user clicks. Immediately change the compromised user’s Microsoft 365 password and revoke all active sessions in Entra ID (Users > [user] > Revoke sessions). Review the user’s Sent Items and Inbox rules for signs of post-compromise activity (forwarding rules to external addresses are a classic indicator). Check sign-in logs for authentication from unexpected IP addresses or locations.

Who handles the response. Designate a named person (owner or IT contact) responsible for executing the above steps. An incident response process that lives only in someone’s head — or worse, requires a conversation to figure out who is responsible — will add hours of dwell time to any breach.

Practical Phishing Defence Checklist for Berlin SMBs

• SPF record published with -all qualifier
• DKIM signing enabled for all sending domains in M365 Defender
• DMARC policy at p=quarantine or p=reject (not p=none)
• MFA enforced for all users (Security Defaults or Conditional Access)
• Legacy authentication protocols blocked
• Safe Links enabled for all users with URL click tracking
• Safe Attachments enabled with Dynamic Delivery
• Anti-phishing policy with key-user impersonation protection configured
• Phishing simulation campaign run in last 90 days
• Incident response process documented and tested

This checklist maps to what a basic NIS2 technical security measure implementation looks like for email security in a German SMB context. If you are unsure of your current status against this list, an independent IT security assessment will surface the gaps with remediation priorities.