Use CNAME for SMTP Server

You're looking at the wrong things. Those are the message headers. You should be looking at the SMTP envelope. (How the envelope is specified depends from how, exactly, your application is submitting mail to the mail system. On many systems the envelope is specified by command-line arguments to the mail submission utility program.) Depending from exactly when in the protocol transaction it decides to issue that 571 response, the SMTP Relay server may not have even seen the message headers at all.

The response text is saying that the administrator of that particular SMTP Relay server you are talking to has restricted what you can put in the SMTP envelope. It appears to be complaining about the recipient part of the envelope. But it may be deferring validation of the envelope sender until specification of the first recipient, so it may be complaining about the sender.

Note that the envelope sender is where delivery status messages are sent, and you'll not want to have those directed to random people around the world. (Aside from the fact that many people don't like this, it makes no sense for delivery status messages for your mail to be returned to anyone but you.) Specify yourself as the envelope sender.

It is wrong to require MX resource records, by the way. An SMTP Relay server can be located by A and AAAA resource records in the absence of any MX resource records. See RFC 5321 § 5.1.

Assuming that the apex A record for example.com. was pointing at a broken IP address, most companies I know would change the A record and skip the www change entirely:

• Most admins would rather not have their website broken for users who key in the name of the website without the www prefix.
• This goes double for admins who don't trust their webapp devs to consistently use www.example.com over example.com. (hint: most of us don't)

Moving on to your linked example, you're comparing apples and oranges. Apex DNS records in web hosting scenarios are a massive pain because of the well-known apex CNAME problem. There are only two correct choices in this circumstance: either the apex A record is changed as necessary to point it at a valid IP, or you forgo having an apex record entirely. Anything between the two is half-baked and inconsistent.

All of this is somewhat beside the point though: if you are relying on manual record changes to handle high availability for your service, you are doing something wrong. The IP address the web browser hits should be a load balancer, an anycast address, a CDN, or a webhosting provider who can provide this high availability if your own server farms cannot. Multiple address records can also work if you're confident that the primary applications consuming them follow follow RFC 6724 guidelines (i.e. most popular web browsers), but many applications are lazy and simply use the first address record returned.

For the sake of the argument, let's examine Google's CNAME chain on its own merits without putting it into the context of your original problem. This will look familiar, as it's the text of my original answer:

Record type is inconsequential here. If the record needs to be changed frequently, it should have a very low TTL. If it doesn't need to be changed frequently, it stands to reason that it doesn't need a low TTL and you can use whatever you're comfortable with.

No one (other than Google) can really comment on why Google wants ghs.l.google.com IN A to have a lower TTL than the CNAME records pointing at it. You can't draw any conclusions without understanding their larger design, and the design is what dictates your moving parts.