<p>You need to have separate SPF records for each subdomain you wish to send mail from.</p>
<p>The following was originally posted on <a href="http://openspf.org">openspf.org</a>, which used to be a great resource for this kind of thing.</p>
<p>Latest link <a href="http://www.open-spf.org/FAQ/The_demon_question/">http://www.open-spf.org/FAQ/The_demon_question/</a></p>
<blockquote></blockquote>
<p>The Demon Question: What about subdomains?</p>
<p>If I get mail from<br>
<a href="http://pielovers.demon.co.uk">pielovers.demon.co.uk</a>, and there’s no SPF data for pielovers, should I<br>
go back one level and test SPF for <a href="http://demon.co.uk">demon.co.uk</a>? No. Each subdomain at<br>
Demon is a different customer, and each customer might have their own<br>
policy. It wouldn’t make sense for Demon’s policy to apply to all its<br>
customers by default; if Demon wants to do that, it can set up SPF<br>
records for each subdomain.</p>
<p>So the advice to SPF publishers is this: you should add an SPF record<br>
for each subdomain or hostname that has an A or MX record.</p>
<p>Sites with wildcard A or MX records should also have a wildcard SPF<br>
record, of the form: * IN TXT “v=spf1 -all”</p>
<p>This makes sense - a subdomain may very well be in a different geographical location and have a very different SPF definition.</p>
<p>The ‘include:’ directive for SPF may be used to provide all subdomains with the same entries. For example, on the SPF record for subdomain <a href="http://mailfrom.example.com">mailfrom.example.com</a> enter ‘include:example.com’. In this fashion whenever you update the definition for <a href="http://example.com">example.com</a> your subdomains will automatically pick up the updated values.</p>
