Twilio SendGrid Phishing Examples: 27 Real Emails That Passed Authentication

We use Twilio SendGrid to send email. It is one of our sending integrations, and because we are a public company in the security space, that is not a secret. Attackers can work it out. So a few of them decided that the most reliable way into our inbox was to pretend to be SendGrid itself.

Over the past year I have collected the ones that made it past Google Workspace and landed in front of me. Twenty-seven of them. Not samples from a vendor report. Real emails, addressed to me, delivered to a hardened enterprise Gmail tenant.

Some of them were laughably bad. A few were good enough that I slowed down. One or two would probably have caught me on a busy day, halfway between meetings with my phone in one hand, and I do this for a living. That range is exactly why I kept them.

Here is the part that should bother every security team, though. Almost all of them passed SPF, DKIM and DMARC. The checks came back clean. The sender was still a lie.

What follows is the whole set, more or less in the order I made sense of it: what each one claimed, what it was really after, and what gave it away. After that, the mechanic that lets these through, and what I think you should actually do about it.

• 27 SendGrid phishing emails reached one inbox between August 2025 and June 2026.
• 27 of 27 passed SPF. This is a phishing campaign that passed authentication, by design.
• 26 of 27 passed DKIM. The single exception threw a DKIM key error, not a clean fail, and it still passed DMARC.
• 0 failed DMARC. 22 of 27 passed DMARC outright, the rest carried no DMARC verdict, and not one was rejected on authentication.
• 7 lure families, from API failures to a fabricated corporate event and a single off-platform credential-harvesting page.
• API failures were the most common lure by a wide margin, and March 2026 was the peak month with 9 emails.

The short version: this is a SendGrid impersonation campaign that beats the checks most teams rely on. The defense is not a better filter. It is a person who verifies.

The Pattern In The Numbers

The lures cluster into seven families. Counts cover all 27 emails.

The timeline matters as much as the volume. These did not arrive once. They arrived on a schedule, and the rate climbed sharply into 2026.

Why these even reach the inbox

Most people assume a phishing email either gets blocked by the mail filter or shows up with a big "this failed authentication" warning. These did neither.

The reason is simple and a little uncomfortable. The attackers are not spoofing sendgrid.com from some sketchy server. They are sending the SendGrid-branded message through SendGrid, from a real SendGrid account on an unrelated domain. SPF, DKIM and DMARC then pass, because they are passing for the sending domain the attacker controls, not for the brand in the From display name.

Netcraft named this loop "Phishception": SendGrid abused to impersonate SendGrid. CSO Online and Fortra have both tracked the same pattern, where compromised SendGrid accounts are used to send more SendGrid phishing, and every stolen login becomes the next sending account. The platform's selling point, high deliverability, is exactly what makes a hijacked account valuable.

Here is what that looks like in the headers of one real message from the set.

The display name says SendGrid. The actual From domain is poshenergygrid.com. The Return-Path and a SendGrid shared sending IP confirm it went out through SendGrid, so SPF, DKIM and DMARC all pass, for poshenergygrid.com, not for sendgrid.com. Every check is green and the message is still a fake. That is the gap attackers live in.

What surprised me was not that these reached the inbox. It was that nearly all of them passed authentication on the way in. The mail system did its job exactly as designed. The sender just was not who the display name claimed. SPF and DKIM confirm a message was sent the way the sending domain allows; they say nothing about whether the brand in the From line is genuine. This is social engineering, not a software bug, and you cannot patch your way out of it.

The 27 Emails

I did not start with a taxonomy. I just read them, one after another, and after a while the same shapes kept coming back. The biggest group by far was API panic: something is broken, paused, or about to stop working. Then a run of fake security alerts. A smaller set fussing about reputation and deliverability. And a handful of odd ones that did not fit anywhere, which turned out to be the most interesting of the lot. Here they are in those rough buckets.

A note on the senders and screenshots. The sending domains named below are themselves victims: real businesses whose SendGrid accounts were abused, or throwaway accounts set up to send through the platform. They are not the attackers, and naming them is meant to show the display-name-versus-real-domain gap, not to assign blame. To protect third parties, links and credential-harvesting destinations have been redacted from the screenshots, except where a lookalike domain is itself the lesson.

The "Your API is Broken" Pile

This was more than half of everything I received. The pretext is always a technical failure that a developer or an ops owner would feel obligated to fix right now, before someone notices the mail stopped going out. Most of them share a tell once you have seen a few: a thin body, one big button, and a link dressed up to look on-platform.

API Endpoint Disabled

From inspiresoftware.com, all three checks green, sent on New Year's Eve, which is a nice touch when half the team is off. Claims /api/v3/send was disabled "due to a configuration issue" and points you at your account preferences to fix it. Real SendGrid notices do not come from inspiresoftware.com.

API Endpoint Failures

From myjohnstonesupply.com. It drops "503 / 429" status codes to look credible and asks you to "acknowledge the usage notice." There is no usage notice. The codes are stage props.

API Endpoint Issue

From stoeltingco.com. "Several of your recent API calls have been unsuccessful." No account ID, no specifics, a generic "Hi there." It cannot be specific, because whoever sent it does not actually know anything about my account.

API Failures Detected

From worldticket.net. I half-laughed at this one. It invents a "preferences mismatch on your account," which is not a thing SendGrid says, but it sounds technical enough that plenty of people would accept it without asking what it actually means. That is the whole trick in three words.

API Issue Detected

The From domain is a bare sendgrid, no top-level domain at all. Friendly tone, "Hey there, we know how frustrating this can be." If the sender address is malformed like that, you can stop reading.

API Request Failures Detected

From leasebusters.com. A big VIEW ERROR LOGS button sitting over almost nothing. That is the whole email.

API Request Status Update

From voltus.co. "Requests to your API endpoint are currently failing, which means emails are not being sent." Lost mail is the one thing a sender genuinely panics about, so the lure goes straight for it.

Update on Your Webhook Connection

From journeysconnect.com. If I am honest, this was one of the more convincing ones. The webhook angle is narrow and technical, and it is aimed squarely at the one developer who owns the event integration and would absolutely click to check "several consecutive delivery failures." It does not try to scare everyone. It tries to reach one person.

Your API Sending is Paused

From tagshelf.com. "A pending security step" is holding your sending, and "this typically takes less than a minute." That last line is the clever part. Telling you it is quick is how they get you to do it without thinking.

Your API calls aren't going through

From onuma.com. It blames an "authentication setup or domain verification" mismatch and tells you to check your API keys. Read that again: it is steering you toward a page where you will type your secrets.

Your Sending is Paused

From poshenergygrid.com, which is the same message I pulled apart in the header diagram above. A fake "account policy update" that supposedly needs a new setting configured before you can send again.

Your request couldn't be completed

From theappsolutes.com. "Error 421, Missing CNAME record," followed by DNS instructions. The fake error code is doing a specific job: making a non-technical reader feel out of their depth and defer to the helpful "expert" who sent it.

The ones after the keys, not just a password

A smaller, nastier group. These do not want a password so much as control of the sending engine itself, which is the real prize once you remember that a working SendGrid account is what lets the next phish go out.

API Key Update

From mitsubishielectric.ca. "All API keys generated before March 2026 need to be regenerated" or they stop authenticating. There is no such deadline. What they want is for you to revoke a real key and mint a new one on a page they control, which hands them a live, working API key. Of all the technical lures, this is the one I would least want a junior engineer to receive at 5pm on a Friday.

Verify your senders

From own-kind.com. New "sender verification standards," please re-verify your sender identities. Do it on their page and they get to decide which addresses your account can send as.

Your Verified Senders Have Changed

From starbucksindia.net. The same hijack from the other direction: your senders are "no longer verified," reverify to keep sending. Honestly, the domain name alone should end it here.

The fake security alerts

There is a cruel irony in this group. They use the exact instinct we spend our days training people to have: see something off on your account, act on it quickly.

New subuser added to your account

From garageplug.in. "A subuser with sending permissions was recently created. If you don't recognize this, review your account access." This is the one that most deserves a second look, because subusers really are how these accounts get abused. So the fake warning describes a real risk, which is what makes a careful person click.

New Admin Added

From carnegietelephone.com, all three checks green, April 2026. "A new teammate with admin-level permissions was added to your account. If this wasn't you, review your teammates and remove any unrecognized users." It even copies the real footer address in Denver. Same machinery as the subuser email, a notch scarier, because admin access sounds like the keys to everything.

Abuse complaint filed against your account

From ismrm.org. This one reaches for compliance dread instead of urgency: "a complaint through Gmail Postmaster Tools," "potential CAN-SPAM violations," log in to "review the cited messages." Real-sounding program names doing the heavy lifting.

The slow, plausible ones about reputation

These were the ones I respected, a little. No flashing alarm, no countdown. They imitate the boring deliverability nags a real sender actually gets, which is why they blend in.

Your reputation score has started to drop

From esmsolutions.com. Pure loss aversion: your reputation is "starting to fall below the threshold," log in to stop the slide. Nobody who sends email at scale ignores a sentence like that.

Your report rate needs a quick review

From megger.com. "Your report rate has risen above 0.1%." This is also the one technically interesting outlier in the set. Its DKIM check did not pass cleanly; it returned a permerror, meaning the receiving server could not find a key for the signature. And yet it still landed, because SPF aligned and DMARC passed anyway. Sit with that for a second: the one message with a broken signature still made it to the inbox on a DMARC pass. If your filtering logic treats "DMARC pass" as a safe-to-deliver verdict, this is the email that walks right through it.

Your Weekly Health Review

From mitsuibussancommodities.com. No panic at all, which is what makes it work. It is a fake weekly report, complete with invented metrics (13.97% processing success, 8.2M requests, 89ms response) that look exactly like the ones you skim every Monday and never click through. Until the week you do.

The One That Made Me Reread It

Action required by January 13

From aha.org. This is the one that actually made me stop and read twice. "Following our merger with Sinch, we're upgrading our API infrastructure," so move to a "new endpoint structure" by the deadline. For a second the story sounded plausible, which is exactly why it is dangerous. Then I checked. There is no Twilio or SendGrid merger with Sinch; Twilio bought SendGrid back in 2019 and still owns it. The attacker simply invented a corporate event to manufacture a deadline. When an email leans on big news to justify an urgent change, go verify the news somewhere else before you touch the link.

The odd ones that traded fear for feelings

A few did not bother with panic at all. They reach for an emotional or political reaction instead, the same trick behind the "Support ICE" and Pride-footer SendGrid scams that Netcraft and others have written up. Invent a sensitive change to your account, and you will log in just to opt out of it.

New LGBTQ+ Footer Added

From useregie.com. A little story about meeting "LGBTQ+ founders," then: we are adding an optional Pride footer to your outgoing email. Agree with it, disagree with it, it does not matter. The link goes to the same place either way.

Women's History Month Footer Added

From houzeo.com. Same play, different month. "Our CEO was moved to act," a Women's History Month footer is going on your sends. The emotion is the point; it gets a reaction before judgment catches up.

Language Preference Updated

From nutritionsociety.org. This is the cheapest trick in the set and probably one of the most effective: "Your language preference has been changed to Spanish." You did not do that, so you rush to undo it, and undoing it means logging in. Annoyance works as well as fear.

The dangerous one

Your report is ready

From zentrix.com.mx. On the surface it is the dullest message here: your report finished, it is available for 72 hours. But here is what sets it apart. Almost every other lure hid behind SendGrid's own click-tracker, which is partly why they looked so clean. This one does not. Its "View Report" link goes to view-exportsendgrid.com, a lookalike domain that exists for one reason, to take your credentials. The lookalike is the entire attack. Anytime you land on something that is "sendgrid" with extra words stapled on, close the tab.

The one that started it

API Integration Health Alert

From omniballot.us, all checks green, dated August 1, 2025, which makes it the earliest in my folder and, looking back, the opening shot. "Our monitoring systems have identified a high volume of failed API requests originating from your account," then a tidy troubleshooting guide about rate limits and the rest. It is calmer and more patient than the panic emails that came later, almost helpful. That is the part worth sitting with: the campaign did not start loud. It started as a polite, well-built alert in the middle of summer, and by the following spring it was arriving nine times a month.

How to tell a real SendGrid email from a fake one

After 27 of these, the patterns are consistent. None of them require deep technical skill to catch.

Check the actual sender domain, not the display name. Every fake in this set said "SendGrid" in the display name and came from inspiresoftware.com, garageplug.in, starbucksindia.net, and so on. Genuine SendGrid mail comes from sendgrid.com or twilio.com, never from a random unrelated company, and never from a malformed bare "sendgrid" with no domain.

Hover the link before you click. A login or settings link that resolves to a lookalike like view-exportsendgrid.com is the clearest possible signal. And remember that a SendGrid click-tracker link is not proof of safety here, because the attackers are sending through SendGrid.

Be suspicious of any email that creates a deadline, a service interruption, or a "verify now or lose access" choice. Account paused, sending paused, keys expiring, senders un-verified, a complaint filed, a merger deadline. Urgency is the common ingredient across all seven families.

Stop trusting "it passed authentication" as a verdict. This is the hard one. Most of these passed SPF, DKIM and DMARC. Authentication tells you how a message was sent. It does not tell you who really sent it. The only reliable move is to verify out of band: open a new tab, type the SendGrid console address yourself, and check your account directly. Never act inside the email.

If you just received one of these

Do not click and do not reply. Open the SendGrid console by typing the address into a new tab yourself, then check your billing, API keys, subusers and verified senders from inside the account. If anything looks wrong, rotate your API keys and review account access immediately. Forward the email to abuse@sendgrid.com so their team can act on the sending account, and report it to your own security team so they can warn colleagues who likely got the same lure.

How to secure your Twilio SendGrid account

The phishing is aimed at one prize: a working SendGrid login or API key. Hardening the account makes a stolen credential far less useful and makes account takeover far harder. Here is the checklist we run, and the one we recommend to customers.

1. Turn on two-factor authentication for every user. Use an authenticator app or a security key, not SMS, and enforce it across the whole account so no teammate is the soft spot.
2. Use SSO where your plan supports it. Tie console access to your identity provider so offboarding and password policy are handled in one place.
3. Scope every API key to least privilege. A key that only needs to send mail should not have full access. Delete unused keys, and never paste a key into an email, a chat, or client-side code.
4. Rotate keys and store them in a secrets manager. Treat any key that might have touched a phishing page as burned, and replace it.
5. Lock API access with IP Access Management. Allowlist the IP addresses that are allowed to use your account and keys, so a stolen key is useless from an attacker's machine.
6. Audit Teammates and Subusers regularly. Subusers are the abuse vector in these attacks, so restrict who can create them, and remove any you do not recognize.
7. Finish sender authentication and enforce DMARC on your own domain. Set up domain authentication (DKIM/CNAME) for your sending domain and keep DMARC at enforcement, so attackers cannot easily spoof your brand to your own customers.
8. Turn on activity alerts. Watch for new API keys, new senders, new subusers, and sending spikes, and route those alerts somewhere a human reads them.
9. Verify account changes out of band, always. Never act on a "paused," "verify," or "key expiring" email. Act only from the console you opened yourself.
10. Train the people who hold the keys. The developers and ops owners with console access are the real targets, so they are the ones who need the practice.

Train against the exact lure, on every channel

After sorting through all 27, the conclusion was not subtle. These are built to beat the filter, and they do. So the only thing left standing between the email and the damage is the person reading it, which means people have to meet this kind of message in a drill before they meet it on a bad day. That is a trained reflex, and reflexes come from practice, not from an annual slideshow.

This is the part where I have a clear bias, because it is what we build. We run a phishing simulator on exactly these lures, and the patterns above make ready-made phishing simulation templates. My rule of thumb is simple: the campaigns that beat your mail filter are the ones worth simulating, because they are what your people actually face. Test only the obviously fake stuff and you are grading the easier exam.

It also rarely stops at email. A stolen SendGrid login often becomes the opening move in a multi-channel attack: the OpenAI invoice scam Kaseya documented paired SendGrid abuse with a phone callback. So test the way attackers actually work, across smishing, vishing, QR-code quishing and callback phishing, not email alone. Pair the simulations with adaptive security awareness training so the people who keep clicking get more practice, not the same annual video as everyone else.

One practical control worth adding: give people a one-click way to report a suspicious email from their inbox, and make reporting feel useful. Report rate and time-to-report are the metrics I watch, not completion. A high report rate on a "your sending is paused" lure is the signal that the training is actually changing behavior.

Two more things worth naming. First, a stolen SendGrid login or API key is not the end of the attack, it is the start of one. It feeds account takeover and business email compromise, and it is brand impersonation at scale, since the next phish goes out from your account. Second, AI lets attackers template these at scale, which is why I received twenty-seven variations of the same five ideas. The volume is cheap now. The defense has to be a behavior, not a filter rule.

That is the part of our Extended Human Risk Management Platform I care about most: not catching every email, but making sure the person reading it stops and checks before they act. We are a SendGrid customer ourselves, so none of this is theory for me. I got all 27 of these in my own inbox, and the only thing that ever stopped one was a habit of not trusting the envelope.

What people assume, and what is actually true

If there is one table to take away from this SendGrid phishing campaign, it is this one. Every assumption on the left failed against the 27 emails we received.

Sources referenced for the mechanic and external corroboration: Netcraft ("Phishception"), CSO Online (compromised SendGrid accounts), Fortra (Twilio SendGrid abuse campaign), Kaseya (OpenAI invoice / callback phishing), and Twilio/SendGrid official support guidance. All 27 examples are real emails received at ozan@keepnetlabs.com.