I'm assuming that an "external message" is something that's coming over a network protocol, e.g. RPC, SOAP, Protocol Buffers, etc.
In that case, it's absolutely a good thing to maintain two separate models. One for messaging, one for domain. It's not unusual to have yet another model for presentation and another model for data.
It seems awfully repetitive, but there are plenty of automapping tools that can reduce the effort to near-nil; in .NET we have AutoMapper, in Java there's Dozer, etc.
More importantly, the alternative is an obnoxious, bloated canonical model which forces everything that touches it to deal with all of the bizarre idiosyncracies of everything else that touches it. When you need to map between models, you usually have the ability to do versioning (choose sane defaults for new fields), but when you have a single shared model... forget about recompiling just one application, you have to rebuild and redeploy your entire architecture. This sucks when you have a distributed system.
Just because two classes have very similar structures does not mean one of them is redundant:
Domain models are "thick" models, meant to accurately model the real world and contain all or most of the business logic for your application. Encapsulation is king and domain objects emphasize behaviour over data.
Messaging models are by definition "thin" models containing nothing but data; in many cases a message has already been validated (in the case of an event message) or will have to be re-validated anyway (in the case of a command), so validation tends to be limited to the format of the message. In addition, the structure of one of these message models is almost always optimized for transmission efficiency (no unnecessary fields) and there may be several "metadata" attributes (like security headers) that would make no sense at all in any other model.
Data models are (traditionally) intended to provide a bridge to a DAL or ORM. Modern tools have gotten pretty good at aligning these with domain models but not nearly all of the way there. Generally there are a lot of annoying restrictions on a data model that also make no sense in a domain model, such as ID properties on every class, bidirectional references, setters on every property, and in some cases every member has to be virtual. The last two are especially problematic; most often you want your domain models to be immutable and sealed (not inheritable).
And finally the presentation model is likely to be much flatter than the domain model, have all sorts of formatting code, and mostly string properties (which have all manner of validation attached to them). Which fields are read-only will depend on the features that the UI is supposed to provide.
It's really, really hard, bordering on impossible, to keep all of these conflicting requirements in sync when trying to maintain an architecture-wide or even application-wide shared model.
Ultimately you will end up doing less work by having custom models with very few dependencies, as opposed to one model with a very high number of dependencies.