Exchange did not require SPF record in internal DNS, it will never lookup with internal DNS

Does that mean the response of "send id service unavailable" is a normal condition for an attempted spoofed email address?

Meaning -
from a random public IP, if I send mail to a valid recipient, but the From is also a valid internal smtp address, the message is dropped (as desired), but the failure message is the "temporary" stamp.

In other words, it's "working" and not allowing a spoofed sender, but Exchange doesn't actually do an SPF lookup.

Please confirm.

Sorry, I don't understand how you send spoofed mail?
from public IP its fine, but from which email server and email client you have sent it and to whom?

You need to have your sender I'd published publicly. Does your exchange have access to both public and internal DNS servers? I.e. Depending to which it sends the query that is the one from which it will get a response.

a temporary error often suggests a timeout event when querying DNS. Which 4xx means.

Hi,
Generally you get this error message "450 4.4.3 Sender ID check is temporarily unavailable" in case of Spam, Junk or Spoof Emails which stuck in Queues of Exchange Server 2013.
You may use Antispam and malware feature of Exchange server and check following things:
1)  Sender Filter Agent
2) Sender ID Agent
3) Content Filter Agent
4) Protocol Analysis Agent
5) Recipient Filter Agent

Go through below links to know more about Error 450 and Exchange Antispam
https://technet.microsoft.com/en-us/library/jj218660(v=exchg.150).aspx
http://exchange-server-guide.blogspot.in/2015/05/how-to-deal-with-exchange-server-error-450.html

mahesh -
I manually telnet into the exchange server and specify the sender and rcpt as being from the Accepted Domain.  This is a "forced spoof".

arnold -
Not sure what you mean by publishing the sender id publicly.  I do have an SPF record in the public DNS zone, and a different SPF record on my internal DNS zone.  The internal domain is the same as the public domain name.

The issue is that Exchange simply does not make a DNS query for the SPF record if the domain name is the Accepted Domain.  It does make DNS queries for external domains.

Tej -
The emails are not stuck in the queue.  They are rejected as the TempErrorAction is set to reject.

Again, this only occurs for messages originated from external IP's and addressed From and To my domain name.

Also - the link you provide does not mention the error code I'm getting.  It's specifically the 4.4.3 error and it only occurs for spoofed messages.

if you run nslookup -q=txt dk.yourdomain.com within a command window on the exchange server what do you get as a response? the dk.yourdomain.com needs to be replaced with the host you use for the domain key reference.
The 4.4.3 is basically telling you that there is a temporary error that exchange is unable to retrieve the sender ID, the issue is that the fake/spoofed emails do not have a valid Domain-Key information so there is no way your exchange server can connect and retrieve information to confirm the key.

Sender Key works by the heather of the message has to include the information to validate the signature and authenticity of the email.  Exchange does not see yourdomain.com and decide, oh wait, it is my domain, let me reference my own information to confirm the authenticity of the sender.

I think it as acting as expected. If you can pull the message in question and look at the headers to see what host it points to for Sender ID validation, then try to see whether you can pull the info using nslookup -q=txt <referenced name>...

OK
Exchange server knows he is only authoritative to send emails for the accepted domain he owns.
For that I don't see any need for SPF record even on internet or internal as well.
SPF is published on internet for other domains to check validity of your exchange server and your smtp domain

Without setting any temp reject action what happens, can you please check

can you run the follow command and post back to the result?

Get-SenderIDConfig | Format-List bypass*,*mailenabled,spoof*

arnold -
I can get the TXT record from my internal DNS zone from the console on my Exchange server, using nslookup.  I've wiresharked the Exchange server, and it never even requests the TXT record for the local dns zone.  I see a DNS request for TXT records for external domains (legitimate incoming mail).

So I don't think it's not that DNS is wrong or not working - it appears that Exchange is not even attempting to check the SPF record from the internal DNS zone for mail addressed to its Accepted Domains.

Mahesh -
If that's true, is the 4.4.3 "error" an expected result?  The end result is that mail is not spoofed - as long as I have senderID enabled.  If the error is "normal behavior" and the end result is correct, I'm fine with that.  I am concerned that it gives a "fail" message.

Jian -

SpoofedDomainAction   : Reject
TempErrorAction       : Reject
BypassedRecipients    : {}
BypassedSenderDomains : {}
Name                  : SenderIdConfig
Enabled               : True
ExternalMailEnabled   : True
InternalMailEnabled   : True

Select allOpen in new window

We are going back and forth. The spoofed email, can you access what the header has by which means your exchange is supposed to validate the senderID?
Guess it depends on how verbose your log settings are. your exchange has its own key,
If the message is spoofed which it is inevitably is when an email is being delivered to the server authoritative for the senderID in question.


4.4.3 is not the error, it is part of the description of the error. The error code the remote mail client/server sees is 450 and to it it reacts by terminating and dequeuing the message for a subsequent delivery attempt.

your internally generated emails to an internal address do those get senderID generation and errors?

arnold -
I am using telnet from a remote IP address to force a spoofed message - it is not a mail client or a remote mail server.  There are no headers, as the SMTP conversation is ended and the mail is not queued.  The SMTP protocol log shows the same thing I see in the telnet session.

The end result is - the spoofed mail is not delivered.

I am trying to determine if it's not delivered by expected behavior or if the 450 4.4.3 is a sign of a real, underlying DNS issue as most search results suggest.

I am pretty sure DNS is working fine.

Maybe a better question is: Does Exchange perform an SPF check for its own Accepted Domains?
(i.e., I'm chasing a red herring here...)



telnet myserver.com 25
helo mydomain.com
mail from: myaddress@mydomain.com
rcpt to: myaddress@mydomain.com
data
spoofed message
.
450 4.4.3 sender id temporarily unavailable

Hello,

I just came across the same mysterious error and found the solution here:
https://social.technet.microsoft.com/Forums/en-US/e6ee0018-ef01-43f3-b8aa-76374184be55/receivedspf-temperror-xxx-error-in-processing-during-lookup-of-xxx-dns-timeout?forum=exchangesvrsecuremessaginglegacy

It seems to be a bug within MS Exchange dealing with "mx" tags within the spf statement. If you replace them by "A Record" statetments the whole thing immediately worked fine for me.

Cheers.
Tim