Domain-Driven Design and Object-Relational Mapping are two unrelated topics.
The sole purpose of an ORM is to fill the gap between an object model and the relational data model present in your database, whatever object model.
An entity, as described by EF, is just something to which you want to map a certain section of your relational model (and from). It turns out that the Entities name was an attempt by the EF developers to give those a corporate connotation, but ultimately nothing drives you in that direction. For all it cares, you could map to View Models.
There is no such thing as "an Entity developed with EF in mind" from a DDD standpoint. A DDD Entity should have no ORM traces and be persistent ignorant. How, where, whether, or when the domain layer's objects are kept is unimportant.
between the two
The only moment where the two orthogonal ideas intersect is when the object model targeted by your ORM mapping is precisely your domain model. By pointing to your DDD Entities in separate EF mapping files located in a non-domain layer and abstaining from utilizing EF artifacts such as data annotations directly in your Entity classes, this is achievable with what EF refers to as "Code first" (but should really be titled standard ORM). This is not feasible while using Database First since it would violate the DDD "purity" requirement.
In essence, the terms overlap, but philosophically they should be seen as two distinct concepts. One is the domain object itself, and the other is a pointer that can point to the same block of code or pretty much anything else, but it can also signify the same domain object.