Be careful with doing this, be sure you understand the implications of simply copy/pasting such an SPF record. For most situations, your MX (which is inbound e

Be careful with doing this, be sure you understand the implications of simply copy/pasting such an SPF record. For most situations, your MX (which is inbound email) may not necessarily be sending (outbound) email. For example: when using O365 or Google Workspace (Gmail), then these are always separated. You need to use the 'include' mechanism for your email inbox providers, and not the 'mx' mechanism. Leaving the 'mx' mechanism in your SPF when it is not required is rather expensive as it causes an additional DNS lookup, and you can only have 10 additional lookups in an SPF policy. The 'a' is also an additional lookup, and may not always be applicable. The host pointed to by the 'a' record may not (and probably should not) be sending email. In parent's example there is a Keycloak server running on the host pointed to by the 'a' record. It would better configure Keycloak to user a 'real' SMTP server, instead of attempting to deliver the confirmation emails directly from your host. Also, you really should enable DKIM signing for those emails, never rely on SPF for such critical emails. Lastly, using the '-all' default can be dangerous when you are just setting up SPF for the first time. You may end up blocking a lot of your own (legitimate) email. When SPF is combined with DMARC, it is even recommended to never use '-all' at all. https://www.mailhardener.com/blog/why-mailhardener-recommends-spf-softfail-over-fail https://www.mailhardener.com/blog/why-mailhardener-recommend... TL;DR: Don't just blatantly copy/paste an SPF example, be sure to understand what you are doing, or you may end up hurting your email deliverability. There are many good resources online on the subject, such as https://www.mailhardener.com/kb/spf https://www.mailhardener.com/kb/spf (disclaimer: I work at Mailhardener)