DKIM passed, and that is the problem: SendGrid key phishing

A SendGrid API key is a non-human principal that can send through your authenticated domain, so the mail passes DKIM and SPF. When the key leaks, those checks become meaningless as a signal, because every legitimate message passes too.

How the attack works

The key authenticates from an IP and ASN never associated with the account, late at night. It sends a high-engagement burst from a real-looking notifications address on your verified domain, linking to an external login page that harvests credentials. It then adds an Event Webhook pointing to an attacker host to exfiltrate open and click telemetry, so the attacker can target users who engage. Harvested credentials are then reused against the corporate IdP. In ATT&CK terms this is T1078, Valid Accounts, with T1566, Phishing, T1534, Internal Spearphishing, and T1098 for the webhook persistence.

Why it works

Because the domain is authenticated, DKIM and SPF passing means nothing. The tell is one key arriving from an unfamiliar source, sending external-login-link mail, and wiring an event webhook to a foreign host. A full-access, long-lived key checked into a build artifact and reused across apps is the root cause.

How to fix it

Revoke and rotate the key, then revert the event webhook and any altered templates, because the key is the principal, not a mailbox. Do not rotate DKIM, which breaks all legitimate mail while the attacker keeps sending. Scope who was phished from the SendGrid Email Activity feed and the audit log filtered to the key. For the class, inventory keys, scope them to least privilege, vault secrets, enable IP access management, and add secret scanning in CI. Trusted-domain phishing is reputational and harms sending deliverability.

Practice it

We built this as a GraphLattice Range scenario so responders can rehearse revoking the key, reverting the webhook, and scoping the phishing exposure.