Trusted Email Is the New Phishing Infrastructure

For years, phishing advice has leaned on a simple test: check the sender.

That advice is now incomplete.

In a growing class of phishing and fraud campaigns, the email does not merely pretend to come from Microsoft, Google, PayPal, Docusign, or another trusted platform. The message is generated by the platform itself. SPF can pass. DKIM can pass. DMARC can pass. The sending IP can belong to a cloud provider with a strong reputation.

The problem is not always forged email. The problem is legitimate workflow abuse.

Attackers are using customer-controlled fields inside trusted platforms - tenant names, team names, alert descriptions, invoice metadata, document titles, report names, and workflow notifications - to make those platforms deliver malicious content through their own notification systems.

TL;DR

• This is not classic spoofing. In many cases, the trusted platform really sends the message.
• Attackers abuse legitimate notification, alert, invitation, billing, and workflow features.
• SPF, DKIM, and DMARC only prove sending authorization and message integrity. They do not prove the business context is legitimate.
• Recent cases involve Microsoft account notifications, Power BI, Azure Monitor, Teams invitations, Google Cloud Application Integration, Google Tasks, Docusign, PayPal, Amazon SES, and Betterment.
• Defenders need to evaluate sender, content, workflow context, and expected business relationship together.

The Old Trust Model Is Breaking

Email authentication answers a narrow technical question:

Was this message authorized to use this sending domain?

That matters. SPF, DKIM, and DMARC are still essential controls. They reduce direct domain spoofing, protect brand reputation, and help receiving systems reject unauthenticated mail.

But they do not answer the question users actually care about:

Is this message a legitimate business event?

That distinction is now critical. A message can be technically authentic and still be malicious. If an attacker can make a real platform send attacker-controlled content, the authentication layer has done its job while the user is still at risk.

The attack surface is the gap between technical authenticity and business legitimacy.

What Trusted Transactional Email Abuse Means

Trusted transactional email abuse happens when an attacker uses a legitimate platform’s own messaging pipeline to deliver malicious or deceptive content.

The core pattern is simple:

1. The attacker creates or compromises an account on a trusted platform.
2. The platform exposes a field that appears in outbound notifications.
3. The attacker places the lure in that field.
4. The platform sends the notification from its legitimate infrastructure.
5. The victim sees a real sender, a familiar brand, and a message that may pass email authentication.

This can happen through many normal business features:

The lure often does not need a malicious attachment. Callback phishing campaigns may only need a phone number. Credential theft campaigns may route through trusted infrastructure before landing on a fake login page. QR campaigns may hide the final destination from email scanners entirely.

Recent Cases

The cases below are included because they have public reporting from vendors, security researchers, or reputable security media. The details differ, but the pattern is consistent: trusted systems are used as delivery infrastructure.

Microsoft Account Notification Abuse

TechCrunch reported on May 21, 2026 that scammers had been abusing Microsoft’s account notification email path. The reported messages came from msonlineservicesteam@microsoftonline.com, an address Microsoft uses for legitimate account-related notifications.

Spamhaus also said it had seen the same Microsoft account notification address abused for spam over a period of several months. Microsoft told TechCrunch it was investigating and strengthening detection and blocking mechanisms.

The important point: this is not ordinary lookalike-domain phishing. The observed sender was a Microsoft notification address used for real account alerts.

Microsoft Power BI Notification Abuse

In January 2026, Ars Technica and PCWorld reported scam emails sent from no-reply-powerbi@microsoft.com, a legitimate Power BI notification address. The abuse centered on Power BI notification/subscription behavior, where attacker-controlled content could be presented inside Microsoft-generated email.

Ars Technica later updated its report to say Microsoft had temporarily disabled the scorecard email subscription feature while working on a longer-term fix.

This is a strong example of why allowlisting a trusted notification sender can be dangerous. The sender can be real while the event is fake.

Microsoft Azure Monitor Callback Phishing

BleepingComputer reported in March 2026 that attackers were abusing Microsoft Azure Monitor alerts for callback phishing.

The messages were not spoofed. They were sent by Azure Monitor using azure-noreply@microsoft.com. Attackers reportedly created alert rules, placed scam content in alert fields such as descriptions, triggered the alerts, and sent the resulting notifications to victims.

The lure was familiar: suspicious charges, invoice activity, account warnings, and a fake support number. The goal was not necessarily to make the victim click a link. It was to make the victim call.

Microsoft Teams Guest Invitation Abuse

Check Point reporting, summarized by ITPro in January 2026, described a campaign using legitimate Microsoft Teams guest invitations. Attackers created Teams with names that looked like urgent billing or subscription warnings, then invited victims as guests.

Because the invitation email was generated by Microsoft, the message looked like a normal Teams notification. The attacker-controlled team name carried the social engineering payload.

ITPro reported more than 12,000 malicious emails sent to over 6,000 users in the observed campaign.

Google Cloud Application Integration Abuse

In late 2025 and early 2026, researchers reported phishing campaigns abusing Google Cloud Application Integration’s email-sending functionality. Malwarebytes summarized reporting that messages were sent from the legitimate Google address noreply-application-integration@google.com.

The campaign used Google infrastructure as part of the delivery and redirection chain, then led victims to a fake Microsoft 365 sign-in page. Public reporting cited 9,394 phishing emails targeting about 3,200 organizations over a 14-day period in December 2025.

Google told researchers it had blocked several phishing campaigns involving misuse of that notification feature.

Google Tasks Notifications

Kaspersky reported in February 2026 that attackers were delivering phishing links through Google Tasks notifications. Victims received legitimate-looking @google.com task notifications, with attacker-controlled task content directing them to a fake employee verification flow.

The defensive lesson is straightforward: if a company does not use Google Tasks for HR, identity verification, or employee onboarding, a task notification claiming that purpose should be suspicious even if the sender is Google.

Docusign Workflow and Reporting Feature Abuse

Docusign’s own Safety Center has published multiple fraud alerts relevant to this pattern.

On May 22, 2026, Docusign warned that attackers were sending fraudulent Docusign envelopes impersonating financial institutions and using payment, disbursement, and vendor contract themes. Docusign stated that the notifications originated from the Docusign platform but represented malicious third-party exploitation of its services.

On April 9, 2026, Docusign said attackers had misused legitimate Docusign system features, including “Send Report,” to bypass email filters. The lures included cryptocurrency-themed unauthorized transaction alerts and fake security warnings that pushed victims to call fraudulent phone numbers.

On February 5, 2026, Docusign warned about workflow notifications from Docusign Maestro combined with external communication to create fake invoice and subscription-renewal scams.

PayPal Subscription and Billing Notification Abuse

BleepingComputer reported in December 2025 that scammers abused PayPal’s Subscriptions billing feature to send legitimate PayPal emails containing fake purchase notices. Malwarebytes later reported that PayPal closed the loophole.

The reported sender was the legitimate service@paypal.com address. The scam content was placed into subscription-related metadata, including a customer service URL field.

This is the same structural issue: a trusted billing system accepted attacker-controlled content and distributed it through a legitimate transactional email path.

Amazon SES Account Abuse

Kaspersky warned in May 2026 about phishing and BEC campaigns using compromised Amazon Simple Email Service accounts.

This case is a related but distinct subtype. Instead of abusing a built-in notification field, attackers used stolen AWS IAM keys to send email through Amazon SES. That gives the attacker direct control over messages while still benefiting from trusted cloud email infrastructure, reputable sending IPs, and Amazon SES identifiers.

Kaspersky described campaigns impersonating document-signing platforms such as Docusign and BEC scenarios targeting finance departments.

Betterment Customer Notification Abuse

TechCrunch reported in January 2026 that Betterment confirmed a breach after attackers sent fraudulent crypto-related notifications to customers. Betterment said an unauthorized individual gained access to certain systems and sent messages that appeared to come from Betterment.

This case matters because it extends the same trust problem beyond email. A malicious push notification or in-app message can be even more convincing than email because users assume it came from the official app.

The Technical Pattern

These incidents are not identical, but they rhyme.

The attack usually depends on one of four conditions:

1. User-Controlled Text Appears in Trusted Notifications

Examples include:

• Azure Monitor alert descriptions
• Teams team names
• Power BI scorecard or report names
• Docusign envelope titles or report names
• PayPal subscription metadata
• Tenant, app, or organization names in identity emails

If that field allows phone numbers, URLs, currency amounts, brand names, homoglyphs, or long free-form text, it can become a delivery channel.

2. The Notification System Sends to Arbitrary or Weakly Verified Recipients

Some workflows must send to external users. That is normal for collaboration, invoices, signatures, guest access, and customer identity flows.

But if attackers can send notifications to large external lists with little friction, the feature becomes a spam relay with excellent reputation.

3. Security Controls Trust the Sender More Than the Workflow

Many filters, allowlists, and user habits treat a Microsoft, Google, PayPal, Docusign, or Amazon sender as inherently trustworthy.

That assumption is exactly what the attacker is exploiting.

4. The Payload Avoids Classic Malware Signals

Many campaigns use no executable attachment and no obvious malicious link. Callback phishing only needs a phone number. QR phishing moves the risky action to a phone. Legitimate links can point to the platform itself while the social engineering content sits in visible text.

That reduces the value of purely attachment- or URL-centric detection.

Why SPF, DKIM, and DMARC Do Not Solve This

SPF, DKIM, and DMARC are still necessary. They stop many forged-message attacks.

But they do not validate intent.

In trusted transactional email abuse, the problem often happens before DKIM signing. The attacker-controlled content is already inside the legitimate notification when the platform signs it.

From an authentication perspective, the email is real.

From a security perspective, the message is hostile.

Detection Ideas for Defenders

The defensive model should shift from “is the sender trusted?” to “does this sender normally send this kind of event to this recipient?”

Watch for Phone Numbers in System Notifications

Callback phishing frequently uses trusted notification systems because a phone number is harder for some email controls to classify than a malicious URL.

High-risk combinations:

• Microsoft, Google, Docusign, or PayPal notification plus a phone number
• “Unauthorized charge” plus a phone number
• “Subscription renewal” plus a phone number
• “Security support” plus a phone number
• Currency amount plus urgent callback language

Detect Billing Language in Non-Billing Workflows

An Azure Monitor alert, Teams guest invitation, Google Task, or Docusign report should not usually contain consumer-style refund language.

Suspicious terms include:

• “unauthorized charge”
• “refund”
• “auto-pay”
• “subscription renewal”
• “invoice activity”
• “call support”
• “crypto transaction”
• “wallet”
• “payment on hold”

These terms are not malicious by themselves. They become suspicious when they appear in the wrong workflow.

Treat Tenant, Team, Alert, and Report Names as Untrusted Input

Security tooling should parse and score display fields that appear inside trusted notifications.

Look for:

• Long names that read like full sentences
• Phone numbers in names or descriptions
• Currency amounts
• Unicode homoglyphs
• Brand names unrelated to the sending platform
• Fake support wording
• Obfuscated spelling such as m0nthly, Ivoice, or mixed character sets

Do Not Blanket-Allow Notification Senders

Avoid broad rules like:

Always allow no-reply-powerbi@microsoft.com
Always allow azure-noreply@microsoft.com
Always allow service@paypal.com
Always allow dse_*.docusign.net

If allowlisting is unavoidable for business continuity, pair it with content inspection, anomaly detection, and reporting workflows. A trusted sender should reduce one kind of risk score, not override the rest of the message analysis.

Correlate With Business Context

Ask simple questions in automation:

• Does this user normally receive Azure Monitor alerts?
• Is this recipient a member of the tenant that generated the message?
• Has this organization ever used Power BI, Docusign Maestro, or Google Tasks with this user?
• Is the sender workflow expected for this department?
• Is this a first-time sender-platform relationship?

Context is the control that sender authentication cannot provide.

Hardening Recommendations for Organizations

For Security Teams

1. Inventory trusted notification senders. Identify Microsoft, Google, Docusign, PayPal, AWS, CRM, HR, finance, monitoring, and ticketing senders that users commonly receive.

2. Review allowlists. Remove broad allow rules that bypass content scanning. Replace them with scoped rules and monitoring.

3. Create detection rules for callback language. Phone numbers plus urgent billing or fraud language from a system notification should be high priority.

4. Train users on context, not just sender. The better rule is: verify unexpected alerts through the application directly, not through email links, QR codes, or phone numbers in the message.

5. Report abuse to the platform. Many of these services have abuse reporting channels. Reporting helps providers identify the abused tenant, project, workflow, or feature.

For SaaS and Cloud Administrators

1. Limit who can invite external users. Collaboration invite features are useful, but external guest invitations should be governed.

2. Restrict alert recipients. Monitoring alerts should not be able to target arbitrary external recipients without review.

3. Review display-name policy. Tenant names, team names, app names, and alert names should not contain phone numbers, URLs, currency amounts, or misleading support language.

4. Audit newly created workflows. New alert rules, subscriptions, Teams, Power BI reports, Docusign envelopes, and identity flows that immediately notify external recipients deserve attention.

5. Monitor for burst behavior. A new object that sends many external notifications quickly is suspicious.

For SaaS Vendors

1. Treat every customer-controlled display field as hostile input.

2. Block or heavily restrict URLs, phone numbers, currency amounts, and impersonation phrases in notification titles.

3. Separate customer branding from security-critical content.

4. Add abuse throttles for new tenants, new projects, and free/demo accounts.

5. Make reporting easy from the notification itself.

6. Expose tenant/project/workflow identifiers in headers or machine-readable fields so defenders can correlate abuse.

The long-term fix has to happen at the platform layer. Email security teams can detect patterns, but vendors control the fields, templates, rate limits, and account trust boundaries that make abuse possible.

What Users Should Do

The practical advice changes slightly:

Do not trust an email only because the sender is real.

For unexpected billing, fraud, subscription, payment, document, or account messages:

• Do not call phone numbers in the message.
• Do not scan QR codes from unexpected notifications.
• Do not sign in through links in the message.
• Open the service directly from a bookmark or typed URL.
• Check whether the event exists inside the real application.
• Report the message to your security team or the platform’s abuse channel.

This is not paranoia. It is the correct response to a world where legitimate platforms can be used as phishing delivery infrastructure.

Bottom Line

The next phishing email may pass SPF, DKIM, and DMARC because it is not forged.

It may come from Microsoft. It may come from Google. It may come from Docusign, PayPal, Amazon SES, or a customer communication platform your organization already trusts.

That does not make the event legitimate.

Defenders need to inspect the workflow, not just the sender. The question is no longer “Did this email really come from a trusted platform?” The better question is:

Why is this trusted platform sending this message, to this person, with this content, right now?

That is where the detection opportunity is.

Sources

• TechCrunch: Scammers are abusing an internal Microsoft account to send spam links
• Microsoft Learn: Self-service password reset deep dive - notification sender addresses
• Ars Technica: There’s a rash of scam spam coming from a real Microsoft address
• PCWorld: Beware! That Microsoft email is genuine, but it’s also a scam
• BleepingComputer: Microsoft Azure Monitor alerts abused for callback phishing attacks
• ITPro: Thousands of Microsoft Teams users are being targeted in a new phishing campaign
• Malwarebytes: Phishing campaign abuses Google Cloud services to steal Microsoft 365 logins
• Kaspersky: Phishing via Google Tasks
• Docusign: Safety alerts and updates
• BleepingComputer: Beware: PayPal subscriptions abused to send fake purchase emails
• Malwarebytes: PayPal closes loophole that let scammers send real emails with fake purchase notices
• Kaspersky: Kaspersky warns of phishing attacks via compromised Amazon Simple Email Service accounts
• TechCrunch: Fintech firm Betterment confirms data breach after hackers send fake crypto scam notification to users