Real Emails Can Still Be Phishing

A phishing email does not have to come from a fake domain to be dangerous. Some of the most convincing attacks abuse legitimate systems, trusted brands, and real notification workflows.

A recent Robinhood-themed phishing report is a useful example. The reported chain combines three issues that many businesses overlook: email alias handling, user-controlled fields, and trusted transactional emails. The result is a message that appears to come from a real sender, passes normal email authentication checks, and still may lead a user into a dangerous action.

This post explains what business leaders, operations teams, and IT teams should learn from that pattern, without getting into exploit instructions.

What Makes This Attack Different

Most phishing guidance starts with the sender. Check the domain. Look for misspellings. Hover over the link. Those habits still matter, but they are not enough.

In this scenario, the message is concerning because the email can be generated by a real platform. A reported attacker-created account uses a variation of the victim's Gmail address, then places deceptive content into a field that later appears in a security notification. If the platform's email template renders that field as trusted markup instead of plain text, the resulting email can look like a legitimate security alert with attacker-controlled messaging.

That is why this category is harder for users to judge. The sender may be authentic. Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC) may pass. The email may arrive from the brand's normal infrastructure. The risk is inside the content and workflow, not only in the sender.

Robinhood's own scam guidance still tells users not to select suspicious links or call numbers sent by text or email, and to access Robinhood directly through the app or website (Robinhood: How to identify and report scams). That advice is important because a real-looking email should not be treated as the final source of truth.

The Gmail Dot Issue Is A Business Logic Problem

Google explains that dots do not change personal Gmail addresses. For example, messages sent to dotted versions of a Gmail username still go to the same inbox. Google also notes that dots can matter for work, school, or organization-managed addresses, so this behavior should not be assumed for every domain (Google: Dots don't matter in Gmail addresses).

That difference creates a business logic challenge for account-based services. If an application treats one dotted Gmail variant as a completely separate identity, an attacker may be able to create an account whose notifications still reach the original Gmail inbox.

For most businesses, the lesson is not "block Gmail." The lesson is to normalize and verify account identifiers carefully.

Practical controls include:

• Normalize consumer Gmail addresses consistently where appropriate, including dot-insensitive handling for gmail.com addresses.
• Do not apply Gmail-specific normalization rules to custom domains where dots may be significant.
• Require email verification before sending sensitive account or security notifications.
• Detect multiple accounts that map to the same normalized consumer mailbox.
• Flag account creation attempts that combine unusual email variants with suspicious profile, device, or display names.

This is a reminder that security problems often live between systems. Gmail's routing behavior can be perfectly legitimate, while another platform's account logic can still create risk.

User-Controlled Fields Must Be Treated As Untrusted

The second issue is template safety. Many systems include user-controlled fields in emails: device names, display names, company names, project names, filenames, notes, and comments.

Those fields are convenient, but they are also untrusted input. If a template places them into an email without proper encoding or sanitization, the message may display attacker-controlled content in a way that users interpret as official.

The Open Worldwide Application Security Project (OWASP) frames Cross-Site Scripting (XSS) broadly as injection of content that can lead to account impersonation, external content loading, sensitive data theft, and other harm. OWASP recommends using the right combination of defensive techniques, including framework protections and context-aware encoding (OWASP: Cross Site Scripting Prevention Cheat Sheet).

Even when an email client blocks scripts, HTML injection can still matter. A maliciously formatted field may visually change the meaning of an email, hide important context, imitate a call-to-action, or push a user toward an attacker-controlled destination.

For product and engineering teams, the rule is simple: render user-controlled values as text unless there is a strong, reviewed reason to do otherwise.

Recommended safeguards include:

• Encode user-controlled fields before inserting them into HTML email templates.
• Use plain-text rendering for high-risk fields such as device names and display names.
• Apply length limits and character restrictions where rich input is unnecessary.
• Test transactional email templates with hostile input during quality assurance.
• Review template helper functions and email components for raw HTML escape hatches.
• Monitor for unusual characters or markup-like patterns in fields that appear in alerts.

Transactional emails deserve the same security review as web pages. They carry trust, urgency, and brand authority.

Email Authentication Helps, But It Does Not Judge Intent

SPF, DKIM, and DMARC are still essential. They help receiving mail systems determine whether a message is authorized to come from a domain and whether the visible From domain aligns with authentication results.

Microsoft describes SPF, DKIM, DMARC, and related mechanisms as interdependent building blocks that work together to protect against spoofing and phishing. Microsoft also notes that inbound systems use other signals, such as reputation, sender history, recipient history, behavioral analysis, and additional techniques, because authentication alone does not fully answer whether a message is safe (Microsoft: Email authentication).

DMARC's own overview explains that DMARC helps receivers determine whether a message aligns with what they know about the sender, and then apply policy to non-aligned messages (DMARC.org: Overview). That is powerful, but it is not the same as a guarantee that every authenticated email is harmless.

A real email from a real platform can still contain risky content if the platform workflow was abused. That is the gap businesses need to close.

What Businesses Should Do Next

This kind of attack is a useful tabletop scenario for any organization that sends account alerts, password reset emails, invoices, approval notices, device notifications, or payment-related messages.

Start by reviewing where user-controlled data appears in email templates. Device names, browser names, account names, customer names, memo fields, support ticket titles, and uploaded filenames are common examples.

Then review identity logic. Ask whether multiple email variants can create duplicate accounts, whether verification happens before notifications are sent, and whether alert workflows can be triggered by an untrusted or unverified account.

A focused review should answer these questions:

• Which email templates include user-controlled fields?
• Are those fields encoded for the correct context before rendering?
• Can an unverified user trigger a notification to someone else's inbox?
• Do we normalize consumer email aliases consistently without breaking custom domains?
• Do we alert on suspicious account creation patterns or unusual device names?
• Do we have a safe process for customers and employees to report suspicious emails?

For employee training, update the message. Do not teach users that "real sender equals safe." Teach them that authentication is one signal. The safer behavior is to open the app or type the known website address directly, especially for security, finance, payroll, identity, and password-related messages.

How Users Should Respond To Suspicious Real-Looking Emails

For individuals, the safest response is boring and effective.

Do not use the link, button, phone number, or attachment in an unexpected message. Open the official app or go directly to the known website. Check account activity from there. If the message claims unusual activity, verify it in the account dashboard rather than through the email.

If the message appears to involve Robinhood, Robinhood says suspected phishing can be reported to reportphishing@robinhood.com, and asks users to include full email headers when reporting suspicious email (Robinhood: How to identify and report scams).

The broader lesson applies beyond one brand: a valid sender is helpful information, not a safety guarantee.

Conclusion: Trust The Workflow, Not Just The Sender

This phishing pattern is a good reminder that security is not only about blocking fake domains. Attackers look for trusted workflows they can bend: account creation, email aliasing, notification templates, device names, and security alerts.

Businesses should review their own customer-facing emails before an attacker does. Make sure user-controlled fields are encoded, account identifiers are handled consistently, and alert workflows cannot be turned into phishing infrastructure.

If your organization wants a practical review of email security, phishing resilience, and account notification workflows, start with our cybersecurity services or contact Collett Systems to schedule a focused assessment.