When mail from one external sender stops arriving while everything else works,
quarantine is the first place to look — and the reason a message was held is the
diagnosis.
The three authentication mechanisms
- SPF — the sending domain publishes which IP addresses may send on its behalf.
A message from an IP not on that list fails SPF.
- DKIM — the sender signs the message. A valid signature proves the message was
not altered and genuinely came from a holder of the domain's key.
- DMARC — the sending domain publishes what receivers should do when SPF and
DKIM both fail to align with the visible From: address: none, quarantine, or
reject.
Read the Authentication-Results header. It tells you which mechanism failed and
what the sender asked you to do about it:
Authentication-Results: spf=fail (sender IP is 203.0.113.88)
smtp.mailfrom=nordwind.example;
dkim=pass (signature was verified) header.d=nordwind.example;
dmarc=fail action=quarantine header.from=nordwind.example;
compauth=fail reason=000That example is a sender-side misconfiguration, not an attack: DKIM passes, so
the message really is from them, but they are sending from an IP their own SPF
record does not cover. Their own DMARC policy told Exchange Online Protection to
quarantine it. The service did exactly as instructed.
Deciding whether to release
Never release on the strength of "the user says they were expecting it." Check:
- Does DKIM pass? A valid signature from the claimed domain is strong evidence
of authenticity.
- Does the sending infrastructure make sense? A supplier who has just changed
mail provider explains an SPF failure. A consumer webmail IP claiming to be a
corporate domain does not.
- What is the content asking for? Payment details, bank changes, urgency,
credentials, or an unexpected attachment shift the balance sharply.
- Is this consistent with previous mail from them? Compare against delivered
messages in the trace.
Release specific messages by ID, and report false positives to Microsoft so the
filters learn. Record the justification in the ticket.
A quarantined invoice during a live payment run is precisely the scenario
invoice-fraud campaigns are built around. Slow down at exactly this point.
Why not just allow the domain
Adding a domain to the tenant allow list disables authentication checks for that
domain — which is the same domain an attacker would spoof to reach your finance
team. It converts a temporary sender-side fault into a permanent hole.
The durable fix belongs to the sender: they add their new sending hosts to their SPF
record, or fix DKIM alignment. Tell them, in writing, what failed. Release the held
messages in the meantime so business continues.
If a temporary allow really is required, it is a security change with an owner, a
justification and an expiry date — not a service desk action.
Related
- Running a message trace
- Triaging a reported phishing message
- Responding to a compromised account