I'm evaluating setting up SPF for a domain that already has SenderID. We're considering removing the SenderID record entirely and replacing it with just an SPF record, instead of trying to write a SenderID record that tries to encompass SPF and SenderID.
We have two outbound servers, and two inbound servers which relay to internal Exchange machines.
Any bounces received by the two inbound server are delivered directly to the sender. I wasn't sure if that was considered sending and therefore should be included with the SPF record?
There is also a POP/IMAP server on a subdomain of our main domain.
I'm using 192.168.1.10 and 192.168.2.10 as our outbound servers, mail1.mydomain.com and mail2.mydomain.com for privacy here.
I believe the following would be the proper SPF record for our domain:
mydomain.com. 3600 IN TXT "v=spf1 ipv4:192.168.1.10 ipv4:192.168.2.10 ptr:subhost.mydomain.com mx:mail1.mydomain.com mx:mail2.mydomain.com a:subhost.mydomain.com include:constant-contact.com -all"
Is the PTR and A fields for the POP/IMAP host on the network that also sends mail as [email protected]?
If the marketing folks frequently change who they use to send marketing emails as "[email protected]", would you recommend ~all instead of -all?
We currently have "spf2.0/mfrom,pra ..." as our SenderID record. I would be interested in input on how to adapt that to properly support SPF as well.
It appears that even microsoft.com and live.com don't include "spf2.0" records, but instead just spf. Is anyone even using it anymore?
Thanks, Alex
I think the simplest SPF record that would fulfill your needs is:
You should not use the ptr mechanism, since it can require a lot of DNS queries on the receiving end, and should not be needed in this case. The use of ptr is also discouraged by rfc7208.
I'll guess that mail1 and mail2 are the names for the receiving mail servers. If you want them listed also (I don't think they are needed since bounces normally are delivered internally) you should just use the "mx" mechanism. This will match the ip-address against all mx records for the mydomain.com domain.
Regarding sending as [email protected], then this SPF record will not be used for that domain, since the sending domain is subhost.mydomain.com. Instead you will have to add a SPF record for the subdomain. If subhost.mydomain.com is one of the listed sending servers (the ip4s), this record could possible link to the record for mydomain.com:
And regarding the -all/~all, then I would recommend using ~all if there is a real risk of the marketing department switching mailing list providers without informing IT (It would not be the first time). Just be aware that some receivers may still block mails when SPF returns SoftFail (from ~all), especially of the mailing provider is listed on some of the blacklists.