1

I have a question in regards to SPF records in a dedicated hosting environment. I wish to set up an SPF record for my dedicated server, but I am not sure whether my understanding is correct.

First question: Do I need to set up the SPF record for ONLY the domain holding the NS and PTR records, or do I need to set it up for each domain on the server?

If I only need to set it up for the NS domain, can it be set up on each domain to override the NS domain?

Also, if it is just for the NS domain, how can I ensure my clients with remote SMTP servers have no issues sending emails? ie. Google Apps or external MX records.

eg: My NS domain is example.com and one of my clients are helloworld.com Am I required to set an SPF record up on helloworld.com, example.com or both? Will the SPF record on example.com affect helloworld.com if I do not put an SPF record on helloworld.com?

Shane
  • 13

2 Answers2

3

(Answer edited in the light of edits to the question.)

It depends. SPF records should be applied to the envelope From, not the header From:. If your server is using SRS, everything should be fine; the envelope From will be rewritten to example.com, and your SPF record will cover it. Otherwise, it will depend on what their MUAs (and/or in-house mail servers) set the envelope From to be; if that's helloworld.com, then yes, their SPF record (if it exists) will need to permit your infrastructure to send.

That said, if they are your clients, there's no harm in them including you in their SPF records, which they can do with a simple include:. Better safe than sorry, and don't forget to keep an eye on the DNS lookups limit.

As to the last part of your question, you should probably read our canonical question on setting up SPF records.

MadHatter
  • 81,580
1

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, From:, 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 A or 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.

BillThor
  • 28,293
  • 3
  • 39
  • 70