Stop the threats your inbox quietly lets through.
AI-powered classification routes every message through multiple detection engines quarantining or releasing based on real intent, not just keywords.
A complete service, run by people.
Detect domain look-alikes, payload links, and impersonation in real time.
Classify message tone, urgency, and ask catching social engineering keywords miss.
Internal email scanning catches compromised accounts before they spread.
API-based no MX changes, no broken calendar invitations, no headaches.
One-click 'report phish' button with analyst feedback in minutes.
Targeted simulations based on the threats actually hitting your team.
Business email compromise targeting Canadian SMBs
Business email compromise (BEC) is the highest-dollar cybercrime category in Canada, consistently accounting for more financial loss than ransomware according to the Canadian Anti-Fraud Centre (CAFC). In its 2023 annual report, the CAFC recorded over CAD $90 million in reported BEC losses — a figure that significantly understates actual losses because only an estimated 5–10% of fraud incidents are ever reported. BEC is not a technical attack in the traditional sense: it exploits trust, process, and urgency rather than software vulnerabilities. This makes it largely invisible to perimeter firewalls and standard antivirus tools, and disproportionately damaging to organizations without dedicated security staff.
The primary BEC attack patterns targeting Canadian SMBs fall into four categories. CEO fraud involves an attacker impersonating a senior executive via a spoofed or lookalike domain to instruct an accounts-payable employee to initiate a wire transfer or change vendor banking details. Invoice fraud involves compromising or spoofing a supplier's email account to redirect a legitimate payment to an attacker-controlled account — often discovered only when the real supplier follows up on an overdue invoice. Payroll diversion involves impersonating an employee to redirect a direct deposit to an attacker's account. And credential phishing involves directing employees to fake M365 or Google Workspace login pages, harvesting credentials that then enable all three previous attack types from inside the organization's actual domain. Canadian businesses are specifically targeted because of high adoption of wire transfer payment practices in real estate, construction, and professional services — sectors that represent a large portion of Canadian SMBs.
Standard email security tools — Microsoft's Exchange Online Protection (EOP), Google's built-in spam filtering — rely heavily on known-bad sender reputation, attachment scanning, and URL filtering. These controls work reasonably well against commodity phishing at volume. They fail against BEC for a structural reason: BEC messages are typically short, contain no malicious links or attachments, originate from newly registered domains with no negative reputation, and are carefully written to mimic the authentic communication style of the impersonated sender. The defining characteristic of a BEC message — an unusual financial request that deviates from normal process — is a business logic signal, not a technical indicator. Detecting it requires understanding communication patterns, sender relationship graphs, and behavioral baselines, which is exactly what AI-powered email security tools are built to analyze.
AI-based email security platforms analyze every message against a behavioral model built from the organization's own communication history: who emails whom, what subjects are normal between specific senders and recipients, what domains are expected from specific vendors, and what request types are typical in a given thread context. A message from a CEO's lookalike domain (quantmtec.com instead of quantmtech.com) requesting an urgent wire transfer on a Friday afternoon triggers anomaly signals on multiple dimensions simultaneously — sender domain mismatch, unusual urgency language, financial request from an executive who has never made this type of request by email. These signals are invisible to rule-based filters but are highly discriminative in a machine-learned behavioral model. The result is detection of BEC attempts that would otherwise reach the recipient's inbox and result in a business decision — not a click on a link.
DMARC, DKIM, and SPF: what each one does and why all three matter
- SPF (Sender Policy Framework) — SPF is a DNS record that lists which mail servers are authorized to send email on behalf of your domain. When a receiving mail server gets a message claiming to be from your domain, it checks the sending server's IP address against your SPF record. A strict SPF policy ("~all" or "-all") instructs receiving servers to treat mail from unauthorized sources with suspicion or reject it outright. SPF stops basic spoofing of the envelope-from address but does not protect the visible From header in email clients — the header that users actually see.
- DKIM (DomainKeys Identified Mail) — DKIM adds a cryptographic signature to outgoing messages using a private key stored on your mail server. The corresponding public key is published in your DNS. Receiving servers verify the signature against the public key to confirm that the message body and headers have not been modified in transit and that the message originated from a server with access to your private signing key. DKIM protects message integrity and provides a verifiable link between the message and your domain — but alone, it does not tell receiving servers what to do with messages that fail the check.
- DMARC (Domain-based Message Authentication, Reporting & Conformance) — DMARC builds on SPF and DKIM by adding policy and reporting. A DMARC record tells receiving mail servers what action to take when a message fails SPF and DKIM alignment (none / quarantine / reject) and where to send aggregate and forensic reports about authentication results. A DMARC policy of "reject" is the goal: it instructs all receiving mail servers to block messages that claim to be from your domain but cannot pass SPF or DKIM verification. Without DMARC at enforcement, SPF and DKIM alone provide intelligence but no protection.
- What happens without SPF — Without SPF, any mail server on the internet can send email claiming to be from your domain with no technical barrier. Attackers use this to send phishing emails from your domain to your customers and partners, impersonate your CEO in BEC attacks against your own suppliers, and conduct credential phishing campaigns that appear to originate from your company's legitimate email address. Your domain reputation suffers regardless of whether the recipient reports the attack.
- What happens without DMARC at enforcement — Many organizations have SPF and DKIM configured but leave DMARC at policy "none" (monitoring-only mode) indefinitely. This is the worst of both worlds: you receive reports showing your domain is being actively spoofed, but you have taken no action to stop it. DMARC in monitoring mode with no path to enforcement provides no protection. It is a common configuration left in place because moving to "reject" policy requires validating that all legitimate sending sources are authenticated — a process that requires coordination across marketing tools, CRM platforms, and transactional email providers, but that takes hours, not weeks, for most SMBs.
- Cyber insurer and M365 licensing requirements — DMARC at enforcement (policy "quarantine" or "reject") is now a listed requirement in the application questionnaires for most Canadian cyber insurance carriers. Microsoft's Secure Score framework also flags the absence of DMARC enforcement as a high-priority finding. A domain without DMARC enforcement that is actively being spoofed for phishing attacks against third parties creates potential civil liability in addition to the direct damage to your domain reputation — recipients of fraudulent mail purportedly from your domain have recourse against you if the attack could have been prevented by standard authentication controls.
Email security obligations under PIPEDA
PIPEDA's mandatory breach reporting regulations (SOR/2018-64) require organizations to report to the OPC and notify affected individuals whenever a security incident involving personal information creates a real risk of significant harm. Email incidents — whether a phishing attack that resulted in credential compromise, a BEC attack that exposed customer financial details, or an email thread containing personal health information that was forwarded to an unauthorized recipient — are among the most common triggers for mandatory PIPEDA breach notification. The OPC's own statistics consistently show that email is the leading initial access vector in reported privacy breaches involving Canadian organizations.
The OPC does not set a statutory 72-hour notification window the way GDPR does, but the organization has published guidance indicating that notification should be made "as soon as feasible" and that unreasonable delay in notifying affected individuals will be a negative factor in any subsequent investigation. In practice, the 72-hour benchmark used by most Canadian privacy counsel is derived from the GDPR standard, which has become the de facto Canadian expectation through regulatory convergence and the influence of Quebec's Law 25, which does set explicit timelines. For organizations subject to both PIPEDA and Law 25 — any company doing business with Quebec residents — the 72-hour window to notify the Commission d'accès à l'information is statutory.
When a BEC attack or email-based credential compromise triggers PIPEDA reporting obligations, the notification to the OPC must include specific content: a description of the circumstances of the breach, the date or period of the breach, a description of the personal information involved, the number of individuals affected, a description of the steps taken to reduce the risk of harm, and contact information for a person who can answer questions on behalf of the organization. Organizations that have no email security logging — no record of what messages were received, which accounts were accessed following a phishing event, and what data those accounts contained — cannot produce this notification with the specificity the OPC requires. AI-powered email security platforms that log every threat detection event, every quarantine action, and every account anomaly serve as the primary evidence base for PIPEDA breach notifications following email-based incidents.
What changes after week one.
You'll feel the difference fast fewer alerts, faster response, and a clearer picture of where your real risk lives.
- Cut phishing dwell time from hours to under a minute
- Stop wire-transfer fraud and invoice redirection attempts
- Detect compromised accounts before they email your customers
- Reduce IT helpdesk 'is this email safe?' tickets by 80%
- Give your team confidence in every message in their inbox
From kickoff to coverage in days.
API integration with M365 or Workspace live in under an hour.
We baseline your normal communication patterns over 7 days.
Block, quarantine, or banner messages based on real risk.
Targeted simulations and reporting close the human gap.
Common questions, answered.
The things buyers ask us most about scope, onboarding, and what you'll see in your monthly report.
Ask us anythingMake your inbox the safest place to work.
Run a 14-day shadow analysis on your live mail flow. See exactly what your current filter is missing.