Verified business communications
Verified business communications start with a different question
An email can be genuine and still contain a request nobody authorised. The mailbox may belong to the real supplier. The domain may be correct. The message may have passed every ordinary email-security control. And still, nobody at the supplier may have authorised the bank-detail change, the payment instruction or the contract amendment it contains.
01
This is not another email-authentication tool
Microsoft and Google already authenticate email, and they do it well. Atestan does not compete with SPF, DKIM, DMARC or Defender — it starts where they stop.
Payment request
ABC SAS → your company
Change of bank details
Can this request be trusted?
Example · fictional company
Every channel check can pass — the domain is right, the signature is right, the mailbox is genuinely theirs — and the instruction inside can still have been written by someone who got in. Channel checks answer where a message came from. They were never built to answer whether this request was meant.
What the channel proves
Is this message authenticated by the domain?
SPF, DKIM and DMARC answer yes or no about the domain. That is a real and necessary check, and Atestan assumes it has already run.
What Atestan proves
Was this precise communication authorised under the controls the issuing organisation itself defined — for this recipient, with this content?
A different question, one level up: not who owns the domain, but what the organisation authorised.
The case that separates them
An attacker who compromises a real mailbox sends from a real domain. DMARC says: authentic. Atestan says: this request does not carry the proof your policy requires. Identity authentication and authorisation of a communication are not the same property.
The question is narrower
What evidence exists that this particular request was authorised, intended for this recipient, and handled as claimed? That distinction matters most when the cost of one wrong action is high — and it is a different question from the one channel checks were built to answer.
Atestan adds to your business controls, MFA, IAM, DMARC/DKIM and dual-approval procedures. It replaces none of them.
02
The five questions Atestan asks about a payment request
In this order, and it stops where the proof stops. Two of the five are BUILT AND TESTED; the other three are specified and not built. And none of them answers a reader today: the service is running, but no organisation is enrolled and no seal has been issued, so the page establishes nothing for anyone yet — it says which is which every time it answers.
Whether the request carries a proof of origin from the organisation it names — or only an address that resembles theirs.
Built and testedWhether an internal instruction carries a proof of origin from your own organisation. Atestan establishes the ORGANISATION, not the individual: it does not say that a named director sent it.
Built and testedWhether the company it names actually received it.
Not yetWhether what it asks for was actually carried out.
Not yetWhether all of it can be re-checked months later by someone who trusts neither side.
Not yet
03
Published policy
The published policy — readable before any request arrives
An organisation publishes the categories of request it says it always seals. Think of the opening hours on a shop door: you do not need to be holding a particular request to read what the organisation commits to. That gives a recipient an independent reference point — the request says what is being asked; the published policy says what the organisation commits to sealing.
A published policy has its own address on the verification page, one page per domain — and reading it needs no code, no account and no request in hand.
https://verify.atestan.com/p/…04
Made for a decision, not for reassurance
The aim is not to replace judgement with a green label. It is to let the person deciding tell “this came from the supplier’s mailbox” apart from “here is what can be established about who sealed this request, and for whom”. That difference is the reason the product exists — and it is why an incomplete proof is shown as incomplete rather than rounded up.
A trust layer above Microsoft 365 and Google Workspace. We are not an email provider, and we never will be.