Not even then, RFCs state that a CNAME may not exist with any other RR type, and your apex domain needs at least SOA and NS records.
A CNAME on the apex domain may kind of work, but it will present as broken in subtle and unexpected ways.
DKIM and DMARC can be CNAMES, many services already use this, at Fastmail for example for DKIM you setup CNAMES, and we manage DKIM keys for you.
SPF needs to be on your (root/organizational) domain, and you don't want (can't have) a CNAME there.
There are services which do that, but it doesn't work in every situation. It can't (for example) cope with SPF macros, which is where the server looking up the record can replace parts of the record it is requesting with variables from the SMTP session (for example, by inserting the connecting IP address into the record lookup domain). In short, as stated in the article "email is complicated"
SPF asserts that a given IP address is authorized to send mail from a particular envelope sender domain (the user typically does not see this domain)
An email with a user visible From address of [email protected] can have passing SPF from evil.com
DKIM asserts that the message contents have been sent by a particular domain (or domains), that domain does not necessarily relate to either the envelope sender domain, or the domain the user sees in the From address.
Again, an email from [email protected] can have a perfectly valid DKIM signature from phisher.com
DMARC is a policy layer over the top of these, which ties the domain the user actually sees in the From address back to those used in SPF and DKIM.
This is where the [email protected] email starts getting blocked. Neither the SPF nor DKIM of the email are "aligned with" whitehouse.gov, and we can start to do something about the spoofing.
"We set a specific header in the email called Return-Path with all emails sent through our email service. If you take a peek at a raw email sent over OhMySMTP you’ll find that the return path ends in @mailer.ohmysmtp.com, and if you look this up in the DNS system, you’ll find an SPF record that points to our server IP address."
While this will mean that and mail sent will pass SPF, it doesn't play well with DMARC. The SPF pass domain won't align with the From header domain, so the SPF authentication will be ignored.
"But SPF alone doesn’t completely solve spam, we also need DKIM, and to a lesser extent DMARC. More on those later!"
Realistically, SPF doesn't do anything to solve spam, nor does DKIM or DMARC. All of these technologies address spoofing and give a greater confidence of the sender responsible for the email which can then be used in reputation engines.
Passing SPF/DKIM/DMARC say nothing about the message contents.
The starttls-everywhere IP connects, tries a bunch of commands which don't look at all like a regular mail connection. It cycles through a bunch of tls settings and never sends an email.
In short, it got itself blocked by anti-spam measures.