As we all know, e-mail is a very important part of our daily lives. At least, during our daily job. When we talk about e-mail it is clear that the number of SPAM messages is increasing. Apart from the fact that SPAM is annoying, it is also a potential threat. By means of SPAM; spoofing and phishing is often used to steal someone’s identity. It can harm the reputation of the domain owner. SPAM can also consumes unnecessary bandwidth and affect overall performance of a mail server.
Anti-SPAM:
Of course we often use Anti-SPAM filters. A disadvantage of Anti-SPAM is that it sometimes marks e-mail messages as SPAM while it isn’t, with the risk losing legitimate e-mail. And every now and then an unwanted SPAM message gets through. This is why we constantly have to be kept up-to-date with Anti-SPAM definitions. Fortunately, more and more is done in terms of legislation against SPAM. But the harder we fight against SPAM it will never solve the problem entirely.
If you zoom in on SPAM then there is something that is not so noticeable; it’s always the receiver that needs to protect themselves against SPAM. Right?
The fact is, the owner of a domain can definitely do something about it. A very good method is using the Sender ID Framework (SIDF). From my own experience, I can highly recommend Sender ID Framework! It is very easy to apply, and it is totally free. Unfortunately, the Sender ID Framework is somewhat underexposed. This is a shame, because it works very well. With this blog I hope to bring the Sender ID Framework to your attention. Are you an administrator of an e-mail server, are you responsible for inbound and outbound communication for you company or are you using e-mail in other way, then I highly recommend you to read this blog.
Spoofing/Phishing (Unauthorized Sender):
If we look at the sender e-mail address of SPAM messages, then there is one characteristic to distinguish. Only a few SPAM messages are coming from e-mail domains that don’t exist. Those are easy to filter. But, most SPAM messages are coming from e-mail domains where the actual senders are not the domain owners. So it is possible that a spammer sends messages on-behalf of your company and so is abusing that identity. This is what we call ‘spoofing‘.
Based on spoofing an unauthorized sender can pretend to be someone else (taking someone’s identity) and try to collect data from the receiver. This is called ‘phishing‘. This is possible because the sender cannot be verified. To give you an example, especially banks have to deal with this kind of threats. After all, there are enough ways to abuse it. And this is what Sender ID Framework can protect you from. By using Sender ID you can help fighting SPAM. Something, you and (all) your receivers can benefit from.
A research from Microsoft (in 2008) has shown that about 75% of all SPAM message are coming from existing domains where the sender is not the owner at all. That research has also shown that 98% of all phishing e-mail could be prevented with Sender ID Framework. That is quite a lot. Time to do something about it.
Sender ID Framework (SIDF):
Sender ID uses DNS to verify whether a sender it authorized to send e-mail on behalf of an e-mail domain. This is known as “SIDF authentication“. SIDF authentication uses a simple DNS query and doesn’t affect overall performance. In fact, it can even increase performance when incoming e-mail is blocked by a Server ID filter (on an e-mail server).
For every e-mail domain one or more “MX-records” exists which indicates to which hostname or IP Address the e-mail should be delivered. According to RFC 5321 it is even required to have an MX-record. But an MX-record does not offer a an authentication method to verify a sender. Sender ID uses an “SPF-record” (TXT-record) which contains a list with hostnames and/or IP Addresses from mail servers which are authorized to send e-mail on-behalf of that domain. An SPF-record can be configured in many ways, which I will explain in a moment…
But having an SPF-record isn’t enough. The receiving e-mail server must also verify the SPF-record. That is very simple to configure. Almost every mail server (such as Exchange Server) has a Sender ID filter that supports the Sender ID Framework. Even when there is no Anti-SPAM software available. The Sender ID Framework works as following:
Genuine E-mail Message:
- A sender (mailserver) sends an outbound message from sender@company-aaa.com to receiver@company-bbb.com.
- The receiver (mailserver) queries DNS for an SPF-record from that domain before accepting the inbound e-mail message.
- The receiver (mailserver) uses the SPF syntax to authenticate the sender (mailserver) by matching the source IP Address.
- According the SPF syntax the source IP Address (of the sender) is authorized to send e-mail from @company-aaa.com.
- The inbound e-mail message is accepted.
- The inbound e-mail message is further processed by Anti-SPAM filters.
Non-genuine E-mail message:
- A sender (mailserver) sends an outbound message from sender@company-aaa.com to receiver@company-bbb.com.
- The receiver (mailserver) queries DNS for an SPF-record from that domain before accepting the inbound e-mail message.
- The receiver (mailserver) uses the syntax of the SPF-record, to authenticate the sender (mailserver) by matching the source IP Address.
- According the SPF syntax the source IP Address (of the sender) is not authorized to send e-mail from @company-aaa.com.
- The receiver (mailserver) has three options:
- The inbound e-mail message is not accepted, and session is disconnected.
- The inbound e-mail message is accepted, but deleted immediately.
- The inbound e-mail message is accepted but marked as SPAM and further processed by Anti-SPAM filters.
Microsoft:
SIDF (Sender ID Framework) is co-developed and anticipated by Microsoft together with some other companies. SIDF is approved by the IETF (Internet Engineering Task Force). It may be clear this method/technique is from upmost value. Microsoft has an official website where everything about SIDF is explained in detail. It is worth to have a look. Use the following link for more information:
Sender ID Framework Overview
www.microsoft.com/senderid
Sender ID Framework SPF Record Wizard:
And SPF-record can be configured in many ways and has many options. The syntax does not have to include only static IP Addresses or subnets. You can also use values like A-records and MX-records. For example, you can configure it in such as way that existing MX-records are used for both inbound and outbound authorization. Mailservers resolved by the MX-records may not only receive but also send e-mail. What is important, the domain owner is in control. On the official Microsoft website you find an intuitive online Sender ID Framework SPF Record Wizard that allows you to check whether a domain has an SPF-record configured. And this wizard also allows you to generate the correct syntax for your SP-record.
Please refer to the following link for more information:
Sender ID Framework SPF Record Wizard
www.microsoft.com/senderid/wizard
Why should you check for Sender ID? (receiver)
As the receiver you can always enable Sender ID filtering on your mailserver. Once enabled; before your mailserver accepts incoming e-mail messages it checks those domains for an SPF-record. When an SPF-record exists it will do SIDF authentication. That will make your mailserver can efficiently filter unauthorized senders.
Why should you enabled Sender ID? (sender)
But of course you can help other receivers (mailservers) by applying Sender ID on all your domains, by simply adding an SPF-record (TXT-record) to your DNS Zone. Unfortunately, not many people are aware of the Sender ID Framework. The more domains apply it, the better. If you don’t know what syntax to use in the SPF-record, use the Sender ID Framework Wizard.
NOTE: Even when an e-mail does not send e-mail, you should still apply Sender ID. Because with Sender ID you can tell other mailservers that that domain does not send e-mail at all.
What is it in for you?
The advantage with Sender ID is that your e-mail domains cannot be used by unauthorized senders. Of course, when the receivers (mailservers) checks for Sender ID. With other words, they can’t use your identity. And it is totally free. I cannot say other than; use it!
I already have an Anti-SPAM provider, can I still use it?
Sure. Most providers even have a specific syntax that can be used in your SPF-record(s). But sometimes it is not possible, or it has less effect. Still I highly recommend to apply Sender ID wherever possible. Just make sure you only check for Sender ID on edge mailservers, that are directly connected to the internet. If you have a mail relay server in front, only check for Sender ID on the mail relay server. Use the previous links for more information. Or you can always hire me if you want 😉
Can you enable Sender ID internally?
Yes you can. This is handy to prevent open relay. But double-check your syntax and settings before you enable it.
I hope this information was informative to you. If you use Sender ID and want to share something, then please post a comment.
