What this means is that if you have a DNS zone that contains DNS resource records (RR) such as MX, TXT, SRV in order to support email, TXT-based authentication strings, etc. you can NOT use a CNAME for the the zone apex.

A "zone apex" is where the SOA and NS (and often MX) records for a DNS zone are placed -- examples might include "foo.wisc.edu", "bar.wisc.edu", or "wisc.edu".

Example:

CNAME NOT allowed:

foo.wisc.edu CNAME other.hosted.service.cloud <-- NOT ALLOWED

foo.wisc.edu MX mta.wiscmail.wisc.edu

foo.wisc.edu TXT foo=bar

www.foo.wisc.edu CNAME other.hosted.service.cloud

* CNAME is not allowed as foo.wisc.edu is a zone apex, it contains MX and TXT DNS resource records.

Why?

RFC 1034 states:

The domain system provides such a feature using the canonical name
(CNAME) RR.  A CNAME RR identifies its owner name as an alias, and
specifies the corresponding canonical name in the RDATA section of the
RR.  If a CNAME RR is present at a node, no other data should be
present; this ensures that the data for a canonical name and its aliases
cannot be different.  This rule also insures that a cached CNAME can be
used without checking with an authoritative server for other RR types.

See also “Why can’t I have a CNAME at the zone apex?” 

See also RFC 1912 "Common DNS Operational and Configuration Errors".

Solutions:

Use an A-record for the zone apex.

Use redirection from another non-3rd-party host via A record for the apex.