You have an Exchange Server 2010 organization. An Edge Transport server sends and receives all email messages from the internet. You notice that some servers on the Internet identify e-mail
messages from your organization as spam. You need to minimize the possibility that e-mail messages
send from your organization are identified as spam. What should you do?
A.
Implement Microsoft Forehead Security for Exchange Server.
B.
Create SenderID TXT records for the Edge Transport servers.
C.
Configure the Edge Transport servers to use a real-time block list (RBL).
D.
Install a server certificate from a trusted third-party certification authority (CA).
Explanation:
You heard right, Sender Id is coming! What is Sender Id, you ask? Don’t feel bad, most Exchange
admins are asking the same question. Essentially (and very simplified) Sender Id is part of an
initiative (I’m not sure that is the exact correct word), to reduce spam. Sender Id is part of the
Sender Policy Framework (SPF). So how does it work? First, you create a DNS TXT record for your
domain (or domains) that identifies the mail servers from which e-mail will be sent for your domain.
SMTP servers that support Sender Id will then check that TXT record when they receive a message
from one of your users. Here is the FUD (fear, uncertainty, and doubt) part. If the message is coming
from a domain that does not have a Sender Id TXT record or the record does not match the sending
IP address, the receiving system has a couple of options:
• Do nothing.
• Reject the message entirely. (!!!!)
• Accept the message and then delete it prior to delivering it to the user.
• Give the message to the anti-spam inspection system with the assumption that the antispam
system (such as Microsoft’s IMF starting in Exchange 2003 SP2) will give the message a higher spam
probability if the sender’s domain does not have valid Sender Id records
http://mostlyexchange.blogspot.ca/2005/07/sender-id-is-coming-get-your-txt.html