locked
SenderID / SPF TmpError RRS feed

  • Question

  • I have noticed that our Exchange 2013 Server is now timing out for all SenderID / SPF checks:

    X-MS-Exchange-Organization-SenderIdResult: TempError
    Received-SPF: TempError (exchange.domain.local: error in processing during lookup of user@domain.com: DNS timeout)

    If I check via nslookup this also times out with "DNS request timed out. Timeout was 2 seconds.":

    nslookup -type=txt gmail.com

    The odd thing is, other nslookup's ("type=mx" or "type=a") resolve fine.

    This used to work without a problem. Unfortunately we've had some Windows and Router updates since so I'm not sure where the problem could be.

    Any pointers appreciated.

    Tuesday, June 11, 2013 11:00 AM

Answers

  • I have identified this as an issue with the firmware on our router. Downgraded and this is now working as expected.

    Many thanks for all your help.

    • Marked as answer by Egg Monday, July 22, 2013 12:46 PM
    Monday, July 22, 2013 12:46 PM

All replies

  • It looks like a temporary error during process of checking against SPF,  possibly caused by the delay in DNS query.

    According to RFC 4408  

    2.5.6 TempError

    A "TempError" result means that the SPF client encountered a
       transient error while performing the check.  Checking software can
       choose to accept or temporarily reject the message...

    Please also read the following thread. This might be helpul


    Tuesday, June 11, 2013 1:33 PM
  • I had seen that thread before, but it seems to flick between it being specific domains, internal/external domains or exchange having problems.

    The strange thing I'm seeing is that this times out for all domains ... unless I use "nslookup -type=all" first:

    C:\>nslookup -ty=txt gmail.com
    Server:  UnKnown
    Address:  192.168.0.11
    DNS request timed out.
        timeout was 2 seconds.
    *** Request to UnKnown timed-out
    
    C:\>nslookup -ty=all gmail.com
    Server:  UnKnown
    Address:  192.168.0.11
    Non-authoritative answer:
    gmail.com       internet address = 173.194.34.117
    gmail.com       internet address = 173.194.34.118
    gmail.com       nameserver = ns2.google.com
    gmail.com       nameserver = ns3.google.com
    gmail.com
            primary name server = ns1.google.com
            responsible mail addr = dns-admin.google.com
            serial  = 2012061200
            refresh = 21600 (6 hours)
            retry   = 3600 (1 hour)
            expire  = 1209600 (14 days)
            default TTL = 300 (5 mins)
    gmail.com       MX preference = 5, mail exchanger = gmail-smtp-in.l.google.com
    gmail.com       MX preference = 30, mail exchanger = alt3.gmail-smtp-in.l.google.com
    gmail.com       text =
            "v=spf1 redirect=_spf.google.com"
    gmail.com       AAAA IPv6 address = 2a00:1450:4009:803::1016
    ns2.google.com  internet address = 216.239.34.10
    ns3.google.com  internet address = 216.239.36.1
    
    C:\>nslookup -ty=txt gmail.com
    Server:  UnKnown
    Address:  192.168.0.11
    
    Non-authoritative answer:
    gmail.com       text =
            "v=spf1 redirect=_spf.google.com"

    Our internal DNS server forwards to our ISP & Google DNS. I've tried directly to the Google DNS servers using "nslookup -type=txt gmail.com 8.8.8.8" with no change in results.

    Very strange.

    Wednesday, June 12, 2013 2:43 PM
  • Hi,

    The issue may occur if the Forwarders are not set and DNS server is not pointing to itself for name resolution. Please check with this point.

    Thanks,

    Simon


    Simon Wu
    TechNet Community Support

    Monday, June 17, 2013 12:39 PM
  • Hi, thanks for your reply.

    Forwarders are already in place to Google (8.8.8.8 & 8.8.4.4) and DNS server already points to itself for resolution (127.0.0.1 & ::1).

    Worth checking though, thanks again.

    Monday, June 17, 2013 1:57 PM
  • hi dear... "
    Set-SenderIDConfig -SpoofedDomainAction StampOnly -TempErrorAction StampOnly
    and after that back to
    Set-SenderIDConfig -SpoofedDomainAction reject -TempErrorAction reject

    This reset those two settings and i dont think u will get a single spam mail. "hope this helps... 


    Regards Shah. MCITP, MCTS, MCSE & CCNA (academies) No claims (try at your own risk)


    • Edited by Suhail.Pir Sunday, June 30, 2013 11:50 AM Spelling mistake
    Sunday, June 30, 2013 11:49 AM
  • I have identified this as an issue with the firmware on our router. Downgraded and this is now working as expected.

    Many thanks for all your help.

    • Marked as answer by Egg Monday, July 22, 2013 12:46 PM
    Monday, July 22, 2013 12:46 PM
  • Check this out . May help you http://wp.me/p1eUZH-87 

    ammarhasayen

    Thursday, September 26, 2013 12:14 PM