Don't let the intentionally misleading title fool you...this blog isn't about sunscreen; this is about the Sender Policy Framework (SPF) and ensuring the emails you send from CRM Online get delivered correctly.

SPF is implemented within the Domain Name System (DNS) as text records (TXT) on a domain, and is used to help prevent email forgery by specifying the computers that are authorized to send mail for the domain. When an SPF-enabled mail server receives an email, it checks the DNS records of the sending domain for an SPF record and if one exists it checks to see if the sending IP address (or host name) matches the authorized senders listed in the SPF record. If it is listed, the email has "passed" the SPF check; if not, it has "failed," and is often marked as spam or bounced.

We're not going to debate the merits of SPF here, but if your organization publishes SPF records on its domain and you're implementing CRM Online, you're going to want to ensure that your DNS SPF records are updated to include Microsoft's outbound email relays as designated senders for your domain.

You can use the Windows PowerShell and its "resolve-dnsname" cmdlet to check on whether your organization uses SPF records. Simply open PowerShell and enter "resolve-dnsname yourdomain.com txt" to see all TXT records being published on your domain name. If you see an entry starting with "v=spf1" as in the example below, you're going to want to contact your DNS team and ask them to add "spf.messaging.microsoft.com" to it as in the example shown below for the powerobjectsweb.com/stg domain. If you don't see anything starting with "v=spf1," you aren't publishing SPF records on your domain and don't have to worry about it.

For additional resources check out this Microsoft knowledgebase article describing SPF records or look to the overview of the Sender Policy Framework (a.k.a. "Sender ID"). As always, keep an eye on our Dynamics CRM blog as we continue to write about all things Dynamics CRM.

Happy CRM'ing!