... or am I arguing an authentication technology that was never prepared for Cloud driven services?
SPF non è davvero una tecnologia di autenticazione. Non autentica chi sta inviando la posta ma solo i limiti da cui gli indirizzi IP possono essere inviati dalla posta e quindi cerca di limitare l'uso improprio del tuo dominio come mittente rivendicato di spam e phishing.
If they gave me companyx.amazonses.com I would be a tad more interested in including this.
Non c'è motivo di credere che questo sarebbe più sicuro solo perché il nome della società è incluso nel nome del dominio. La vera domanda è quali indirizzi IP sono coperti dal SPF (cioè autorizzato a inviare posta per questo dominio) e si potrebbe semplicemente impostare questo "record aziendale" per essere uguale al record globale di amazonaws.
Se usi il cloud per inviare posta, di solito lo fai per trarne vantaggio, cioè flessibilità, scalabilità, tolleranza agli errori, bassa latenza dovuta al routing geografico ecc. Ma, per implementare questi vantaggi, potrebbe essere necessario avere molti indirizzi IP ed essere flessibile in cui le attività sono assegnate a quale indirizzo IP.
Questo significa che l'indirizzo IP potrebbe essere un'ancora di fiducia eccessivamente ampia quando si utilizza l'infrastruttura cloud. Invece o in aggiunta si dovrebbe fare affidamento su specifiche specifiche del sistema, piuttosto che specifiche IP. Questo può essere fatto usando DKIM dove il sistema di posta in uscita firma la posta e il destinatario può verificare che sia stato effettivamente firmato dal sistema di posta appartenente al mittente. Entrambi i formati DKIM e SPF possono essere combinati con DMARC per una protezione ancora migliore contro l'utilizzo improprio del nome di dominio per spamming e phishing.
In breve: non lamentarsi del fatto che SPF sia insufficiente e non progettato per il cloud. Utilizza invece DKIM e DMARC oltre a SPF.