System Email Authentication
Spektrix sends email messages on behalf of its clients. These emails are related to sales or account changes, rather than marketing emails which are handled by a third party provider DotDigital. This includes but is not limited to:
- Order Confirmation Emails
- Print at Home Ticket Emails
- Password Reset Emails
- Membership Renewal Notification Emails
- Scheduled Reports Emails
- Scheduled Customer Lists Emails
Our clients are strongly encouraged to configure a domain for use in their Spektrix system to impersonate their own domain for sending these emails. This helps avoid impact on deliverability and allows you to receive replies to the address.For example if a client's domain is venue.com, then they can choose to let Spektix send emails using a subdomain such as boxoffice.venue.com. To let Spektrix impersonate their subdomain to send system emails, some authentication is required. The set up is outlined below in this article.
Sending Subdomain
Clients must set up a subdomain to send their system mail from, and add the appropriate authentication against that subdomain rather than their root domain. This is so that, in the unlikely event of an ISP complaint being made as a result of any email being sent, only the subdomain is impacted and your root domain is protected. Additionally, it’s only possible to have one set of MX records against each domain and it is highly likely that MX records at the root domain are already in use.
For example, this could be: boxoffice.venue.com, rather than just venue.com.
Please let our support team know which subdomain you would like to use.Please note that it is not recommended to use the same subdomain as is used for any Custom Domain integrations with Spektrix.
Domain Authentication
Spektrix needs to be allowed to impersonate client domains using three forms of authentication. These are: A Sender Policy Framework (or SPF Record). A Domain Key, to enable Domain Key Identified Mail (or DKIM). MX Records, to help some email service providers authenticate received mail.
All three of these pieces of authentication are used to prove to Email Service Providers that email sent by Spektrix that impersonates client domains is legitimate and can be trusted. Without this authentication in place, then a fallback domain will be used by default or mail may fail to be received by customers.
To read more about DKIM click here.
Setting up SPF, DKIM and MX Records
SPF Record
To set up SPF for Spektrix simply add the following statement to an existing SPF record for your chosen sending subdomain:
v=spf1 include:mailgun.org ~all
DKIM
To set up DKIM, or Domain Key Identified Mail please contact Spektrix Support to confirm which sending domain you would like to use. Our Support Team will assist you with generating a Domain Key.
Please note that our Domain Keys are generated in 2048-bit.
MX Records
Please add the following MX records to your chosen sending subdomain:
mxa.eu.mailgun.org AND mxb.eu.mailgun.org (for clients in the UK, Ireland and Canada)
mxa.mailgun.org AND mxb.mailgun.org (for clients in the USA)
Best Practices
Email Logging
Spektrix is able to log email messages sent from the system, and track opens, clicks and receipt. Whilst clients do not have access to this logging, it is very important to help our Support Team troubleshoot any issues that might arise. In order to benefit from this, you can create the subdomain:
email.[sendingdomain]
For example, if your sending subdomain is boxoffice.venue.com, then you should create email.boxoffice.venue.com.
Once you’ve created the appropriate domain, add the following CNAME:
eu.mailgun.org (for clients in the UK, Ireland and Canada)
mailgun.org (for clients in the USA)
This will allow us to log any emails that Spektrix sends on a client's behalf.
Reply To Address
If a client’s system email is sent from an address that does not have a mailbox or where the mailbox is not monitored, then it’s possible to set up a Reply To address to direct any replies to a monitored mailbox. To do so, please contact Spektrix Support.
DMARC
Major email providers like Google, Microsoft, and Yahoo now require a DMARC record for high volume, also commonly referred to as bulk, email senders. At this stage, they expect only the record and not a configured DMARC policy. Without a record for your domain, emails may be filtered into spam folders or outright rejected by these providers. This not only includes marketing emails but also system emails such as order confirmations, password reset and login links.
For system emails, we can provide a basic DMARC record for you to add to your system email subdomain. This record does not implement DMARC but will satisfy the bulk sender requirements.
It’s important to check with your IT team or whoever manages your email systems to ensure DMARC changes won’t conflict with existing settings or policies. This is especially important if your company already has a properly configured DMARC record for your parent domain. Adding a basic record for a subdomain might remove the intended configuration.
For marketing emails, Dotdigital sets up email authentication, including a basic DMARC record, on your email domain. This record does not implement DMARC but will satisfy the bulk sender requirements.
If you have DMARC implemented on a parent domain and delegate a subdomain to Dotdigital you must let us know so your setup can be adapted. If you would like to change the record or add additional reporting addresses, contact our support team for help.
While we discourage its use, there is a fallback domain boxoffice-email.com available to ensure that emails will always be sent.
If a client is using DMARC or Domain-based Authentication, Reporting and Conformance then it may not be possible for them to use a fallback domain.
If DMARC is in place then using the fallback domain will have the following effects depending on which policies are set up.
p=none means that the fallback domain will still deliver mail as expected, but the DMARC report recipient may receive additional reports.
p=quarantine means that emails will be sent by the fallback domain but will be directed to spam folders and the DMARC report recipient will receive additional reports to this effect.
p=reject means that the emails will be sent by the fallback domain but won’t be received by the recipient at all and the DMARC report recipient will receive additional reports to this effect.
If a client has DMARC quarantine or reject policy then SPF and DKIM must be used otherwise Spektrix will not be able to reliably send emails on their behalf using a fallback domain or the client’s domain.