When managers or admins assign lessons, learners are notified by email; and those email notifications appear as though they came directly from the manager herself. This enables learners to reply to their manager with any questions or concerns.

Depending on the strictness of your company's email settings, however, these messages may be treated as spam. That's because they originate from Lessonly, not the manager's email account.

This is a common problem for apps that send email notifications, but following the steps below will ensure that learners receive assignment notifications as intended.

Sender Policy Framework (SPF) DNS records identify who is allowed to send emails on your domain's behalf. Without SPF protection, it would be easy to spoof anyone's email address and make it look like a malicious email is from someone the recipient trusts.

Lessonly sends emails on behalf of managers when they assign learning content. For example, suppose Aaron, a manager, assigns a lesson to Steve, a learner. Lessonly will send an email from aaron@example.com to steve@example.com notifying Steve of the assignment. When this happens, the email is marked as being sent from lessonly.com on behalf of example.com. If the SPF DNS record for example.com is not set up to allow lessonly.com to send emails on its behalf, then the recipient's email server may assume this email is spam.

💡 Important Note: the SPF specification limits the number of DNS lookups to "at most 10 per SPF check." Section 10.1, "Processing Limits", of the SPF RFC reads as follows:

"SPF implementations MUST limit the number of mechanisms and modifiers that do DNS lookups to at most 10 per SPF check, including any lookups caused by the use of the "include" mechanism or the "redirect" modifier. If this number is exceeded during a check, a PermError MUST be returned. The "include", "a", "mx", "ptr", and "exists" mechanisms as well as the "redirect" modifier do count against this limit. The "all", "ip4", and "ip6" mechanisms do not require DNS lookups and therefore do not count against this limit. The "exp" modifier does not count against this limit because the DNS lookup to fetch the explanation string occurs after the SPF record has been evaluated."

This limit prevents SPF lookups from being misused for denial of service attacks.

To allow lessonly.com to send emails on behalf of example.com, an SPF entry must be present in example.com's DNS record. These are text entries that may look like this:

Additional senders are easy to add to an existing SPF record; just list each one in the same record:

The example above allows Lessonly to send emails on behalf of example.com. To be clear, the domain to include is:

DomainKeys Identified Mail (DKIM) allows an email system to verify that a message received from a particular domain was indeed sent by the owner of that domain. The Lessonly app signs all email notifications using DKIM keys. To verify the authenticity of these emails, you (or more likely, your email system) can check the message's DKIM signature against our DKIM public keys.

These keys are made public as TXT-type DNS records on the subdomains s1._domainkey.lessonly.com and s2._domainkey.lessonly.com.

Currently, the s1._domainkey.lessonly.com record reads:

The s2._domainkey.lessonly.com record reads:

For more information on DomainKeys Identified mail, see dkim.org.

Our email will come from the following IP address: 167.89.73.35

If SPF and DKIM aren't options, or if you've set them up but Lessonly emails are still being filtered as spam, disable the "Send assignment emails from assignor" setting. This option can be found in the Settings menu (the cog icon in the upper right), under Notifications.

By unchecking this option, Lessonly will send notifications as notifications@lessonly.com instead of the person making the assignment.