If you haven’t created a SPF record to protect your SMPT domain on Internet this is for you.
SPF is not a single thing , it is two things. One thing is to verify incoming mail to your servers that they originate from a list of trusted servers. an example would be when your serves receive a mail that claims to be from domain.com , your server will do a lookup in DNS for information (the SPF record). This info will (if existing) have list of servers that are authorized to send mail with sender with SMTP address in domain.com domain. next step is for the receiving server to verify this SPF info together with header info in mail message and IP address of the sending server, if everything is OK it server will simply accept the email but if there is mismatch you have to decide and configure your server what to do, perhaps let email through anyway or mark it as spam.
The other thing is to create your own SPF record for others to verify mail claiming to come from your SMTP address space.
Easiest way to create your SPF record is to use one of the multiple wizards on Internet. Microsoft also has one https://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/ which is quite good. Remember that no wizard will never provide you with good results unless you enter good information into it so next step is to find all servers that send SMTP mail with senders from the SMTP domain you want to edit the SPF record for, this is key for a proper working SPF deployment.
SPF record itself is a plain TXT record in the zone authoritative for the SMTP domain and you can enter information in a variety of ways, IP addresses, server name, MX or a combination of them.
some examples of SPF records in domain.com zone.
v=spf1 ip4:10.10.10.10 ~all
This means that only a server with IP 10.10.10.10 is allowed to send mail with senders addresses in domain.com zone.
v=spf1 mx ~all
only servers listed in the MX record are allowed
v=spf1 a mx ip4:10.10.10.10 ~all
Only servers with A records or MX records or IP equal to 10.10.10.10 is allowed
The all parameter:
all parameter in SPF is prefixed with different chars such as – ~ ? +
- means that the information must match, it is otherwise illegal.
~ means that it should match but could also mismatch.
+ means that it is absolutely fine for other servers than listed to send email for domain.com
? means either way, it may or may not originate from the servers specified.
Outsourced domain
Sometimes you need to let someone else deliver mail for your domain such as news mail sent from a provider or perhaps you have configured your Exchange in a hybrid setup with some users on on premise and some in Office 365. you can of course simply add the providers IP addresses to your SPF record but this impractical because could change without you knowing and they could also be multiple causing the SPF syntax to be invalid.
Why would SPF be invalid when you have a lot of information in it?
the RFC states that the receiving server must be able to figure out each SPF record with 10 or less NS queries.
solution for outsourced email or many NS queries is to use the include parameter.
v=spf1 mx include:provider.net ~all
this means either mail are authorized to come from servers listed as MX or whatever the spf record says in the provider.net zone. With this technique you can manage your servers and the provider can manage their environment independent and also making the verifying server only do 2 NS queries. first for your MX records and the other one for the SPF record in provider.net zone, now there is a new spf record giving us 10 additional queries to use.
Good practice in my opinion.
Collect information about all system that could send mail for domain.com.
Start with ?all parameter and try to log what’s happening. by logging I mean log what NS queries is done against the domain.com zone. this is a lot easier if you run and manage the NS hosting the domain.com zone than if it outsourced to a provider which might not be that helpful with statistics.
Don’t change to –all unless you are very sure that the spf record is correct.
Don’t use your production domain for bulk marketing mail, create a separate domain for this because if something goes wrong, only the marketing stuff will fail.
Verify your SPF syntax, here is on tool that can be used http://www.kitterman.com/spf/validate.html
If you have a lot of info in your SPF, use the include parameter.
Verify incoming email to your environment
make Exchange verify incoming email.
Install the ant spam agents which is already deployed if you’re using Edge. configure the SenderID transport agent.
Configure it with appropriate action.
Set-SenderIdConfig -SpoofedDomainAction StampStatus
spoofedDomainAction could be Delete, Reject of StampStatus. StampStatus is interesting since it will allow mail to be received but Exchange will stamp it and later in the transport pipeline the content filtering agent will consider this stamping and most likely classify the email as more likely to be spam.
Last, enable the SenderID agent with Set-SenderIdConfig -Enabled $true
The senderID agent has some other good to know configuration parameters. BypassedRecipients and BypassedSenderDomains which is self explainatory, there is also TempErrorAction which also has the Delete,Reject, StampStatus values.
TempErrorAction happens when the verifying server encountered a transient error while checking the SPF, perhaps the spf syntax is incorrect, perhaps NS query timed out or something else that wasn’t considered to be normal.
Be safe and publish spf info in your DNS about your smtp domains and enable checking of the spf for incoming mail to your servers.
