[ZoneZealot]

SendGrid's platform doesn't need to be the sender of these emails at all. It's just classic phishing, the emails can pass SPF, DKIM and DMARC as all of these rely on DNS resource records to be created on the RFC5321.MailFrom and/or RFC5322.From domain. Which is under control of the spammer. It's not pretending to be from sendgrid.com, if it was then these measures would help.

[TZubiri]

Correct, I think the confusion might arise because of the self replicating nature of this attack when the target domain is an MTA.

I can't pinpoint it exactly, but it might be a combination of the replication cycle of the attack being recursive and very short if the target is an MTA. But it may also be because the fact that sendgrid clients are sendgrid clients is public information.

Kind of how like meta companies are overrepresented in their medium, in a stock exchange banks are overrerpresented, lots of websites about building websites, lots of road ads are about placing road ads.

[rezonant]

Yes, as the article says, they seem to be using Sendgrid to phish Sendgrid customers because the UX is "xyz.com delivered by sendgrid.com", hoping that this is seen as legitimacy by the recipient.

[ZoneZealot]

None of the examples in the article exhibit the 'via' UX. They were all sent with an aligned RFC5321.MailFrom and RFC5322.From (i.e. domain name used in both of those values is the same), those not matching is the most common reason to have the 'via' displayed [0]. They do have display names which pretend to be SendGrid.

0: https://support.google.com/mail/answer/1311182#zippy=%2Ci-ca...