A staff member forwards a Drive share notification that led to a credential page, and the first thing an administrator checks is the authentication results. SPF: pass. DKIM: pass. DMARC: pass. For a moment that reads like a contradiction, or like a failure of the standards. It is neither. The standards did their job. They were asked a question this attack does not depend on.
The short answer
SPF, DKIM and DMARC authenticate the sending domain. Google's own summary: SPF "helps to prevent senders from impersonating you"; DKIM "prevents your message contents from being changed during transit"; DMARC "lets you choose what happens to messages that don't pass SPF or DKIM."
A Drive share notification is sent by Google. The From address is a google.com address, the message is signed by Google, and a pass is the correct result. Nothing was impersonated at the mail layer.
The malicious parts are not in the mail layer. The Google account that shared the file, the document, the link inside it and the page the link leads to are none of them examined by email authentication.
Set up SPF, DKIM and DMARC anyway. They stop the variant where someone puts your domain on a message your domain did not send. That is a different attack, and a common one.
What each one checks
Google's authentication overview describes the three in plain terms. SPF, Sender Policy Framework, "helps to prevent senders from impersonating you, blocking spammers and other attackers from sending email that appears to be from your organization." DKIM, DomainKeys Identified Mail, "prevents your message contents from being changed during transit" by signing the message so the receiver can verify it. DMARC, Domain-based Message Authentication, Reporting, and Conformance, is the policy layer: it "tells receiving email servers what action to take on messages sent from your domain that don't pass SPF or DKIM authentication. The action options are reject, quarantine, or deliver the message."
Every one of those sentences is about a domain, and the mechanics deserve one paragraph of precision. SPF checks whether the server that delivered the message is authorized to send for the domain in the envelope sender, the Return-Path address that mail servers exchange and recipients rarely see. DKIM checks whether the message carries a valid signature from a signing domain and arrived unaltered. DMARC then ties both to the address people do see. In Google's words, DMARC "passes or fails a message based on how closely the domain in the From: header matches the sending domain specified by either SPF or DKIM. This is called alignment," and "To pass DMARC, a message must pass at least one of these checks": "SPF authentication and SPF alignment" or "DKIM authentication and DKIM alignment." A receiving server applying them learns one thing with confidence: which domain is responsible for this message.
What a Drive notification authenticates as
When a Google account shares a file and Google sends the notification, the message is from Google's infrastructure. Published examples show more than one sending address, including drive-shares-dm-noreply@google.com and drive-shares-noreply@google.com; Google does not document them, but it does document the consequence, in its administrator guidance on Drive spam and phishing:
Because the email notifications come from Google, users might be tricked into thinking message contents are legitimate.
Run the checks against that message. SPF asks whether the sending server may send for the envelope-sender domain, which is Google's; it may. DKIM asks whether Google's signing domain signed it and it arrived intact; it did. DMARC asks whether the google.com in the From: header aligns with either of those; it does, so there is no failure for google.com's policy to act on. Pass, pass, pass, and every one of them is right. Google really did send it.
This is not a thought experiment. The Center for Internet Security documented an active campaign against state and local governments whose lures were delivered "as Google Drive share notifications originating from a legitimate Google mail server" and therefore "carry a valid Google Domain Key Identified Mail (DKIM) signature and pass sender policy framework (SPF) and Domain-based Message Authentication, Reporting and Conformance (DMARC) authentication checks." Valid signature, passing checks, malicious document.
Where the attack lives
Take the same message apart by identity and by layer.
| Element | Controlled by | Examined by SPF, DKIM or DMARC? |
|---|---|---|
| The sending domain and the message signature | Yes, and they pass | |
| The Google account that shared the file | The attacker | No |
| The document title, contents and the name on it | The attacker | No |
| The link inside the document | The attacker | No |
| The page the link leads to | The attacker | No |
Everything the attacker controls sits below the line that authentication examines. Authentication answered "who sent this message" and answered it correctly. The question the recipient needed answered was "who shared this file, and what does it want", and no mail header carries that answer. The three identities, mail sender, Drive sharer and impersonated person, are taken apart in Google Drive share phishing: why the email is real and the document is malicious.
What DMARC does protect you from
None of this is an argument against DMARC. It is an argument for knowing what it covers.
The classic school impersonation is a message with a From address at your own domain, sent by a server that is not yours, carrying the superintendent's name. That is precisely the case SPF, DKIM and DMARC were built for. Such a message fails SPF alignment, because your servers did not send it, and DKIM alignment, because your domain did not sign it; with a DMARC policy of reject, receiving servers that honor DMARC are instructed to reject it. Gmail additionally offers Protect against inbound emails spoofing your domain, described by Google as protecting "against potential Business Email Compromise (BEC) messages not authenticated with either SPF or DKIM, pretending to be from your domain." Gmail also marks mail that fails authentication entirely: Google notes that "unauthenticated emails display a question mark next to the sender's name."
Two of Google's own cautions belong here. Set up SPF and DKIM before DMARC, because "if you don't set up SPF and/or DKIM before enabling DMARC, messages sent from your domain will probably have delivery issues." And on alignment, Google's view is that "relaxed alignment typically provides sufficient spoofing protection", while strict alignment "can result in messages from associated subdomains to be rejected or sent to spam."
Do all of it. Then understand that a Drive share notification never fails any of it, because it is not pretending to be from your domain. It is honestly from Google's.
What works on the part authentication cannot see
The controls that reach the attacker's layer are the ones that act on content, on receiving and on people. A Gmail content compliance rule can match campaign-specific text in the notification's headers and body and quarantine it; the methodology is its own guide. Drive's allowlist and, on Education Standard and Plus, trust rules with a Receiving files trigger decide who can receive external shares at all; the trade-offs are in how to reduce Google Drive share phishing. And the one check that generalizes is a human one: look at the account that shared the file, not at the sender, and not at the name.
What not to conclude
Not that the standards failed. They authenticated the sending domain, which is all they claim to do, and they got it right.
Not that DMARC is optional. It blocks the direct spoofing of your domain that also carries your superintendent's name, and Gmail flags unauthenticated mail with a question mark in any case.
Not that "passes DMARC" is a safety signal for staff. It means the message is from whom the headers say. For a Drive notification, that is Google, and Google is not the attacker.
Not that blocking Google's sending address fixes the gap. It removes every legitimate Drive notification and leaves the shared document in place; why blocking the sender doesn't stop Drive share phishing covers it.
Sources
- About authentication methods — Google Workspace Admin Help. The descriptions of SPF, DKIM and DMARC quoted above.
- Set up DMARC — Google Workspace Admin Help. The definition of DMARC, alignment and the condition for passing, the order of setup, and the alignment guidance.
- Advanced phishing and malware protection — Google Workspace Admin Help. The domain-spoofing (BEC) setting and the question-mark indicator for unauthenticated mail.
- Help prevent Drive spam and phishing — Google Workspace Admin Help. Why notifications from Google mislead users.
- Google Drive: Legitimate Notifications/Malicious Files — Brown University OIT. One notification sender address, in a published example.
- Dual-RMM Phishing and PowerShell RAT Campaign Hits SLTTs — Center for Internet Security. An active campaign against U.S. state and local governments delivered "as Google Drive share notifications originating from a legitimate Google mail server (drive-shares-noreply@google[.]com)" that "carry a valid Google Domain Key Identified Mail (DKIM) signature and pass sender policy framework (SPF) and Domain-based Message Authentication, Reporting and Conformance (DMARC) authentication checks."
Related field guides
- Google Drive share phishing: why the email is real and the document is malicious
- How to reduce Google Drive share phishing in Google Workspace
- Why blocking the sender doesn't stop Google Drive share phishing
- K-12 impersonation phishing: why attackers pretend to be superintendents, HR and finance
Authentication tells you who sent the message, and that is where its job ends. When a genuine notification has carried a malicious document into two hundred inboxes, the job that remains is finding those inboxes and clearing them after review, which is what Message Removal in ORINEX Workspace Compliance does. What ORINEX Workspace does.