Someone at your company gets a call on their personal mobile. Not the office line, the number they gave HR on day one. The screen shows your IT helpdesk's actual number, the same one that's saved in their contacts from a call last year about a password reset. The voice on the other end sounds rushed but professional. There's a problem with multi-factor authentication, something about a security policy rollout, and they need the employee to re-enrol their passkey right now, before the end of the day. A link goes over. The employee, trying to be helpful, clicks it.
That is not a hypothetical. It's the attack Google's Threat Intelligence Group described in a report published on 6 August 2026, tracking a group it calls UNC6671, which has rebranded several times but keeps running the same playbook against financial services, private equity and professional services firms, as The Hacker News reported the same week. The detail that should stop you is the spoofed number. The employee didn't fall for a fake caller ID with a strange area code or a robotic voice. They answered a call from what looked, by every available signal, like their own company's helpdesk.
Why did the call look real when nothing about it was?
Because caller ID was never built to be trusted in the first place. It's a label the calling system sends along with the call, and nothing on the network checks whether the number matches who's actually dialling. Spoofing it costs an attacker almost nothing. The prize is a stolen multi-factor session, harvested through what's called an adversary-in-the-middle phishing page, a fake login screen that sits between the employee and the real service and passes credentials and one-time codes straight through in real time. Once that session is live, the attacker is inside Microsoft 365 or whatever cloud platform the business runs on, no malware required.
There's a telecoms standard called STIR/SHAKEN that's meant to attach a verified signature to outgoing calls, the phone equivalent of DKIM, which the FCC required major US carriers to implement in their networks by 30 June 2021. It helps against the crudest robocall spam, but it does nothing against a group like UNC6671, because the standard only vouches for which carrier originated the call, not for whether the person dialling actually works where they claim to. A call can pass every check the network runs and still be a stranger reading a script. That gap is exactly why Google's own advice for this attack is behavioural rather than technical, there is currently no DNS-style record you can publish for a phone number the way you can for a domain.
Notice, too, why attackers bothered building a phone-based attack at all. Email filtering and phishing-resistant MFA have both genuinely improved over the past two years, so the crudest version of this scam, a spoofed email with a link, gets caught more often than it used to. Vishing is the workaround, a channel with far weaker built-in verification than either email or the login page itself. The lesson is not "the phone is now the dangerous channel and email is fine." It's that attackers go wherever the weakest verification is, and right now that's split across both.
What you actually want, underneath the fear of that scenario, is simple: a way to know that a message asking for something sensitive really came from who it says it came from. Not "looks plausible." Actually verified. That want applies just as much to the inbox as it does to the phone.
Your inbox has the same weak spot, except it's easier to fix
An email's "From" address works exactly like caller ID. It's a field the sender fills in, and by default nothing forces it to be true. Anyone can type your domain into that field and send a message that lands in a customer's or supplier's inbox looking, at a glance, exactly like it came from you. I wrote about the mechanics of that specific scam, someone sending an invoice that looks like it came from your business, in how a fraudster sends an invoice that looks like it came from you.
Here is the part that actually matters for you this week. Unlike the phone network, email has a working answer to this problem, and it has existed for years. Three DNS records, SPF, DKIM and DMARC, let a receiving mail server check whether a message claiming to be from your domain was actually sent by a server you authorised, and whether its contents were tampered with in transit. I go through what each one does on its own in SPF, DKIM and DMARC explained without the jargon, but the short version is this: SPF is a published list of which mail servers are allowed to send as you, so a receiving server can check whether the message arrived from one of them. DKIM attaches a cryptographic signature to each message, so if even a single character is altered in transit the signature breaks and the message fails the check. DMARC is the instruction layer sitting on top of both, telling a receiving server what to actually do when a message fails SPF or DKIM, and quietly sending you a daily report naming every server on earth that tried to send mail using your domain that day, whether it succeeded or not.
Business email compromise, the umbrella term for exactly this kind of spoofed invoice or spoofed request, is not a rounding error. The FBI's Internet Crime Complaint Center recorded $2.77 billion in reported BEC losses across 21,442 incidents in the United States in 2024 (source: 2024 IC3 Annual Report, FBI).
The catch is that a DMARC record on its own doesn't do anything if it's set to p=none, which is the default most domain registrars and hosting panels leave in place. That setting monitors and reports on spoofing attempts without blocking a single one of them. I covered exactly why that's true, and what changing it actually involves, in what p=none really means and why it protects nobody. The uncomfortable fact is that most businesses never move past it. Monitoring 1,276,088 domains worldwide in July 2026, DmarcDkim found that 68.7% had no effective DMARC protection in place at all, meaning either no record, or a record too weak to stop anything (source: DmarcDkim, July 2026).
Why the helpdesk story matters even if you're not a hedge fund
UNC6671's targets so far skew large, financial services and enterprise cloud environments, and it's tempting to read that and assume the lesson doesn't apply to a business with twelve staff and no dedicated security team. That's backwards. Smaller businesses are the ones least likely to have a procedure for verifying an unusual request through a second channel, and least likely to have moved their own domain's DMARC record past p=none. The attackers who invest in building convincing spoofed calls for a hedge fund are not going to bother doing the same for a plumbing supplier in Lekki or a design studio in Austin. But the much larger, much lazier population of scammers sending spoofed invoice emails absolutely will, because the spoofing itself takes seconds and costs nothing, and they only need it to work once in a thousand tries.
Think about what a spoofed invoice actually costs a small business compared to what it costs the attacker to send one. A supplier who invoices a handful of clients a month has, at most, a few dozen genuine payment requests going out in any given week. An attacker spoofing that supplier's domain can send a thousand near-identical fake invoices in an afternoon, to the supplier's own client list scraped off a website or a leaked spreadsheet, and only needs one accounts payable clerk to pay the wrong bank details once. The business bears the reputational cost of every one of those thousand emails whether or not any of them actually get paid, because the client who nearly got caught out remembers whose name was on the message. That asymmetry, cheap to send, expensive to be the victim of even when the fraud fails, is the entire reason this keeps happening to businesses that never see themselves as a target.
I'd push back a little on the standard advice here, which usually stops at "train your staff to spot phishing." Training helps, but it puts the entire weight of defence on a tired employee's judgement in the middle of a normal working day, against messages specifically engineered to look unremarkable. The DMARC fix doesn't ask anything of your staff. It sits in DNS, checked automatically by every major mail provider, on every single message, forever, without anyone having to notice anything was wrong in the moment. That's a better trade than most security advice you'll read this year.
What actually verifying a request looks like, on the phone and in the inbox
For calls, the fix Google's own report recommends is procedural rather than technical, because the phone network genuinely can't verify caller ID the way DNS can verify a sending server. If a call asks for a password reset, an MFA re-enrolment, a wire transfer or anything touching money or access, hang up and call back on a number you already had saved, not one read out during the call, not one texted to you moments before. That single habit defeats almost the entire UNC6671 playbook, because the attacker loses control of the channel the moment you dial out yourself.
For email, the equivalent habit exists too, glancing at the sender before acting on urgency, but it shouldn't be the only line of defence, because a well-forged message won't show any obvious tell. The technical fix is checking your own domain's current SPF, DKIM and DMARC records, not your staff's inbox training. Most business owners have never looked. If you haven't, that's the actual first step, not a training session, not a new policy document. A domain sending mail through Google Workspace or Microsoft 365 with no DMARC record, or one still sitting at p=none, is currently trusting that nobody has bothered to spoof it yet. Given how cheap spoofing is, that's not a bet worth making twice.
There's a version of this that applies inside your own team too, not just to outside attackers. If a colleague emails asking you to change a bank account on file, approve an unusual payment or reset an account, and the request has any urgency to it at all, pick up the phone and call them on a number you already had, the same rule as the helpdesk call. It costs thirty seconds and it closes off both attack paths at once, because a spoofed email that would have sailed through a weak DMARC record still can't fake a voice you already know on a line you already trust.
Frequently asked questions
Can DMARC stop a phone-based vishing attack like the one Google described? No. DMARC only governs email. It can't verify a phone call or a caller ID, which is why the defence against vishing is procedural, always verify unusual requests through a channel you initiated yourself, not the one the attacker used to contact you.
If SPF and DKIM already exist, why does DMARC matter on top of them? SPF and DKIM tell a receiving server whether a message passed certain technical checks, but on their own they don't tell that server what to do with a message that fails. DMARC is the instruction, quarantine it, reject it outright, or do nothing and just report on it, which is what makes p=none so misleading as a default.
How long does it actually take to move a domain from p=none to enforcement? Properly, it's a staged process over several weeks: publish DMARC in monitoring mode, read the reports it generates to confirm every legitimate sending source is accounted for, then move the policy to quarantine and finally reject once you're confident nothing legitimate will be blocked. Rushing straight to reject without reading the reports first is how businesses accidentally block their own invoices.
Is a helpdesk phone call really the same risk category as a spoofed email? They're the same underlying failure, a system that displays a label without verifying it, but email is the far bigger exposure for most small businesses, simply because sending a spoofed email costs an attacker nothing and can be done at any scale, while a convincing spoofed call takes real effort to research and execute.
We use Google Workspace. Doesn't that already protect us? Google's spam and phishing filters protect what lands in your own inbox, but they do nothing to stop someone else spoofing your domain to attack your customers or suppliers. That protection lives entirely in your own domain's SPF, DKIM and DMARC records, which you have to set up regardless of which mail provider you use.
Does a small business really need to worry about a group like UNC6671 by name? No, and that's not really the point of the story. The specific group will rebrand again, as it already has more than once. What's worth taking from it is the pattern, verified-looking labels that were never actually verified, and that pattern shows up in cheap, mass-produced scams aimed at small businesses just as much as in the targeted attacks aimed at hedge funds.
If you want to know where your own domain actually stands rather than guess, run it through the free check on this site. It reads your current SPF, DKIM and DMARC records in seconds and tells you plainly whether your domain is one of the roughly two thirds currently sitting unprotected, or one of the smaller number that's actually locked down.