Unfortunately, that's the point of SPF. If it "fails" the check, then your mail is generally adversely scored. There is a way of creating an SPF record to say "these are the approved servers, but they are not the only ones that might relay mail from this domain", but I personally think that defeats the purpose of SPF. But perhaps for the big mailers, what is known as a "soft fail" won't make much of a difference.
Regarding the question of allowing people to have a sender address of a particular domain, and yet be allowed to send mail from any random machine, as an email administrator, and in this day of endemic spam (at least 90% of the email sent around the world is spam), I have a strong aversion to the idea of any organisation allowing domain senders to use random servers which they do not control. I can't think of any spammers who use their own domains to send messages "from". By allowing your namespace to be potentially polluted (any sender address can be spoofed, but it's less likely that a target that doesn't seem so "easy" will be used - there's a lot less spam purporting to come from Hotmail senders these days), you open the door to your email reputation scores to get progressively eroded.
If you don't want to use your real email address for something, then either send via the service provider itself, or use a service like mailinator.com that is set up specifically for throwaway addresses.
If the DW admins think there is any utility whatsoever in allowing their namespace to be used with random relay servers, then they can get around the SPF issue by either giving a "soft" record (as I mentioned earlier, with its drawbacks), or create a different subdomain for either the notifications or the user email aliases. If you'd go down that path, then creating a subdomain for the user aliases would seem to me to be a better way to go, so as to at least keep the "@dreamwidth.org" sender reputation reasonably intact - in any case, for the alias namespace, you can either leave off the SPF record in its entirety, or give it a "soft" record.
But if someone sent mail purporting to be from @dreamwidth.org, and from a home IP address, my organisation would reject it anyway. We don't accept mail from home networks, and while I enforce a stringent ruleset in that way, it is not rare.
no subject
Regarding the question of allowing people to have a sender address of a particular domain, and yet be allowed to send mail from any random machine, as an email administrator, and in this day of endemic spam (at least 90% of the email sent around the world is spam), I have a strong aversion to the idea of any organisation allowing domain senders to use random servers which they do not control. I can't think of any spammers who use their own domains to send messages "from". By allowing your namespace to be potentially polluted (any sender address can be spoofed, but it's less likely that a target that doesn't seem so "easy" will be used - there's a lot less spam purporting to come from Hotmail senders these days), you open the door to your email reputation scores to get progressively eroded.
If you don't want to use your real email address for something, then either send via the service provider itself, or use a service like mailinator.com that is set up specifically for throwaway addresses.
If the DW admins think there is any utility whatsoever in allowing their namespace to be used with random relay servers, then they can get around the SPF issue by either giving a "soft" record (as I mentioned earlier, with its drawbacks), or create a different subdomain for either the notifications or the user email aliases. If you'd go down that path, then creating a subdomain for the user aliases would seem to me to be a better way to go, so as to at least keep the "@dreamwidth.org" sender reputation reasonably intact - in any case, for the alias namespace, you can either leave off the SPF record in its entirety, or give it a "soft" record.
But if someone sent mail purporting to be from @dreamwidth.org, and from a home IP address, my organisation would reject it anyway. We don't accept mail from home networks, and while I enforce a stringent ruleset in that way, it is not rare.