Atestan Atestan

Verified business communications

Fraud works on a person, not on a system

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.


This is not another email-security tool

Microsoft and Google already check that an email really came from the domain it claims, and they do it well. Atestan does not replace those checks. It starts where they stop.

Payment request

Company X → your company

Change of bank details

Can this request be trusted?

Example · fictional company

Where email checks stop

Every email check can pass, the domain is right, the signature is right, the mailbox really is theirs, and the instruction inside can still have been written by someone who broke in. Email checks answer where a message came from. They were never built to answer whether this request was meant.

Two different questions

What email checks prove

Did this message really come from that domain?

Email checks (SPF, DKIM, DMARC) answer yes or no about the domain. That is a real and necessary check, and Atestan expects it to have run already.

What Atestan proves

Does <em>this exact request</em> carry proof from the organisation it names, for this recipient, with this content?

A different question: not who owns the domain, but whether the organisation sealed this exact request.

The case that tells them apart

An attacker who breaks into a real mailbox sends from a real domain. Email checks say: genuine. Atestan says: this request does not carry the proof the organisation itself asks for. Proving who owns the domain and proving the organisation meant this request are two different things.

The question is narrower

What evidence is there that this particular request was meant, intended for this recipient, and handled as claimed? That matters most when one wrong action is expensive, and it is a different question from the one email checks were built to answer.

Atestan adds to the controls you already run, email checks, multi-factor sign-in, identity systems and two-person approval. It replaces none of them.

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.

  1. Whether the request carries proof it came from the organisation it names, or only an address that looks like theirs. Atestan proves the ORGANISATION, not the person: it does not say that a named director sent it.

  2. Whether it was addressed to your organisation on the day it was sent, not a copy that anyone who got hold of it could reuse.

  3. Whether the company it names actually received it.

  4. Whether what it asks for was actually carried out.

  5. Whether all of it can be re-checked months later by someone who trusts neither side.

Rules posted in advance

A company posts its rules in advance

A company posts in advance the kinds of request it always seals, like the opening hours on a shop door: you do not need a request in hand to read what the company has committed to. The posted rules give the person receiving a request something independent to check it against. The request says what is being asked; the rules say what the company has promised to seal.

The rules live at their own address, one page per company, readable with no code, no account and no request in hand.

https://verify.atestan.com/p/…

Made for a decision, not for reassurance

The aim is not to replace judgement with a green label. It shows the difference between two things that look alike: “this came from the supplier’s mailbox” and “here is proof of who sealed this request, and for whom”. That difference is why the product exists, and it is why an incomplete proof is shown as incomplete, never rounded up.

A trust layer above Microsoft 365 and Google Workspace. We are not an email provider, and we never will be.