SPF needs to be configured for each domain. While you can use wildcards, this effectively creates all the possible sub-domains that match the wildcard. It is rare you would want to use wildcards. SPF does not apply to
PTR records, and your
NS domains typically shouldn't be sending email.
If you want to protect domains which should not be sending email from being used to send spam, use an SPF record like
v=spf1 -all. I would recommend doing so, but many domains do not have this coverage. (I seen many of them being rejected by my spam filter.) This should include web domains which some spammers tend to prefer.
The domain used in the envelope from address,
Sender:, and similar headers should have an SPF record like
v=spf1 a mx -all. This will cause problems for senders using other SMTP servers to send email from your domain. SPF will be applied to the envelope from address which in most cases should match one of the sender address headers.
If you want to allow other SMTP servers to send on behalf of your domain you can use the
include mechanism. There are limits to the number of domain lookups that can be applied, so deep nesting with mechanisms like
MX may cause the check to be fail before all mechanisms are completed. Your are also likely to import a
~all mechanism which will significantly defeat the purpose of using SPF.
Setting up your SMTP server to accept authenticated connections from your users on the Submisssion port (587) will allow them to use your mail server to send email. The Submission port should be configured to enable StartTLS. Authentication should require TLS.
Your SMTP server should have an SPF record allowing it to send email. A record like
v=spf1 a -all would be appropriate.
Consider looking at
DMARC which will allow you to publish a policy on how email SPF and DKIM should be handled. You can also receive feedback on how well your domain is meeting your policies. This can include indications that your domain is being used to send Spam.