A sending account that is not yours any more

Somebody has your marketing platform credentials and is sending as you. The mail passes SPF, passes DKIM, aligns, and satisfies your p=reject policy completely — because it is coming from infrastructure you authorised.

Why none of your controls help

SPF     the platform's IPs are in your record.  pass
DKIM    the platform signs with your domain.    pass
DMARC   aligned on both.                        pass
BIMI    your logo appears next to it.

Every control you deployed is working exactly as
designed. They authenticate the sender, and the
sender is the platform, and the platform is doing
what its authenticated user told it to.

The response

Stop the sending, at the platform. Their support, their kill switch, their account suspension. This is the only thing that ends it, and everything else is secondary.
Rotate the platform credentials and revoke sessions. Including API keys, which are frequently how the access persists after a password change.
Only then consider DNS. Removing the platform’s SPF include and DKIM selector does end their ability to authenticate — and it also ends your legitimate mail through them, and it takes a TTL to propagate while the platform can send immediately.
Preserve evidence before it is deleted. Campaign records, recipient lists and sending logs live in the platform, and a support intervention may remove your access to them.
Assess the data, not just the mail. A marketing platform holds your customer list. The outbound campaign may be the smaller half of the incident.

When pulling DNS is right

If the platform will not or cannot act quickly, removing the include and the selector is the only lever you hold. Accept that it stops your own mail through them, and that a cached SPF record and a cached DKIM key both keep working for their TTL — so it is slower than it feels.

This is the cost of every third-party sender

Authorising a platform to sign as you means its account security is now part of your domain’s security, and you have no visibility into it. That is the argument for per-vendor selectors, for removing vendors promptly at offboarding, and for enforcing multi-factor authentication on every platform that can send as you — which is a control on their console, not in your DNS.

Knowledge check

Why is removing the platform’s SPF include and DKIM selector not the first action?

It stops your legitimate mail through that platform, takes a TTL to propagate, and does not stop the attacker sending in the meantime — only the platform can do that immediately.
Because the attacker would notice and switch to another platform.
Because DNS changes require a change window and the platform does not.
Because it would break DMARC for the whole domain.

Correct — It stops your legitimate mail through that platform, takes a TTL to propagate, and does not stop the attacker sending in the meantime — only the platform can do that immediately. Containment lives at the platform, which can suspend the account in seconds. DNS is the lever you reach for when they will not act, and it is slower and more damaging than it appears.

Not this — Because the attacker would notice and switch to another platform. They may well, and that is not the reason. The reason is that the DNS change is slow and costs you your own mail.

Not this — Because DNS changes require a change window and the platform does not. Process friction is real and secondary. Even with instant DNS access, the propagation delay and the self-inflicted outage remain.

Not this — Because it would break DMARC for the whole domain. Removing one sender’s authorisation does not break the domain’s policy. It breaks that sender’s mail, which is partly the point.

Why none of your controls help

The response

When pulling DNS is right

Try it on a real domain