The 'SendGrid' Email That Wasn't Sent by SendGrid

The email arrived with a single display name: "SendGrid." The subject line read: "Your /v3/mail/send endpoint has been paused." For anyone whose business depends on transactional email delivery, that is a high-urgency message. The single call to action button read "Open Account Preferences."

The sending address was noreply@eduvem[.]com. SendGrid had nothing to do with it.

Anatomy of a Display Name Impersonation

Display name impersonation is one of the most effective low-complexity phishing techniques available. Every major email client renders the visible sender name in large text and reduces the actual From address to a secondary field that requires an extra tap or hover to inspect. On mobile, the From address is often hidden entirely behind the display name unless the recipient explicitly expands the sender information.

This attack exploited that rendering asymmetry precisely. The display name "SendGrid" carried brand recognition and implied authority. The actual sending domain, eduvem[.]com, is a Brazilian education technology platform with no connection to Twilio SendGrid. The domain was registered in 2013 and currently uses Namecheap privacy protection, hosted on Google Cloud infrastructure at IP 35[.]215[.]125[.]13.

What made this message technically notable was not just the display name mismatch. The authentication posture of eduvem[.]com was in active disarray:

• SPF: Multiple conflicting SPF records were present, producing an invalid configuration. The result at evaluation time was PermError rather than a clean pass or fail.
• DKIM: No DKIM selectors were discoverable for the domain.
• DMARC: A DMARC record existed but was set to p=none, meaning no enforcement action would be applied to failures. Reporting was directed to a third-party DMARC reporting provider (Brevo).

The combination of a PermError SPF result, absent DKIM, and a non-enforcing DMARC policy created a technically ambiguous authentication outcome. Gateways that require a clean pass before triggering analysis may treat PermError as neutral, allowing the message to advance without raising flags.

The Click-Tracking Redirect as an Evasion Layer

The single CTA in the email pointed to a URL hosted under u26063703[.]ct[.]sendgrid[.]net, a genuine SendGrid click-tracking subdomain. This is a deliberate evasion technique with a specific mechanism: at delivery time, when an email gateway or URL scanner evaluates the link, the destination URL is the click-tracking endpoint on sendgrid.net. That domain carries legitimate reputation. The scanner sees a known-good domain and returns a clean result.

The actual redirect destination was only revealed after a click event, well after delivery-time scanning was complete. This is the fundamental limitation of credential harvesting attacks that chain through legitimate redirect infrastructure. The threat exists at click time, not at delivery time, and most gateway-layer scanning cannot reach past the redirect.

The open-tracking pixel was similarly hosted on sendgrid.net, reinforcing the appearance of a genuine SendGrid notification at every layer a scanner might inspect.

External Warning Banners Do Not Equal Detection

An external-sender warning banner was present at the top of the message. This is a standard configuration in many Microsoft 365 and Google Workspace deployments: any message originating outside the organization receives a yellow or red banner noting that the sender is external.

External-sender banners are a useful friction layer, but they are not a detection mechanism for email spoofing. A genuine SendGrid account notification would also come from an external sender and would also carry an external-sender banner. The banner tells the recipient nothing about whether the sender is legitimate. In this case, it may have actually reduced suspicion: the banner appeared, the recipient noted it, and nothing else stood out visually to prompt further investigation.

See Your Risk: Calculate how many threats your SEG is missing

What Behavioral Detection Surfaces

Themis, the Adaptive AI engine, flagged this message on a combination of signals that static authentication analysis could not access. The display name did not match any known SendGrid sending domain. The actual From address had no prior relationship with the recipient organization. The authentication posture of the sending domain was broken (PermError SPF plus absent DKIM). The message contained a single generic CTA with no recipient-specific identifiers, consistent with a mass-distribution phishing template rather than a transactional service notification.

Genuine service interruption notifications from platforms like SendGrid include account-specific identifiers: usernames, account IDs, or partial email addresses. This message had none. The subject line was generic, the body was a template, and the recipient was not identified by name or account reference anywhere in the message. That generic quality, combined with the display name mismatch and broken authentication, produced the behavioral fingerprint that triggered detection.

For defenders: monitoring for display name mismatches against a known-sender registry (particularly for widely impersonated platforms like SendGrid, DocuSign, or Microsoft) is one of the higher-signal detection controls available for this class of attack. Authentication results alone cannot surface it.

Indicators of Compromise

MITRE ATT&CK Mapping