returns@legitcompany.org<\/a>.<\/p>\n\n\n\nThe actual email accounts probably don\u2019t exist. When the customers reply to emails from these different addresses, the incoming software reroutes them to the right destination.<\/p>\n\n\n\n
This means that these legitimate companies are faking email addresses within their domain. But clearly, they are not trying to fool or misinform their customers.<\/p>\n\n\n\n
Of course, the examples above use the domain owned by a legitimate company.<\/p>\n\n\n\n
But shouldn\u2019t they be stopped from sending emails spoofed as @whitehouse.gov or @paypal.com? Shouldn\u2019t the hosting provider put measures in place to monitor and stop this activity?<\/p>\n\n\n\n
Multiple domains using the same mail server<\/h3>\n\n\n\n
It wouldn\u2019t be difficult. The hosting providers monitor all network traffic sent from the servers that they host.<\/p>\n\n\n\n
They know which domain is sending out the email, and they can see the sender details in the mail headers. All they\u2019d have to do is stop any that don\u2019t match up.<\/p>\n\n\n\n
But they don\u2019t do this for other good business reasons. Let\u2019s say that LargeLegitimateCompany has a subsidiary called SmallLegitimateCompany. Both companies share the same SMTP server.<\/p>\n\n\n\n
If we followed the logic of the hosting provider blocking messages that don\u2019t match the domain, then the emails from one of the companies would go down the tube.<\/p>\n\n\n\n
Is there no solution for proper monitoring and spoof prevention? Yes, there is. It\u2019s called SPF. I\u2019ll tell you what that stands for in the next section.<\/p>\n\n\n\n
<\/span>Using SPF To Prevent Spoofing<\/span><\/h2>\n\n\n\nThe principle of SPF is that website owners can specify other domains to be part of a family. Every domain in the family is allowed to use the same SMTP server.<\/p>\n\n\n\n
The website owners register the list of senders (other domains) who are permitted to send emails from the mail server associated with their main domain.<\/p>\n\n\n\n
This means that the hosting provider can compare outgoing email headers to this list. If they don\u2019t match, they can stop the email from going out.<\/p>\n\n\n\n
And the protection doesn\u2019t just stop there. It\u2019s also possible on the other side i.e. the receiving side.<\/p>\n\n\n\n
The receiving mail software can ping a request to the sending domain to check that the address details are on the list. If the details don\u2019t match, the software can send the email to the junk folder.<\/p>\n\n\n\n
<\/span>A Brief History Of SPF<\/span><\/h2>\n\n\n\nThis strategy of SPF was first documented in 2003 by Wong Meng Weng in Singapore. He called it Sender Permitted From.<\/p>\n\n\n\n
Other technologists worked on the framework. For whatever reason, the official label was renamed as Sender Policy Framework. Happily, that still meant the acronym was SPF!<\/p>\n\n\n\n
The goal of Weng and his colleagues was to fight the rising tide of spam on the internet. They mightn\u2019t have got anywhere if it wasn\u2019t for the fact that Bill Gates had directed Microsoft to work on a counter-measure to email spam as well.<\/p>\n\n\n\n
Microsoft is never shy from borrowing the work of others (and they fully credited it in this instance). The silicon giant added SPF to their mailing software in 2005.<\/p>\n\n\n\n
So, why are we still receiving spoof emails now? Let\u2019s explore that next.<\/p>\n\n\n\n