N00B SBS2011 Exchange SPF
Iv recently deployed SBS2011 and we are in the process of migrating our email from Yahoo Business to our exchange server. Unfortunately i have to use the pop connector in exchange because many remote users rely on yahoo's pop/smtp email hosting. Our exchange server isn't hardened up yet and Im not comfortable opening up the web faced OWA and remote stuff quite yet. The problem is yahoo doesnt have a smart host and email is getting black listed because reverse DNS snoops on the domain is resolving to Yahoos servers and not ours obviously. I spoke with Yahoo and they told me to give them the SPF record and they would add it to DNS on their servers. Here is what I think I should give them:
v=spf1 mx include:<my static ip address> ~all
Will this work?
My domain is hosted by Yahoo so my MX records curretnly point to their servers. I'll change it once Exchange is ready to completely host mail but for now it has to stay....
HELP
v=spf1 mx include:<my static ip address> ~all
Will this work?
My domain is hosted by Yahoo so my MX records curretnly point to their servers. I'll change it once Exchange is ready to completely host mail but for now it has to stay....
HELP
Yes it would, you'll have to add IP of the external IP of your environment
For example if here is your mail flow
Exchange --> A/V --> firewall
So, within SPF you'll add
v=spf1 mx include:<internet facing IP Adress of firewall> ~all
that is it.
Regards,
Exchange_Geek
For example if here is your mail flow
Exchange --> A/V --> firewall
So, within SPF you'll add
v=spf1 mx include:<internet facing IP Adress of firewall> ~all
that is it.
Regards,
Exchange_Geek
If you don't have an SPF record currently - that won't be the problem. If you do - then an SPF record isn't going to cause you problems with Reverse DNS.
ASKER
Thanks guys
@Exchange Geek
My users were getting the following message
According to you I would just tell yahoo to add the following spf record?
The xx.xxx.xxx.xx represents my public static IP
@Exchange Geek
My users were getting the following message
att.net gave this error:
xx.xxx.xxx.xx blocked by sbc:blacklist.mailrelay.att.net. DNSRBL: Blocked for abuse. See http://att.net/blocks
According to you I would just tell yahoo to add the following spf record?
v=spf1 mx include:xx.xxx.xxx.xx ~allThe xx.xxx.xxx.xx represents my public static IP
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Yes Hiro
Regards,
Exchange_Geek
Regards,
Exchange_Geek
ASKER
Thanks, Ill give this a go
If you decide to carry on ignoring me I'll happily add you to my list of Askers who I don't get notifications for. I'm not bothered either way. I have better things to do with my time than try to help people who ignore me.
ASKER
Ok, Called Yahoo and added "v=spf1 mx include:<ip> ~all" to DNS. I was reading http://www.openspf.org/SPF_Record_Syntax and wondering if I got the syntax correct?
Im a little worried after reading the Include mechanism. Is there anything else I might need to do on my end?
Im a little worried after reading the Include mechanism. Is there anything else I might need to do on my end?
The "include" mechanism (edit)
include:<domain>
The specified domain is searched for a match. If the lookup does not return a match or an error, processing proceeds to the next directive. Warning: If the domain does not have a valid SPF record, the result is a permanent error. Some mail receivers will reject based on a PermError.
Examples:
In the following example, the client IP is 1.2.3.4 and the current-domain is example.com.
"v=spf1 include:example.com -all"
If example.com has no SPF record, the result is PermError.
Suppose example.com's SPF record were "v=spf1 a -all".
Look up the A record for example.com. If it matches 1.2.3.4, return Pass.
If there is no match, other than the included domain's "-all", the include as a whole fails to match; the eventual result is still Fail from the outer directive set in this example.
Trust relationships — The "include:" mechanism is meant to cross administrative boundaries. Great care is needed to ensure that "include:" mechanisms do not place domains at risk for giving SPF Pass results to messages that result from cross user forgery. Unless technical mechanisms are in place at the specified otherdomain to prevent cross user forgery, "include:" mechanisms should give a Neutral rather than Pass result. This is done by adding "?" in front of "include:". The example above would be:
"v=spf1 ?include:example.com -all"
In hindsight, the name "include" was poorly chosen. Only the evaluated result of the referenced SPF record is used, rather than acting as if the referenced SPF record was literally included in the first. For example, evaluating a "-all" directive in the referenced record does not terminate the overall processing and does not necessarily result in an overall Fail. (Better names for this mechanism would have been "if-pass", "on-pass", etc.)
ASKER
@ alan
I forgot to assign my static IP to the router and the IP in question was dynamically assigned. I assume this is why my users got that message. I have since changed it to the static IP which resolved the issue sending to ATT but Im still going down the rabbit hole for reverse dns snooping. Not ignoring you.
I forgot to assign my static IP to the router and the IP in question was dynamically assigned. I assume this is why my users got that message. I have since changed it to the static IP which resolved the issue sending to ATT but Im still going down the rabbit hole for reverse dns snooping. Not ignoring you.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Verified SPF on MXtoolbox, hopefully this works for the interim. Thanks all!
Reverse DNS is configured on your IP Address by your ISP and the name added as your Reverse DNS record needs to resolve back to the IP Address you are sending from.
So - for now, you can create a new A record called for example - send.yourdomain.com and then add this as your Reverse DNS record (call your ISP) and then as long as your A record in DNS points to your Public IP Address, you should pass a Reverse DNS check.