TL;DR: Real domains such as scoutcamp.bounces.google.com, forms.cloud.microsoft and sendgrid.net can still deliver phishing when attackers abuse trusted platforms, according to IRONSCALES, because SPF, DKIM and DMARC prove infrastructure ownership, not message intent. The decisive control is behavioural context: who sent it, what account generated it and whether the request matches an expected relationship.
At a glance
What this is: This is a teardown of legitimate email domains that attackers abuse to make phishing look authentic, with the key finding that authentication alone does not prove trust.
Why it matters: IAM and security teams need to govern sender context, reply paths and account provenance, because platform-level legitimacy can hide attacker-controlled identities behind clean mail authentication.
Context
Real email domains do not guarantee trusted communication. In this case, the security gap is not domain ownership but sender intent and account provenance, which is where phishing through legitimate platforms succeeds. The identity problem sits behind the mailbox: a real sending service can still carry attacker-controlled content.
This matters to IAM and email security because SPF, DKIM and DMARC validate infrastructure, not the human or account relationship behind the message. When notification platforms, form builders, link wrappers and document-sharing services are abused, the real control point becomes who created the artefact, who can reply to it and whether the request matches an expected business relationship.
Key questions
Q: What fails when phishing uses a legitimate platform domain?
A: The failure is not domain authentication. The failure is trust assignment based on infrastructure ownership alone, because a real platform can still carry attacker-controlled content, reply paths and workflows. Defenders need to evaluate the account behind the message, the expected relationship and the action requested, not just the fact that the domain is legitimate.
Q: Why do legitimate platform emails still create security risk?
A: Because the sender service can be real while the actor using it is not. Attackers exploit notification, form, document-sharing and signature workflows to inherit reputation from trusted domains, which makes the mail pass common checks and often bypass user suspicion. The risk is identity abuse through an authorised service, not classic spoofing.
Q: What are the signs that a trusted email service is being abused?
A: Look for a reply destination that does not match the sender, a first-time relationship with the purported sender, a request that does not fit the normal workflow, and a link that asks for sign-in or data entry when the business context does not justify it. Those behavioural mismatches matter more than domain reputation.
Q: Should organisations allow-list trusted platform domains?
A: Only with extreme caution. A broad allow-list for major platforms such as Google, Microsoft, Adobe or SendGrid removes inspection from the same channels attackers most want to use. If an exception is unavoidable, scope it to a specific sender or workflow, keep authentication requirements in place, and continue behavioural analysis on allowed mail.
Technical breakdown
Why SPF, DKIM and DMARC still let abuse through
SPF confirms that a sending server is authorised for a domain, DKIM confirms the message was not altered after signing, and DMARC checks alignment between the signing domain and the From header. None of those checks verify whether the account behind the notification is legitimate or whether the content is expected. That is why a platform can send malicious mail perfectly well if an attacker creates, compromises or misuses an account on that platform. The authentication stack can be correct while the trust decision is wrong.
Practical implication: Treat mail authentication as necessary but insufficient, and add sender-behaviour inspection before trusting a message.
How trusted platforms become phishing infrastructure
Legitimate services become delivery vehicles when an attacker uses a normal platform function such as creating a form, sharing a file, requesting a signature or publishing an event. The message inherits the platform's reputation, so scanners see authentic infrastructure, real links and valid signatures. The abuse pattern is not domain spoofing in the classic sense. It is identity abuse through the service account or customer account that loaded the platform. That shift matters because the defensive question is no longer just whether the domain is trusted, but whether the actor using it is expected.
Practical implication: Verify the sending account and business relationship, not just the platform domain, before allowing action on the email.
Why link wrappers and allow-lists create false confidence
Link protection hosts and allow-lists can reduce noise, but they also normalise trust in the wrapper rather than the underlying request. A wrapped link can still point to a phishing destination, and a platform domain can still be abused through a real account. Allow-listing an entire trusted service removes one of the few checks that might have detected an unusual sender, request type or reply path. This is especially risky when the service is widely used across the business and attackers can blend into routine notifications.
Practical implication: Scope allow-lists narrowly and keep behavioural analysis active on any trusted platform mail that gets through.
Threat narrative
Attacker objective: The attacker wants victims to trust and act on phishing messages that appear to come from a legitimate service, so the platform's reputation carries the lure to completion.
- Entry occurs when an attacker uses a legitimate platform account or creates one on a trusted service such as Google Search Console, Microsoft Forms, Adobe Acrobat or Dropbox Sign.
- Credential or trust abuse follows as the platform sends mail with valid authentication, clean links and an apparently reputable sender identity.
- Impact comes when the recipient signs in, submits data or approves a request that the attacker controlled through that platform account.
Breaches seen in the wild
- Gemini AI Breach — Google Calendar Prompt Injection: Gemini AI assistant prompt injection attack leaks sensitive Google Calendar data.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Legitimate-domain phishing is really an identity abuse problem, not a DNS problem. The article shows that real infrastructure can deliver malicious requests when an attacker controls the account behind it. That means email trust should be judged at the account, reply-path and relationship layer, not at the domain layer. Practitioners should treat sender identity as the control boundary.
Authentication proves origin, not intent. SPF, DKIM and DMARC answer whether the platform's infrastructure sent the mail, but they do not answer whether the message was expected, appropriate or authorised by the business relationship. That is why platform abuse keeps working even when all mail checks pass. The governance gap is a trust decision being made from infrastructure evidence alone, which is too narrow for modern phishing.
Allow-listing whole platforms creates a standing exception that attackers can ride through. When users are told to trust Adobe, Google, Microsoft, Dropbox or SendGrid mail by default, defenders exempt the very channels that attackers can abuse most easily. The better model is conditional trust tied to known senders, expected workflows and behavioural signals. Security teams should assume that trusted infrastructure can be weaponised at any time.
Platform abuse collapses the boundary between email security and IAM. A form creator, file sharer or signature requester is effectively a non-human identity using a business platform to initiate a security-relevant action. That makes account provenance, lifecycle control and offboarding relevant even in an email-phishing discussion. Practitioners should govern the platform account as carefully as the inbox.
Reply-To is a critical trust signal that too many teams ignore. Several examples in the article were only obvious once the reply destination was inspected. That is a practical reminder that the visible sender and the real conversation endpoint are often different. Teams should use reply-path scrutiny as a standard triage step, especially for notifications that ask for sign-in or data entry.
What this signals
Behavioural trust now matters more than sender reputation. Email controls that stop at SPF, DKIM, DMARC and domain allow-lists are no longer enough when attackers can rent legitimacy from a real platform. Security teams should shift triage to context: who created the message, who receives the reply and whether the action fits the established relationship.
Trusted-platform abuse is a governance issue for non-human identities. A form creator, file-sharing account or signature requester is a service-side identity that can be abused just like any other privileged account. That pushes mailbox defence closer to IAM and lifecycle governance, because the account behind the notification is the real security boundary.
Reply-path scrutiny should become a standard email control. When the Reply-To destination is inconsistent with the claimed sender, the message deserves elevated review even if the sending domain is genuine. That simple check often surfaces the mismatch that authentication cannot see.
For practitioners
- Inspect the reply path before the domain Check the Reply-To header, not only the From address, for any message that asks for sign-in, data entry or approval. A mismatch between the visible sender and the reply destination is a strong indicator that a trusted platform is being used as delivery infrastructure.
- Verify the account behind the notification Confirm which account created the form, file share, invoice, signature request or event invitation. If the platform is real but the requesting account is not expected, treat the message as suspicious even when SPF, DKIM and DMARC all pass.
- Scope allow-lists to specific senders Avoid allowing an entire platform domain by default. If business needs force an exception, restrict it to a known sender or workflow and keep behavioural analysis enabled so unusual requests still get inspected.
- Reinforce out-of-band verification for requests Train staff to validate platform-based requests in a separate channel such as Teams, Slack or a phone call before opening a shared file, completing a form or signing in through a notification link.
- Review trusted-platform abuse indicators Tune detection for first-time sender relationships, unusual request wording, mismatched reply destinations and legitimate domains carrying unexpected actions. Those signals are more useful than simple domain reputation in this threat pattern.
Key takeaways
- Real domains can still carry phishing when attackers abuse legitimate notification and sharing platforms.
- Mail authentication confirms infrastructure ownership, not whether the account behind the message is expected or trustworthy.
- Defence has to move from reputation-only filtering to behavioural checks, reply-path review and strict allow-list scoping.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The article centers on attacker use of trusted platforms to gain trust and move victims into malicious workflows. |
| Recommendation — Map trusted-platform abuse to TA0006 and TA0008, then hunt for platform accounts driving suspicious email flows. | ||
| CIS Controls v8 | CIS-5 — Account Management | Abuse hinges on compromised or attacker-created platform accounts behind legitimate mail. |
| Recommendation — Apply CIS-5 to inventory and govern accounts that can send notifications, forms and file shares. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The core issue is whether notification accounts have appropriate permissions and entitlements. |
| Recommendation — Use PR.AA-05 to review which service accounts can create, send and share trusted-platform content. | ||
| OWASP API Security Top 10 | API9 — Improper Inventory Management | The article's risk depends on poorly governed platform accounts and forgotten sending surfaces. |
| Recommendation — Inventory every external notification and sharing surface so hidden sender paths cannot be abused. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential and authenticator control is central when attackers abuse legitimate service accounts. |
| Recommendation — Apply IA-5 to rotate, revoke and monitor authenticators for platform accounts that send external mail. | ||
Key terms
- Trusted-Platform Abuse: The use of legitimate collaboration or cloud-sharing services as part of the attack infrastructure. The platform itself may be normal business software, but attackers exploit the trust users and security tools place in it to deliver content, redirect victims, or hide malicious activity.
- Reply-To Mismatch: A reply-to mismatch occurs when the Reply-To address or domain does not align with the sender’s claimed identity or the expected platform. It is a strong phishing indicator because it can redirect responses away from the legitimate service and toward attacker-controlled infrastructure. The mismatch matters most when paired with trust abuse.
- Behavioural Email Trust: An approach that evaluates whether a message fits the expected sender, workflow and business relationship rather than trusting domain reputation alone. It combines context, account provenance and request intent to decide whether action is safe.
- Platform-Side Identity: The service account, customer account or creator identity that loads a trusted platform with content such as forms, shares, invoices or invitations. It is often the real control point in phishing that uses legitimate infrastructure.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management for practitioners who need to connect identity controls to wider security decisions.Use it to strengthen the governance skills that underpin access, authentication and lifecycle control across identity programmes.
Published by the NHIMG editorial team on October 16, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org