Behind the Blackboard! Requirements for Managed and SaaS Hosting Clients to use Blackboard's Email Relays - Behind the Blackboard Skip Navigation
Download PDF  Icon Download PDF    Print article

Requirements for Managed and SaaS Hosting Clients to use Blackboard's Email Relays

Date Published: Oct 25,2023

CategoryProduct:Learn Administration,Communication Tools; Version:Learn 9.1 Q4 2016 (3100.0.0-rel.107+401e,Learn October 2014 (9.1.201410.160373),SaaS,Learn 9.1 Q4 2015 (9.1.201510.1171621),Learn 9.1 Q2 2016 (3000.1.0-rel.52+991d)
Article No.: 000054017
Blackboard Learn
Blackboard Managed and SaaS hosting sites are configured by default to use standard Blackboard-provided mail relays to handle email communications being sent through the System. To ensure that all messages are timely delivered and not flagged as spam or blocked, certain requirements and policies apply.


This article applies to all email deliverability issues while using Blackboard's mail relays such as


  1. This behavior is caused by a missing SPF record, which authorizes Blackboard as a sender.
  2. It is also necessary for the receiving MTA to support TLS version 1.1 or 1.2. The relays purposefully do not support older ciphers, for example TLS 1.0 and SSL 3. If the receiving MTA does not support TLS 1.1 or 1.2 the emails will not be sent at all.


SPF Requirements

The steps to add an SPF record are dependent on where the DNS entry is registered.  For specific steps, please consult your DNS service's support or help documentation.  The entry that needs to be added is ''. (This also applies if you are SaaS-Hosted, there is not a distinct SPF record for SaaS.) If this were the only thing in the SPF record, the record would look like:
"v=spf1 ~all"
  But: It is expected that there will be additional entries for all verified senders, including IP's for the institution's internal relays, domains, or third part vendors.  For example, if your institution uses Barracuda, then an appropriate SPF record may look like:
"v=spf1 mx/24 ~all"


Additionally, Whitelisting will prevent email traffic from being flagged on an institution's network.  While the SPF record should be sufficient, it is recommended that the following IP ranges be whitelisted:

Note: The above list was updated on August 12, 2022. Please review and make any changes as soon as possible.

Additional SaaS Requirements:

In March of 2017 new IP addresses were implemented for SaaS that are used for outbound communication.  The goal of having multiple IP addresses is to help reduce the likelihood of an outage.  Clients will need to whitelist the following IP addresses, in addition to those that are already whitelisted.

These addresses are not currently implemented into the general SPF record, so they need to be added in addition to the SPF or whitelist. This is only applicable to clients in the United States. There is no impact on non-US clients.


Client Test and Staging

Production, Test, and Staging in the Kermit Fleet

To determine your fleet, please contact Blackboard Client Support


General Information

There are three main sites to review official standard documentation
http://www.openspf.orgDriving force behind SPF standards from Open SPF


What is an SPF Record?

"Sender Policy Framework (SPF) is a industry-standard technology to defeat forged e-mail. SPF is not directly about stopping spam – junk email. It is about giving domain owners a way to say which mail sources are legitimate for their domain and which ones aren't. However, as the legitimate mail industry is currently at or near 100% adoption, email from Domains without appropriate SPF records is seen as suspicious and is highly likely to be rejected or delayed.

How does SPF Work?

"SPF works by domains publishing "reverse MX" records to tell the world what machines send mail from the domain. When receiving a message from a domain, the recipient can check those records to make sure mail is coming from where it should be coming from."

I Already have the IP's Whitelisted, why do I need an SPF record?

Whitelisting tells servers under your control to ignore spam checks and to just deliver the email. This is a good measure to take if a specific server or service is having issues and can be isolated. However, even though the Blackboard relays have been whitelisted, delivery is still not guarnteed.  ISP's are used to relay millions of messages a day.  A lot of that email is spam, and they have taken measures to control it.

For example, ISP's will throttle emails based on the reputation of the service sending the emails.  One way to build this trust is to simply send email for a extended period of time and to ramp up slowly.  However, end users marking the emails as spam (as students may do with notifications), will degrade the trust. When the reputation with an ISP is lowered, the emails may then be filtered into a low priority queue which sends emails in smaller batches over a longer period of time, leading to delayed email.  When the reputation becomes poor, the emails may be blocked altogether.  With valid SPF records, the emails are trusted, and will not be subject to the throttling rules implemented by the ISP.

The above information is not very well documented across the internet, but a few sites that mention it include
: (Information on how to throttle email)

How do I view my current SPF record?

Popular Internet search engines will find a number of sites that will do this for you by simply entering a URL in a search box. However, this can also be done from command line:

To view current SPF record in Windows:

1.  Open the Command Line Terminal (cmd.exe)
2.  Type: nslookup -type=txt
3.  Review the line starting with "v=spf
C:\>nslookup -type=txt 2>&1 | findstr "spf1"
        "v=spf1 -all"

To view current SPF record in Linux:

1.  Open the command prompt
2.  type dig txt +short
3.  Review the line starting with "v=spf
$ dig txt +short | grep 'spf1'
"v=spf1 -all"

What is the Maximum Size or an Email

At the time of writing: the total size of an individual message including all attachments (taking into account the about 25% inflation of size caused by Base64 encoding), SMTP headers, MIME part separators and other things must not exceed exactly 52,428,800 bytes. Emails exceeding this will be rejected by the Blackboard relays and will not be sent. The application also batches emails such that the total size of an email's SMTP headers will not exceed 32,768 bytes.

These figures are set uniformly and cannot be varied. In practice emails larger than about 25 megabytes may not be deliverable anyway. Blackboard cannot control the behaviour of receiving MTAs and MTAs are permitted by Internet standards to impose a limit on the size of inbound messages to their preference.

The information contained in the Knowledge Base was written and/or verified by Blackboard Support. It is approved for client use. Nothing in the Knowledge Base shall be deemed to modify your license in any way to any Blackboard product. If you have comments, questions, or concerns, please send an email to © 2024 Blackboard Inc. All rights reserved