Using SEQTA with Email Relay Services

TABLE OF CONTENTS

• Option A: SEQTA-linked SendGrid Email Service(Incl. Department of Education WA)
• Option B: School-Provided Email Service  
• Useful links

A Simple Mail Transfer Protocol (SMTP) Relay server improves a SEQTA server's ability to send Pastoral Care Notifications and Bulk communications to Staff, Students and Guardians, since it doesn't rely on SEQTA's client-shared infrastructure.

Emails sent through a properly configured relay, are significantly less likely to end up as SPAM or junk in the recipients email application since  there are steps we can use to increase the level of trust email services (like Google’s Gmail, Microsoft’s Hotmail, Outlook etc) have with the service. Most relay services also manage higher loads than our client-shared services, which will result in recipients receiving correspondence with minimal delays. In short, it ensures emails are reliably sent and are much more likely to end up in recipient's Inboxes.

Before Continuing: Schools should consider whether their Notification emails (Default "from" email address in your SEQTA's Application Setting) are a different email domain from your user's email addresses in Staff accounts (Staff section under Data Management), and whether your preferred email option covers both scenarios.

Option A: SEQTA-linked SendGrid Email Service
(Incl. Department of Education WA)

To allow us to enable this service at a school site we require:

• Outbound access to authenticated mail services (SMTP) on port TCP/587. 
• A signed SendGrid Subscription Agreement with Education Horizons 
• Contact Name - a primary contact for the SendGrid account's creation
• Login Email - an email to allow you to login and monitor usage and other tasks. The login email is suggested to be a common email or distribution list to ensure the login is not tied to a specific person.

School's will be asked to enable a 2FA upon first login, as enforced by SendGrid on all their accounts. Two-Factor Authentication (2FA) can be tied to a specific mobile using Microsoft Authenticator, but it's strongly suggested clients utilise a shared one-time password (TOTP) system such as Authy, LastPass, PasswordState, BitWarden, etc to allow multiple staff to log in if necessary. 
 

The school’s listed SEQTA Technical Contact will be supplied with credentials to create additional (API Key) logins for use with other services requiring outbound mail. This also provides the school with means to monitor the specific email volume of each device/account.

Option B: School-Provided Email Service  

For schools opting to use their own service we will require the following details:  

• Outgoing mail server and port (eg. smtp.office365.com:587)
• Username or API Key  
• Password or API secret  (see requirements below)
• Any specific connection notes (eg. TLS Encapsulation)
• The sending email address 'email from address' (eg. info@schooldomain.state.edu.au)

Other requirements:

• SPF records need to be amended as required
• Outbound access on port TCP/587 if authenticated mail services are used
• Most services are moving towards "App Passwords" (Google) or "Azure Communication Services Email" (Microsoft) and removing BASIC AUTH for outbound email.

Useful links

• Office365 users should read and understand the ramifications of SMTP Auth with O365 (Option #1) of Multifunction device or application to send email using Office 365 including SendAs permissions.
• G-Suite users should read SMTP relay: Route outgoing non-Gmail messages through Google and ensure the account we are provided has a "App Password" as the old "Less Secure App" or LSAs are being deprecated by Google.
  Note: A Google account password change also resets the App Password, and we'll need to be supplied with the updated password as soon as possible.