Security, Spoofing and Account Compromise

First 15 minutes

1. Preserve raw headers and obtain the Message-ID for message tracing.
2. Review unified audit events and sign-in source-IP context for the suspected account.
3. Suspend a suspected compromised Google Workspace user to reset sign-in cookies and OAuth tokens.

Now

• Suspend a suspected compromised Google Workspace user so current sign-in cookies and OAuth tokens are reset.

Next 24 hours

• Keep the suspected account suspended while its reset sign-in cookies and OAuth tokens are treated as invalidated credentials.

Next 7 days

• Add the documented user-suspension control to the response procedure for future suspected Google Workspace compromise.

Technical checks

Verification criteria

• Message trace identifies the original source and intended recipients for the preserved Message-ID.
• Audit and sign-in records either corroborate expected account activity or identify unauthorized activity requiring containment.

Escalation criteria

• Escalate to security when audit or sign-in records show activity or source IPs that the account owner cannot explain.
• Escalate to the Google Workspace administrator when a suspected user must be suspended to reset sessions and OAuth tokens.

Prevention

• Define which Authentication-Results writers are inside the trusted receiving boundary.
• Retain and review account audit and sign-in evidence with sufficient permissions for compromise investigations.

Business impact

• A suspected compromised account can require suspension that resets its active sign-in cookies and OAuth tokens.
• Audit and sign-in evidence can expose user or administrator activity that requires a security response.

Provider notes

• Microsoft 365 supplies message trace, unified audit, and Entra sign-in evidence only when the relevant logging, retention, and permissions are available.

Open questions

• No raw headers, trusted Authentication-Results, message trace, audit events, or sign-in events were supplied, so spoofing versus compromise remains unresolved.
• A passing authentication result does not by itself establish that the human sender controlled the account at send time.
• Log names, retention, and containment controls differ between mailbox providers.

First 15 minutes

1. Group suspicious streams from DMARC aggregate reports by authentication result, disposition, and identifier.
2. Preserve raw headers and use Microsoft 365 message trace to identify source, recipients, and Message-ID for suspicious examples.

Now

• Apply Microsoft Defender anti-spoofing and domain-impersonation protections to affected recipients or domains.

Next 24 hours

• Inventory legitimate senders and align them before expanding DMARC enforcement.

Next 7 days

• Start at p=none, review reports for a week, then apply quarantine to a small percentage before broader enforcement.

Technical checks

Verification criteria

• Aggregate reports show that known legitimate streams pass DMARC through aligned SPF or DKIM.
• Receiver-local policy differences are recorded rather than treated as evidence of uniform enforcement.

Escalation criteria

• Escalate to security when message trace identifies active suspicious sources or targeted recipients.
• Escalate to the Microsoft 365 security owner when affected recipients need anti-spoofing or domain-impersonation policy coverage.

Prevention

• Maintain staged DMARC enforcement with report review and authenticated, aligned legitimate senders.
• Keep anti-spoofing and domain-impersonation protections assigned to relevant Microsoft 365 recipients or domains.

Business impact

• Specified recipients or domains can remain exposed to spoofing and domain impersonation until anti-phishing protections cover them.

Provider notes

• The staged DMARC sequence is Google guidance, while message trace and anti-phishing controls described here are Microsoft 365 features.

Open questions

• The current DMARC policy, affected recipient providers, suspicious source IPs, and inventory of authorized third-party senders are not supplied.
• Receiver enforcement and local policy vary, so publishing p=reject cannot guarantee identical handling everywhere.
• Same-domain spoofing controls do not establish whether a lookalike-domain or compromised-account campaign is also active.

First 15 minutes

1. Group aggregate-report rows by source IP, authentication result, disposition, identifier, and message count.
2. Classify forwarding and known third-party senders before labeling a DMARC failure malicious.

Now

• Keep policy at the current stage while daily report review classifies legitimate and unrecognized sources.

Next 24 hours

• Correct authentication and identifier alignment for legitimate sending services before enforcement expands.

Next 7 days

• Move gradually from p=none through partial quarantine toward broader enforcement only after legitimate services align.

Technical checks

Verification criteria

• Aggregate reports provide classified authentication, disposition, identifier, and count records for the reviewed sources.
• Aggregate reports identify authentication results and dispositions for the legitimate streams under review.
• Receiver overrides are documented so policy publication is not mistaken for uniform message rejection.

Escalation criteria

• Escalate to security when aggregate reports contain unrecognized sources after forwarding and authorized third-party senders are excluded.
• Escalate to the sender owner when a known service fails authentication or identifier alignment.

Prevention

• Review DMARC aggregate reports daily while policy is staged and legitimate senders are being aligned.
• Require DKIM signing identifiers to align with the visible author domain for DMARC authentication.

Business impact

• A DMARC failure does not establish whether every affected message was rejected because receivers can override the published policy.

Provider notes

• Google's staged guidance moves from p=none through partial quarantine toward broader enforcement, and p=reject instructs honoring receivers to reject DMARC failures.

Open questions

• The report's source IPs, counts, header-from domain, SPF/DKIM domains, policy disposition, and authorized-sender inventory are not supplied.
• A DMARC failure can represent forwarding or a misaligned authorized sender, so malicious spoofing is not proven until sources are classified.
• Receiver participation and policy enforcement vary; aggregate reports do not cover every receiver or prove uniform blocking.

First 15 minutes

1. Treat any possible public exposure as sufficient reason to begin replacing and deleting the key.
2. Review account settings, API keys, teammates, IP access management, webhooks, and subusers for suspicious changes.

Now

• Replace and delete the exposed key, however brief the exposure was.

Next 24 hours

• Reduce the replacement key to only the API endpoint scopes its integration needs.

Next 7 days

• Audit other SendGrid API keys and narrow any permissions that exceed their intended integrations.

Technical checks

Verification criteria

• A non-destructive request with the replacement succeeds only for its intended integration and authorized scopes.
• After the small propagation delay, the same safe authentication check with the deleted key fails.

Escalation criteria

• Escalate to security and SendGrid support if the account review finds unauthorized sends, teammates, webhooks, subusers, API keys, or settings.

Prevention

• Issue API keys with only the endpoint scopes required by each integration.
• Maintain reviewable inventories of account settings, keys, teammates, IP access controls, webhooks, and subusers.

Business impact

• Unauthorized use can send phishing, spoofing, or spam through the account and damage the sender's reputation.

Provider notes

• A revoked SendGrid v3 API key can require a small propagation delay before authentication fails.

Open questions

• The exposure start time, repositories or logs containing the key, and every integration that used it are not available.
• Whether the key was used for unauthorized sends or account changes must be determined from tenant activity and mail evidence.

First 15 minutes

1. Preserve suspicious headers and compare the author domain with authenticated SPF and DKIM identifiers for DMARC alignment.
2. Check domain registration and account evidence to classify exact-domain failure, lookalike impersonation, display-name deception, or account compromise.
3. Review available DMARC aggregate reports for unknown, unaligned, or unauthenticated sources using the author domain.

Now

• If the domain is still in DMARC monitoring mode, keep it there while legitimate unaligned or unauthenticated streams are identified and remediated; do not reduce an existing enforcement policy on this evidence.

Next 24 hours

• For licensed Microsoft Defender tenants, enable the relevant domain or user impersonation detections and choose an appropriate junk, quarantine, or delete action.

Next 7 days

• After checking the observed current policy and assessing legitimate direct and indirect paths, decide whether a domain still in monitoring mode should move toward enforcement; preserve any existing enforcement state unless separately justified.

Technical checks

Verification criteria

• Available DMARC aggregate reports account for expected author-domain sources and identify any remaining unaligned or unauthenticated streams, recognizing that not every receiver reports.
• In a licensed, configured Microsoft Defender tenant, a controlled impersonation test receives the selected junk, quarantine, or delete action.

Escalation criteria

• Escalate to security when evidence identifies a lookalike-domain campaign, and to the Microsoft security administrator when configured impersonation actions do not apply in a licensed tenant.

Prevention

• Remediate legitimate unaligned sources before advancing DMARC enforcement, and maintain receiver-side impersonation controls where licensed and configured.

Business impact

• Recipients can receive a deceptive lookalike-domain message that passes SPF, DKIM, and DMARC for the attacker's own domain.

Provider notes

• Microsoft Defender for Office 365 can supplement authentication with domain or user impersonation detection and junk, quarantine, or delete actions when licensed and configured.

Open questions

• No suspicious message headers, sending-domain registration data, account audit trail, or DMARC aggregate sample was supplied, so the attack class is unresolved.
• Impersonation controls, licensing, and enforcement behavior vary by receiving provider and tenant configuration.

First 15 minutes

1. Inventory applications that depend on each exposed key, issue and deploy a permission-scoped replacement, verify every dependent application, and then delete the exposed key; if active abuse is observed, revoke the exposed key immediately and complete the dependency migration as emergency recovery.
2. Review recent UI, API, and SMTP access attempts, then confirm that every current teammate still needs the granted access.

Now

• Inventory dependencies, issue and deploy a permission-scoped replacement, verify dependent applications, and then delete each exposed key; if active abuse is observed, revoke the exposed key immediately and complete replacement as emergency recovery.

Next 24 hours

• Confirm each inventoried application uses the permission-scoped replacement and verify two-factor authentication for users.

Next 7 days

• Tighten Teammate access so each person retains only the features needed for the job.

Technical checks

Verification criteria

• The compromised key is absent, the permission-scoped replacement works in each inventoried application, and dependent environment variables are updated.
• Recent access-attempt records have been reviewed and two-factor authentication is enforced for every SendGrid user.

Escalation criteria

• Escalate to SendGrid support and the security team when access-attempt data or sending history indicates account takeover or abusive sending.

Prevention

• Maintain a tested response that replaces and deletes every publicly exposed API key.
• Require two-factor authentication and review Teammate permissions regularly.

Business impact

• Unauthorized use of the account can expose recipients to abusive mail and damage the sender reputation used by legitimate business messages.

Provider notes

• SendGrid IP Access Management covers UI, API, and SMTP relay access, but an incorrect allowlist can lock out legitimate users.

Open questions

• No current provider advisory, account notification, or affected-artifact list is supplied, so the specific incident scope cannot be inferred from the question.
• Whether API keys, user credentials, teammates, sending domains, templates, lists, or webhook secrets were exposed requires the provider notice and tenant audit data.
• A send pause is conditional on evidence of unauthorized access or sending; current SendGrid security documentation does not prescribe a universal pause after every provider incident.

First 15 minutes

1. Check every authenticated domain in the account and identify whether its 2021 configuration used automatic or manual security.
2. Identify whether each affected domain used automatic or manual security and check every domain in the account.

Now

• Begin the documented replacement-authentication sequence for each affected manual-security domain.

Next 24 hours

• Create replacement authentication with a previously unused selector, publish and validate its DNS records, then delete the original manual authentication.

Next 7 days

• Record completion only after the replacement validates and signing continuity is preserved.

Technical checks

Verification criteria

• Every affected manual domain has a validated replacement authentication and DNS record set before its original configuration is deleted.
• Each manual replacement uses a new selector and has validated DNS records before the original configuration is deleted.

Escalation criteria

• Escalate to Twilio SendGrid and security when affected-customer status or the security mode of any authenticated domain cannot be reconciled.

Prevention

• Maintain a complete inventory of authenticated domains, selectors, and automatic versus manual security modes.
• Require replacement validation before deleting an existing manual domain authentication.

Business impact

• An unresolved exposure of a private DKIM key leaves trust in the affected domain authentication in question until the tenant-specific rotation status is verified.

Provider notes

• Twilio reported that an unauthenticated Redis cache containing some customers' private DKIM keys was publicly accessible for four days in June 2021.
• Twilio's investigation reported no indication of unauthorized access, which is not proof that access was impossible.

Open questions

• The advisory says directly impacted customers were emailed; the question does not establish whether this tenant received that notification.
• The account's current list of authenticated domains and whether each used automatic or manual security in 2021 are not supplied.
• Twilio reported no indication of unauthorized access as of its investigation; tenant-specific abuse cannot be ruled in or out without historical logs and key-use evidence.