This tidbit is starting a series on understanding some mechanisms available to you for protecting e-mail sent from your domain. We covered this topic in this month’s Tech Talk / SYSOP meetings but for all those that missed them or those that want a refresher I am covering this again here in this series.
Putting into practice what we share here will not only potentially help with protecting you from inbound spoofed SPAM and malware but also help ensure that your domain’s legitimate e-mail actually gets delivered. Many of the larger e-mail providers such as Google or Microsoft are becoming more suspicious of e-mails received that can’t be verified as from a legitimate sender which is exactly what these mechanisms are designed to do.
All of these methods involve setting up special DNS records in your domain’s master zone file that help tell potential recipients of mail from your domain whether or not that mail came from a location authorized by you to transmit mail on your behalf.
Over this series we are going to look at three different mechanisms that if all employed can work in concert with each other to help protect your e-mail:
- SPF – Sender Policy Framework
- DKIM – Domain Keys Identified Mail
- DMARC – Domain-based Message Authentication, Reporting, and Conformance
All are setup around DNS TXT records in your DNS domain's authoritative zone file
This week - SPF records
SPF records are used to identify what hosts are allowed to send e-mail on behalf of your domain.
The format of a typical SPF record looks something like this:
mydomain.com. IN TXT “v=spf1 mx a include:_spf.google.com ~all”
They can look a bit like a collection of alphabet soup but let’s see if I can put some clarity behind what is contained in them. Taking this DNS SPF TXT record apart:
mydomain.com is simply the identifier for your domain name
IN TXT – is the record identifier in DNS that this is a TXT or “Text” record type
v=spf1 – identifies the version of SPF
Those first three parts really just set the table for the main part of what’s really in the SPF record which are identifiers of devices that are allowed to send mail on behalf of your domain.
In our example:
mx – identifies that any valid MX server that is already identified to receive mail in our zone file for our domain is also allowed to also send mail for our domain. This makes a lot of sense as MX is shorthand for mail exchanger so it’s a really quick way of saying that any server identified by purpose as a mail exchanger should be considered a valid sender.
a - identifies any valid hosts defined in our DNS zone file with an “A” or host type record are also allowed to send mail for the domain.
So, the above two entries quickly allow us to identify classes of devices under our control that are authorized to send mail on our domain’s behalf. Easy enough but now we will get a bit more complicated.
What about when we use other third-party services that may send out e-mail on our domain’s behalf like servers from Google Apps or perhaps a student services application hosted by a third-party vendor or perhaps the local RIC? Below is the example of using the “include:” keyword to indicate that hosts from inside the domain that follows are also authorized sending hosts on our behalf:
include: _spf.google.com – identifies in this case that hosts from inside the “_spf.google.com” domain are allowed to send mail on our behalf.
You can use as many “include:” statements as you need in your SPF record to cover all the possible third-party providers you might have in use.
At the end of the SPF record is the “all” identifier which tells recipients how to potentially handle mail received from a host not previously identified in your SPF record as authorized.
The key here is not the word “all”, but the symbol placed in front of the word “all”.
- ”-all” known as a hard fail – not compliant and asked to be rejected
- “~all” known as a soft fail – marked not compliant but asked to be accepted
- “?all” known as neutral – left to the discretion of the recipient.
As e-mail providers get more aggressive at combating SPAM e-mail and malware the practical reality is anything received that cannot be identified as coming from a valid sender in your SPF record is more than likely being rejected or at least marked as SPAM.
So that’s it for our example.
There are several other possible identifiers that can also be used inside an SPF record, but we will leave those for another discussion.
If you have questions about using SPF or want help implementing SPF for your domain contact our support team.
In our next Tidbit on this subject we will explore the use of DKIM records.
Until next time…….
You must be logged in to post a comment.