As part of the product we offer we send emails on behalf of our clients. Because the emails don't come from an IP associated with the client they are sometimes flagged as spam.
We advised some of our clients to add an SPF record approving us to send emails on their behalf. We saw immediate improvement in deliverability rates after making the change however one of our clients was notified by his hosting provider that the SPF record we suggested to add would "slightly restrict" all emails that don't come from our servers (including our client's own servers).
The record we use is this:
v=spf1 a mx include:ourdomain.com ~all
So my question is if the warning we received about this is correct and if so why and what can be done to solve this (allow sending email both from original domain and by ourselves).
Well.. kinda?
If the client doesn't already have an SPF record, then it does restrict messages coming from unauthorized hosts. Intentionally. If this record doesn't fit their needs (like if servers that need to be authorized aren't in their
AorMXrecords), then they should customize this one (while keeping theinclude).If the client already has an SPF record that's less restrictive than the one you're advising them to put in place, then the record you've provided might not be appropriate; instead, they should simply add the
include:ourdomain.comto their existing SPF record.Outside of those cases, the record you've provided doesn't restrict (or "slightly restrict") messages - the client's allowed systems (the
aandmxparts of the record) aren't treated as any 'less authorized' than the servers that you've allowed via theinclude.I'd recommend reading this article and if you're needing a wizard to help set up SPF record, look for a link to a wizard near the end of the page.
http://www.unlocktheinbox.com/resources/spfrecords/