Researchers at email security company ZeroBEC have documented a campaign built on the Greatness phishing-as-a-service platform that spoofs RingCentral, the business communications provider, using fake voicemail and performance-review notifications as lures. The messages come from an unrelated IONOS mail server, fail SPF, fail DMARC, and carry no DKIM signature at all. By any authentication standard, they should be rejected outright. Instead, ZeroBEC found that the mail routinely lands in the inbox, because RingCentral is sitting on a safe sender allowlist at the receiving organization, and that entry overrides everything DMARC was set up to enforce.
The Attack in Plain Terms
The lure claims to be from [email protected], referencing a missed voicemail or a performance review, both plausible enough inside an organization that actually uses RingCentral to get a click without much hesitation. Clicking routes the victim into Greatness’s infrastructure, where the campaign branches into one of two paths: a Microsoft adversary-in-the-middle flow that intercepts an MFA-approved session token in real time, or a device-code phishing flow that talks the victim through approving a legitimate-looking Microsoft sign-in on the attacker’s behalf. Either path ends the same way, with a live, authenticated Microsoft 365 session in the attacker’s hands and no password ever exposed to steal.
Why This One Slips Past DMARC Specifically
None of that is new by itself. AiTM relay and device-code abuse have both shown up in other kits this year. What makes this campaign worth a closer look is the delivery mechanism, not the credential theft. A safe sender list is meant to reduce false positives for a trusted vendor’s genuine mail. It was never designed to distinguish between mail that actually originates from that vendor’s infrastructure and mail that merely claims to. Once an entry for ringcentral.com sits in an allowlist, most gateways stop applying DMARC enforcement, SPF checks, or DKIM validation to anything claiming that sender, full stop. The policy an organization published, and the policy its gateway is actually enforcing, quietly diverge, and nobody gets an alert when that happens.
The Blind Spot This Exposes
A DMARC record at p=reject is supposed to mean exactly what it says: mail that fails alignment does not reach the inbox. This campaign shows that guarantee only holds as far as an organization’s own mail gateway configuration lets it. Every safe sender entry, every allowlisted domain, every “always trust mail from this vendor” rule is a manually maintained exception to a policy that was otherwise doing its job. The more of a company’s vendor ecosystem gets waved through this way, RingCentral today, another SaaS tool tomorrow, the larger the gap grows between the DMARC posture an organization believes it has and the one actually protecting its inbox.
This is not an argument against safe sender lists, which serve a real purpose. It is an argument for auditing them the same way a domain owner audits DMARC aggregate reports: as a live inventory of exceptions, reviewed on a schedule, not a set-and-forget list built up over years of one-off support tickets.
What This Means for Your Program
Pull your organization’s safe sender and allowlist configuration and review it against your DMARC policy. Every entry is a place where enforcement stops applying, and most of these lists accumulate for years without anyone checking whether the exception is still justified.
Ask your mail gateway vendor exactly how allowlisting interacts with DMARC, SPF, and DKIM evaluation. Some platforms skip authentication checks entirely for allowlisted senders. Others still log the failure even while delivering the mail. That difference determines whether you have any visibility into abuse like this at all.
Train users on RingCentral, Zoom, DocuSign, and every other frequently spoofed SaaS brand specifically, not just phishing in general. Attackers pick these lures because they are common enough to be routine and specific enough to bypass hesitation, and because the underlying vendor is more likely to be sitting in an allowlist somewhere in the recipient’s organization.
Treat DMARC monitoring as an ongoing practice, not a one-time setup. Continuous visibility into who is actually sending on your behalf, and how your own infrastructure is being represented in the wild, is what turns a published policy into an enforced one.
The Takeaway
DMARC did exactly what it was built to do in this campaign: it correctly flagged the mail as failing alignment. The failure happened one step later, in a safe sender list that nobody had reason to revisit until researchers went looking. That gap between a correct verdict and an enforced outcome is where campaigns like this one live, and it will keep showing up anywhere authentication is treated as a box checked once rather than a control monitored continuously.
Excello Mail gives you continuous visibility into your DMARC enforcement and every source authorized to send under your domain, so a published policy and an enforced one never quietly drift apart. Sign up for free to Excello Mail and see exactly who is sending as you, all the time.