A source IP can identify a transport path without identifying the customer authorized to use a particular domain. Shared services put unrelated tenants behind common infrastructure. Keep transport origin, tenant authorization, signing identity and human responsibility separate. A valid domain signature is important evidence, but an upstream authorization error can allow the wrong request to reach the signer.
State the threat model and historical evidence
The risk considered here is a relay trusting a broad provider source without binding that source to the customer allowed to use its signing route. The attacker in the model controls a different tenant on the same shared service, not the brand's private key. The affected assets are authorized domain use and the accuracy of later attribution. This is a historical failure class, not a claim that a named service is currently vulnerable.
Guardio Labs' original EchoSpoofing report, published by Nati Tal on July 29, 2024, describes abuse through Microsoft 365 and Proofpoint routing in which unauthorized messages acquired legitimate authentication. Its disclosure section describes tenant-specific filtering as a mitigation and discusses the provenance of tenant metadata. Original research. The written comparison below illustrates that boundary; it neither reproduces the exploit nor evaluates current vendor implementations.
Keep attribution fields separate
SMTP observations describe message handling, while DKIM associates a message with a signing domain. Neither alone establishes the person who composed or approved a business request. RFC 5321 and RFC 6376. Preserve the trusted receive time, connecting source, tenant evidence where available, From domain and verified signing domain as distinct fields.
Tenant evidence must come from an established trusted boundary. An arbitrary message header claiming an allowed tenant is not equivalent to verified transport context. Authentication-Results fields similarly require a trusted origin. RFC 8601. A deployment review must establish how a service authenticates and protects that context rather than merely checking whether a field exists.
Compare five hypothetical authorization cases
Assume a deliberately broad rule permits any request from source-family shared-A. A proposed narrower rule also requires independently trusted tenant context equal to tenant-good. These are written rule assumptions, not running code or vendor configuration.
- Case1: shared-A; trusted tenant tenant-good; message claim tenant-good. Both proposed rules admit the request.
- Case2: shared-A; trusted tenant tenant-other; message claim tenant-other. The broad rule admits; the tenant-bound rule denies.
- Case3: shared-A; trusted tenant tenant-other; message claim tenant-good. The broad rule admits; the tenant-bound rule denies despite the untrusted claim.
- Case4: shared-A; trusted tenant unavailable; message claim tenant-good. The broad rule admits; the tenant-bound rule denies for missing evidence.
- Case5: outside-family; trusted tenant tenant-good; message claim tenant-good. Both rules deny because the source-family condition is not met.
In the thought experiment, an admitted request could reach a downstream signer. No key was generated, message signed, cryptographic check run or SMTP request sent for this teaching revision. The admission decision is not a DMARC verdict or proof of delivery.
Verify the trusted context rather than its label
The trusted-tenant field above is a premise, not a demonstrated security mechanism. A real deployment must establish how that context is authenticated and protected from message-controlled overrides, including how missing context is handled. The historical report does not prove that today’s configuration is exposed. Use current vendor guidance and approved route evidence to evaluate actual signing authorization; never treat an arbitrary header as trusted merely because its name resembles a vendor field.
Correlate before naming a responsible party
For an incident, join original messages with authorized time-specific route and account logs. A shared relay address and valid signature can coexist with an authorization defect, account abuse or a legitimate sender; those explanations require different evidence. Keep containment decisions separate from accusations. Request provider investigation through approved channels when tenant-level attribution is necessary, sharing only relevant identifiers and times.
Close with observed facts, confidence, missing account evidence and the next accountable action. The defensible finding may identify an authenticated domain and shared route while leaving the actor unresolved. That is more useful than assigning responsibility to a company solely because its mail used the same infrastructure.
Keep findings within the evidence
The examples are defensive decision aids, not observed allegations against real people or current providers. Retain authentication evidence, business verification and attribution separately. Current protocol sources describe domain validation and trusted result boundaries; they do not supply the missing account evidence or authorize publication of an accusation.