We will share with you some of the more representative questions about SPF before.
The environment is described as follows:
The company ad domain name is contoso.com, the public network SMTP domain name is also contoso.com. The mail server used is Exchange CU10 and uses the Exchange Edge Edge Server to implement spam filtering. To prevent other mail system phishing domain contoso.com from sending mail to other domain names. An SPF record has been added to the public DNS resolution zone contoso.com, with the following record: V=spf1 MX A ip4:1.1.1.1 include:spf.contoso.com ~all.
Problem phenomenon:
One day in 2016, the IT staff received a sender [email protected] spam, Exchange administrators query the local organization does not exist in the [email protected] This email address, obviously this address [email protected] is a phishing address. By looking at the message header, the public IP address that sent the phishing message is 2.2.2.2, this IP is not the public IP of the organization. Why can I still receive phishing messages after I have added SPF and enabled Exchange Send IDs? (For SPF and send IDs, refer to my previous blog content:
http://jialt.blog.51cto.com/4660749/1769978)
Problem Analysis Process:
SPF has been explained in the blog I wrote earlier, and if you want to prevent phishing messages from being implemented using SPF records, you must have certain conditions. So I conducted the following checks.
1, verify the domain name contoso.com SPF record to add whether there is a problem, and through the third-party website to simulate the process of phishing, are normal.
2. Check that the current Exchange organization's Send ID feature is enabled and checked for enabled.
3. Check that the Send ID feature of the Exchange Edge Server is working correctly, and the result returned by command test-senderid-ipaddress 3.3.3.3-purportedresponsibledomain 163.com is normal. When I use test-senderid-ipaddress 1.1.1.1-purportedresponsibledomain contoso.com Returns the result that the SPF record is not found.
4, I suspect that is the Exchange Edge Server DNS resolution problem, check the Edge Server DNS discovery, the Edge server uses the DNS for internal ad IP, and the internal contoso.com resolution zone does not add an SPF record. As a result, when the Edge server receives the message, it cannot be found by DNS to find the contoso.com SPF list, which prevents the contoso.com of the phishing domain name.
So the problem is found, we have two workarounds: 1), change the Edge server's DNS to public DNS. 2), in the internal DNS resolution zone contoso.com add and the public network consistent SPF record.
This article is from the "Jialt blog" blog, make sure to keep this source http://jialt.blog.51cto.com/4660749/1775999
You can still send an imposter message after you add an SPF record