SenderID has been used in Exchange as a means for anti-spam for quite some time, as far as I can remember this was first used in Exchange 2010. Related to SenderID is SPF (Sender Policy Framework). SPF looks like SenderID functionality, but it differs in the way how it checks email messages.
Both use public DNS records with TXT records where information is stored regarding the sending SMTP server, and this information is used by the receiving (Exchange) server to validate if the sending server is allowed to send email on behalf of the sender.
Getting more popular for fighting spam are DKIM (DomainKeys Identified Mail) and DMARC (Domain-based Message Authentication, Reporting & Conformance). Just like SenderID and SPF, these solutions use public DNS for additional information as well, but since encryption is used most Exchange admin have some doubts about the complexity of DKIM and DMARC.
In the upcoming blogpost I’ll discuss SPF, DKIM and DMARC as implemented in my lab environment which looks like this:
There’s an Exchange 2016 CU2 Mailbox server hosting several Mailboxes. The server is accessible via webmail.exchangelabs.nl and autodiscover.exchangelabs.nl (same IP address, behind a Kemp LM3600 load balancer) and configured with a Digicert UC certificate.
In addition to this there’s an Exchange 2016 CU2 Edge Transport server with FQDN smtphost.exchangelabs.nl. Besides the regular A and MX record, the IP address is also configured in Reverse DNS. The Edge Transport server is also behind a Kemp LM3600 load balancer, and it has a Digicert SSL Certificate with the same domain name. There’s an Edge Synchronization configured between the Mailbox server and the Edge Transport server, and all inbound and outbound mail is handled by the Edge Transport server.
SenderID and SPF
One of the solutions to fight spam is to use SenderID filtering in Exchange Server 2010 and higher. SenderID filtering tries to determine if the sending SMTP server is actually allowed to send messages on behalf of the sender and his SMTP domain. SenderID filtering uses an additional record in public DNS to achieve this. In this DNS record, information is stored which servers are allowed to send mail on behalf of the SMTP domain. The other way around, if a SMTP server is sending mail on behalf of a SMTP domain, and this information is NOT stored in DNS, it might well be a source of SPAM (spoofed messages). This record in DNS is an SPF record.
SPF and SenderID not the same. The both validate the user’s e-mail address using a SPF record in DNS, and the records are identical for both SPF and SenderID. The difference between the two is in which layer of the SMTP message they validate. In short, SPF validates the HELO domain command, which is the envelope of the email message. SenderID on the other hand typically check the Mail From command inside the message. But because of all this a typical admin gets confused by the difference between SPF and SenderID. Neither of them is better or worse, but it’s also wrong to say that SenderID is the new SPF or SPF 2.0, that’s also not the case. Reasons enough to get confused…. And to make it more confusing, rumors are that Microsoft is not developing on SenderID, and is fully supporting SPF…
This is how it works. A user sends a message (1) to a recipient in your organization and the user’s SMTP server sets up a connection. When the EHLO and MAIL FROM (2) commands are sent the receiving Exchange server will try to contact DNS to get the SPF record (3) and compare the data found in the SPF record with the name and IP address of the sending server to see if there’s a match (4). If there is a match (“pass”) an entry to the message header will be added, but if there’s not a match (“fail”) there are multiple options:
- The message is rejected and nothing else happens;
- The message is stamped with an additional message header saying the SenderID failure, and at the same time the Spam Confidence Level (SCL) is increased. Then the message is delivered to the mailbox (5), if the SCL is below the threshold of course.
So, if you have added an SPF record to the public DNS and the receiving mail server performs a check on this SPF record it’s an additional test to get your message successfully delivered.
What’s in this SPF record? For my own environment it contains the following value:
“v=spf1 a:smtphost.exchangelabs.nl ~all”
Where smtphost.exchangelabs.nl is the FQDN of my sending Exchange 2016 Edge Transport Server. If I send out a message, it should always originate from this FQDN. If it’s coming from another mail server, the message is most likely not sent by me!
Since my MX record is the same as the FQDN above it is also possible to use the MX record for SPF purposes, like this:
“v=spf1 mx ~all”
The ~ symbol means that the receiving mail server should accept the message but tag the message (i.e. add an additional message header), this is called a soft fail. If the ~ symbol is replaced by a – symbol, it means a hard fail. The receiving server will most likely bounce any mail that does not comply. A ? symbol can also be used and is pretty neutral, it is up to the receiving SMTP server to determine what to do with the message.
It is also possible to use an IP address or a range of IP address in an SPF record to determine where your mail may be originating from. In this example all servers in the 176.62.196.240/28 range may send SMTP messages on behalf of my name:
“v=spf1 ip4: 176.62.196.244/28 ~all
For more information on how to construct a proper SPF record, you can check the Sender Policy Framwork syntax pages on http://www.openspf.org/SPF_Record_Syntax.
Note. Microsoft used to have their own wizard for creating SPF records, but this wizard have been taken offline quite some time ago.
When you’ve constructed your SPF record and added it to your public DNS, you’re ready to test.
You can use the verifier offered by the Port25.com site. To use this you can send an email to check-auth@verifier.port25.com and wait for the results. In the body of the returned email you should find something like:
HELO hostname: smtphost.exchangelabs.nl
Source IP: 176.62.196.244
mail-from: John@Exchangelabs.nl
———————————————
SPF check details:
———————————————
Result: pass ID(s) verified: smtp.mailfrom=John@Exchangelabs.nl
DNS record(s):
Exchangelabs.nl. SPF (no records)
Exchangelabs.nl. 617 IN TXT “v=spf1 a:smtphost.exchangelabs.nl ~all”
smtphost.exchangelabs.nl. 617 IN A 176.62.196.244
Another basic check is to send an email to another Mailbox and check the header of the message after receiving the message. When I send an email to my home account and check the header of the message I can see the following information in the message header:
Authentication-Results: hotmail.com; spf=pass (sender IP is 176.62.196.244) smtp.mailfrom=J.Wesselius@Exchangelabs.nl; dkim=none header.d=Exchangelabs.nl;
At this point we know SPF is working correctly and we can continue with DKIM. This is subject of the following blog.
When receiving an email the Exchange 2016 Edge Transport Server also checks the SPF record of the sending organization as can be seen in the header of an inbound message:
Received-SPF: Pass (smtphost.exchangelabs.nl: domain of testjaap@holland.nl designates 145.128.1.35 as permitted sender) receiver=smtphost.exchangelabs.nl; client-ip=145.135.16.35;
Summary
You can use SPF as a validation mechanism for your mail servers so receiving mail hosts can actually check if your mail server is allowed to send mail on behalf of your company’s SMTP domain. For a straight forward environment with only a couple of outbound SMTP servers this is not an issue. When you know which servers are outbound SMTP servers you can add these to the SPF record and you’re ready to go.
Things get more complicated when you have multiple email environments, all sending on behalf of your domain. Or when you have 3rd party organization, like marketing organizations, or services that send out large amounts of bulk mail, these servers have to be added to the SPF record as well to make sure all mail gets delivered as planned, and not being treated as spam or junk mail. This is the most difficult part of SPF, and this is not a technical issue but more an organizational issue.
SPF is a general solution and not a vendor specific solution, so you can implement SPF for your Exchange environment, but also for a Lotus Notes or Groupwise environment, or for a cloud solution like Office 365 or Google Mail.
SPF is just the first step in validating email and fighting unsolicited email. In my next blog I’ll discuss DKIM as an additional step.
Jaap Wesselius 
4 thoughts on “SenderID, SPF, DKIM and DMARC in Exchange 2016 – Part I”