What makes a threat and what statistics actually measure
A suspicious message often combines several elements: a claimed identity, a time-pressured pretext and a requested action. That action might be disclosing credentials, making a payment, opening a file or carrying out supposed repair steps. The topics overlap; the eleven mechanisms described here do not form a statistical classification of eleven mutually exclusive attack types.
The ENISA Threat Landscape 2026, published in September 2026, covers incidents from 1 January to 31 December 2025. ENISA analysed 8,257 incidents, mainly from open sources supplemented by voluntarily shared information. The report explicitly states that this is not a complete picture of the threat landscape; the period also overlaps the previous edition by six months. ENISA, methodology, p. 9
In Figure 1, phishing accounts for 77.8% and malspam for 13% of the social engineering techniques identified in the dataset examined. This means neither “77.8% of all cyberattacks start by email” nor “77.8% of all messages are phishing”. Different sources count incidents, complaints, websites, messages or reported losses; these measures cannot simply be compared. ENISA, p. 11, Figure 1
Good writing is not an all-clear signal. AI can assist deception, but this establishes neither an AI share measured here nor a causal relationship proven by an annual statistic alone. Actual reports, account findings and working practices are more informative for your organisation than a blanket worldwide success rate.
Four sender cases with different consequences
On narrow screens, scroll the table sideways.
| Case | Example | DMARC's contribution |
|---|---|---|
| Exact third-party domain forged in From | Attacker uses rechnung@example.com without appropriate authorisation | Aligned authentication may be absent; policy can request special treatment |
| Only the display name is imitated | “Example Accounts” with an address under example.net | A pass for example.net does not confirm the organisation claimed |
| A lookalike domain is used | A similarly spelt domain controlled by the attacker | May be fully and correctly authenticated for itself |
| Real account or sending service compromised | Misuse of an authorised account under example.com | Messages may pass with alignment; account protection and content/process checks are needed |
DMARC concerns the domain in the visible From address and its aligned authentication. It is not a general assessment of a person, content or authority for a particular business decision. RFC 9989, sections 1, 2.2 and 11.4
Schematic explanation · not a measurement
Four sender cases: a pass never proves harmlessness
Four parallel routes reach the same recipient at example.org. Display name, exact domain and control of the account are highlighted separately.
1 · Exact domain forged
- From: example.com
No matching SPF/DKIM path.
-
Verification and alignment
DMARC failure possibleThe recipient decides how to treat the message.
2 · Display name feigns familiarity
- “Example Accounts” · example.net
The familiar name belongs to a different technical domain.
-
The check concerns the domain used
DMARC pass possibleThis does not rule out fraud.
3 · Lookalike domain
- examp1e.example
The spelling resembles the expected domain, but it is different.
-
An attacker can authenticate their own domain
DMARC pass possibleDMARC does not prohibit similarly spelt domains.
4 · Authorised account compromised
- Real account · example.com
The attacker has access to the authorised sending route.
-
Technically authorised sending
DMARC pass possibleA fraudulent payment request can be correctly authenticated.
All four routes need content and operational assessment. No line means “harmless”.
Complete description of the flow
Four parallel message routes reach the same recipient at example.org. The first claims example.com without a matching SPF/DKIM path and ends at “DMARC failure possible; recipient decides”. The second uses the name “Example Accounts” but the domain example.net; the third uses the lookalike example domain examp1e.example; the fourth comes from a compromised authorised account under example.com. Each of the last three routes states “DMARC pass possible; this does not rule out fraud”. The visual emphasis distinguishes display name, exact domain and account control. No green line means “harmless”.
Understand attack mechanisms
Senders and accounts
On narrow screens, scroll the table sideways.
| Topic | What happens | What particularly helps |
|---|---|---|
| Email spoofing | Visible sender details are forged; direct domain forgery and display name deception differ | SPF/DKIM/DMARC for your domain, trusted receiving checks and careful identity verification |
| Phishing | A targeted or broadly distributed message induces disclosure of data or a dangerous action | Access the service independently, use suitable authentication, check content and links, and provide a reporting route |
| Business Email Compromise | A business identity is misused for payment or data fraud; an account need not have been compromised in every case | Payment approvals, independent callback and account protection; an attachment is not required |
| Vendor Email Compromise | A supplier's identity or real account is misused, for example to announce changed bank details | Confirm the change through an existing known contact and separate approval; a genuine conversation history is not reliable confirmation |
Content and delivery forms
On narrow screens, scroll the table sideways.
| Topic | What happens | What particularly helps |
|---|---|---|
| Quishing | A QR code leads to a deceptive destination, often on another device | Open the destination independently, assess filters' actual QR capabilities and protect the device used |
| Dangerous attachments | Files, scripts or shortcuts entice the recipient to open or run them, or exploit software flaws | Updates, file rules, suitable analysis or sandboxing and endpoint protection; do not run files merely because a message asks you to |
| HTML smuggling | Browser features assemble a file from encoded components | Browser and endpoint controls, plus behavioural analysis; distinguish downloading from actual execution |
| SVG attacks | Depending on its use, SVG can contain links, scripts or other active elements | Check the file context, use restricted processing and filters; an image format alone does not mean harmless content |
| Calendar invitations | Invitations or events contain deceptive links or instructions and, depending on settings, may appear before confirmation | Check invitation settings, origin and content; visibility in the calendar proves neither acceptance nor trustworthiness |
Domains and infrastructure
On narrow screens, scroll the table sideways.
| Topic | What happens | What particularly helps |
|---|---|---|
| Homograph and IDN attacks | Different characters or names look similar; rendering depends on software and fonts | Use known bookmarks or type the address yourself, check the domain carefully and use phishing-resistant authentication |
| Echospoofing and SubdoMailing | Different mechanisms: misused relay permissions or abandoned DNS/sending dependencies | Check relay and tenant binding, remove orphaned CNAME/NS/SPF references, and control accounts and legitimate authorisation |
These short descriptions explain mechanisms, not a frequency ranking or guaranteed detection criteria. Aligned authenticated mail is possible in several of these cases. The technical foundations are in DMARC, DNS security and ARC and gateways.
ATT&CK describes actions
Appropriate ATT&CK techniques can support security teams' documentation. Classification must follow observed behaviour, not just a label attached to a message. In the checked Enterprise dataset 19.2, examples include email header spoofing under T1684.002, spearphishing attachments under T1566.001, HTML smuggling under T1027.006 and compromised domains under T1584.001. QR links used to collect sensitive information are described under T1598.003; not every QR code is automatically this particular attack step. MITRE ATT&CK, versioned source data
The catalogue establishes neither a success rate nor a guarantee that a particular product detects an attack. No separate technique number is invented here for calendar invitations.
Protective measures and their limits
On narrow screens, scroll the table sideways.
| Risk | Technical contribution | Also needed |
|---|---|---|
| Direct unauthorised use of the From domain | SPF and DKIM plus DMARC alignment and policy | Fully configure legitimate sending routes, analyse reports and account for recipient decisions |
| Deceptive display name or another similar domain | Receiving filters can detect impersonation | Independently confirm the specific identity and business instruction |
| Compromised real account | Strong authentication, session/access controls and detection of unusual use | Check endpoints, recovery, permissions and forwarding rules |
| Harmful link, QR code or attachment | Suitable content, URL and file checks, plus endpoint protection | Users must be able to stop and report unexpected actions |
| Manipulated DNS response or SMTP transport | DNSSEC, DANE and MTA-STS, depending on the path and support | Actual validation, server state and controlled operation |
| Orphaned genuine DNS authorisation | DNS/service inventory and controlled decommissioning | DNSSEC alone also signs the reference left behind |
| Payment diversion | Filters may provide indications | Independent callback and a defined approval process for changes to bank details |
SPF, DKIM and DMARC passes do not protect against malicious content from an authorised sending route. TLS protects a connection even when it carries a dangerous message. RFC 9989, sections 1 and 11, RFC 4033, section 4
Account protection and reliable workflows
Payments and changes to stored business details should use a known contact route obtained independently. A telephone number in the suspicious message does not meet that requirement. Staff need an accessible reporting route and permission to stop when something is unclear, even if a message claims to come from management.
Use strong authentication that is resistant to phishing where possible, such as suitable passkeys. An additional factor alone does not prevent all phishing: ENISA describes AiTM phishing and theft of session cookies, among other techniques. Also check active sessions, recovery routes, authorised applications and the endpoint. ENISA 2026, pp. 55–56, Google: binding passkeys to a website or app
Unknown forwarding rules or rules that hide messages can keep a compromised account useful for fraud. Organisations should also include administrator rights, relay permissions, new sending services and orphaned DNS references in operational checks. Planned testing and training must fit your own data flows; a general DNS score does not measure them. The Microsoft guide to recovering compromised accounts gives concrete examples of session revocation, application permissions and forwarding rules; implementation at other services depends on their features.
What to do when you suspect a specific incident
- Stop: Do not follow links, attachments or QR instructions, approve additional permissions or call back through the suspicious message.
- Check independently: Reach the claimed sender through a known contact or open the service using an address you obtain independently.
- Report and preserve the original: Inform the designated IT or security contact. Preserve the message and times while retaining headers; do not indiscriminately copy sensitive content into external checking services.
- After entering data or granting permission: Contact the real service from a trusted device, check credentials and recovery, end affected sessions or grants, and investigate unknown rules. A password change alone does not necessarily terminate every existing session.
- After running a file: Immediately involve the IT or security team and follow its incident procedure; do not alter evidence or systems through further experimentation.
- If a payment has been initiated: Contact your bank immediately through a known route and report the suspected fraud. Coordinate further evidence preservation and, where appropriate, reporting to law enforcement with the responsible parties.
The specific response depends on what actually happened. A DMARC failure alone proves neither a successful attack nor a reportable incident. Legal duties, recipients and deadlines depend on the facts and scope; see compliance and documentation.
How a domain check can help assess these risks
The Email Security Check provides a snapshot of published DNS data and limited SMTP features. It does not examine received messages, QR codes, accounts, attachments or fraudulent payment requests. Even an identified gateway name does not prove an active licence, filter configuration or effectiveness.
Use the results to check your domain configuration. A specific incident needs additional message, account and operational data. Neither an absent scan finding nor a high score gives the all-clear for the mechanisms discussed here. The check scope states its limits; the introduction explains the layers of protection.
Frequently asked questions
Is a message safe if SPF, DKIM and DMARC pass?
No. These checks can confirm an authorised domain relationship. Misuse of a real account or dangerous content remains possible.
Does BEC always involve account takeover?
No. Business identities can also be impersonated. Where an account has actually been taken over, technical authentication and conversation history may add credibility.
Does a QR code make a message dangerous?
Not by itself. The destination and requested action matter. A QR code may move the interaction to another device, whose protections then become relevant.
Does DMARC prevent lookalike domains?
No. A different domain can be correctly authenticated for itself. Your domain's DMARC does not prevent its use.
Which statistic should our organisation rely on?
No general percentage replaces your own risk assessment. Read the period, region, population and selection method, then add your own operational findings.
Must every suspicious incoming message be reported externally?
A suspicious incoming message alone creates no blanket external reporting duty. Report internally and establish the facts; check applicable duties through the responsible team.
Does a BIMI logo prove that a payment request is correct?
No. Logo display and payment authorisation are separate questions. Always confirm new bank details through the designated independent approval route.
Read sources in context
Sources checked: 27 September 2026. ENISA Threat Landscape 2026 describes a limited dataset and its methodology; MITRE ATT&CK catalogues observed techniques; the linked RFCs define technical mechanisms. None of these sources guarantees freedom from errors or the effectiveness of a particular installation.
Official BSI guidance on email security adds behavioural advice. Vendor reports and complaint statistics each need their own context; figures for Germany, Austria and Switzerland need suitable regional data; correlation over time alone does not prove causation.
Next steps: DMARC enforcement, ARC and gateways, DNS hygiene, alias strategy and interpreting header findings.