What requirements should a denotational semantics for a programming language satisfy to be correct? We have a programming language and its denotational semantic, 
like Tony Hoare's CSP with its syntax and denotational semantic 
e.g. stable failure and UTP. 

We want to extend the language (its syntax and semantics) by
adding new operators to the language. 
After given an informal definition for each new operator, 
we want to provide a denotational semantic for the extended language.

We have been told that 


the denotational semantic must be a domain, 
the denotational semantic must distinguish what your language want to distinguish intuitively, 
the denotational semantic must be consistent with its operational semantic or algebraic semantic.


What requirements should our denotational semantics for the extended language satisfy to be correct?
Are there any criteria to distinguish between correct and incorrect denotational semantic for a programming language?
What I am writing is essentially contained in babou's answer. 
But I wanted to express it a bit differently 
emphasizing the point of defining formal semantics.

A formal semantics is a mapping from one class of mathematical structures $P$ 
(e.g. programs in a programming language) 
to another class of mathematical structure $S$ (e.g. domains):
$[[ \cdot]] : P \to S$.

Different conditions required from the mapping give different kinds of semantics.

What conditions should we require from the mapping? 
That depends on what we want to do with the semantics.
The required denotational properties depend on 
what your intention is in extending the language, 
a formal semantics might be wrong or right depending on that intention.

Let's step back for a second and look more generally why we define formal semantics.


  The point of formal semantics is that 
  we take the class of mathematical structures that we want to study and 
  map it to another class of mathematical structures that we already know something about, and we use that knowledge to study the original class of structures. 


If you don't know what denotational properties you require from your denotational semantics of your language and have no use for it, 
what is the point of to providing a denotational semantics?
It will not add any confidence that your extended language will behave as you want.

On the other hand, 
if you know how the denotational semantics should be
based on your intuitive informal semantics and your intention in extending the language,
then you can use that to formally check that 
your programming language matches your intuitive semantics and 
will work as you intended 
(w.r.t. the requirements you had for your denotational semantics).