Now, assuming email settings are correct in a customer’s MIDAS system, then the most likely cause is a missing or incorrect SPF record for their organization’s own domain.
What is SPF?
SPF stands for “Sender Policy Framework”. Its purpose is to prevent unauthorized sending of email purporting to be from someone within your organization.
It’s function is best explained with an example…
Let’s assume that your cloud-hosted MIDAS system resides at “demo.mid.as”, and your own organization’s own domain is “example.com”.
You may wish your MIDAS system to be able to send emails appearing from “[email protected]” even when your booking system is hosted at another domain (i.e. demo.mid.as).
However, if an SPF record has not been correctly configured on your “example.com” domain to authorize “demo.mid.as” to send email on behalf of your organization’s own domain, emails sent from your MIDAS system will likely not arrive.
In a previous article we explain the importance of SPF in more detail. That article also covers how to correctly set an SPF record for MIDAS email delivery.
Anyway, back to email settings in MIDAS itself. Email settings may be configured via MIDAS Admin Options → Manage MIDAS → Email.
Email settings and SMTP Test button in MIDAS.
When choosing to have outgoing email sent via your organization’s own SMTP (mail) server, an “SMTP Test” button is shown. This allows you to send a test email to yourself using the SMTP settings you’ve entered.
SPF Record Check
Starting with MIDAS v4.28, we’ve added an SPF record check into this SMTP test for cloud hosted customers.
This will attempt to retrieve the SPF record for your domain. You’ll see a warning if the SPF record not been correctly configured to authorize your MIDAS system to send email on behalf of your organization.
We hope this check will assist our cloud-hosted customers in setting up an SPF record for their domain to ensure maximum email deliverability.
We believe in giving your clients control over the automated email notifications and reminders they may receive from your MIDAS system. To that end, we’re making some improvements in this area for v4.25.
Improved Client Email Notification Settings
Previously, each client in MIDAS could be set to receive the following email notifications:
None – Client isn’t sent any automated reminders.
Bookings – Client is sent automated reminders about their upcoming bookings.
Invoices – Client is sent automated reminders about their upcoming invoices.
Bookings + Invoices – Client is sent automated reminders about their upcoming bookings and upcoming invoices.
Automated client email notification from your MIDAS system included an unsubscribe link. This allowed clients to opt out of receiving further automated notifications from your MIDAS system. Effectively, the client’s “E-Mail Reminders” setting reverts back to “None”.
For v4.25, we’re extending the automated client notification email options. These now include:
Improved Client Email Reminder/Notification Options in v4.25
Bookings (Upcoming) – Client is sent automated reminders about their upcoming bookings.
Bookings (Recently Ended) – Client is sent automated follow-up emails after their bookings.
Invoices (Upcoming) – Client is sent automated reminders about their upcoming invoices.
Invoices (Overdue) – Client is sent automated reminders about their overdue invoices.
Clients can also unsubscribe from each notification type, rather than blanket unsubscribing from all notifications.
Easier For Clients To Unsubscribe From Notifications
MIDAS v4.25 now includes a “List-Unsubscribe” header in automated email notifications to your clients. This can make it even easier for them to opt-out of receiving further automated notifications from your MIDAS system.
Email software which support the “List-Unsubscribe” header may show a bar/banner at the top of emails, which users can click to opt-out of similar emails.
These are just a few of the new and improved features for MIDAS v4.25. Please see this post for details of other new features you’ll find in v4.25.
Over the past few articles, we’ve unvailed some of the new features in the next update (v4.24) to our MIDAS room and resource scheduling software.
In this article we’re revealing a new email notification. This notification can be configured to automatically send to your clients shortly after their bookings have concluded.
Those familiar with the extensive email notification capabilities of MIDAS will know that you can already configure MIDAS to automatically send clients a variety of notifications. These include; booking confirmations, reminders of their upcoming bookings, invoice payment reminders and more. In fact there are no fewer than 10 different email notification types available in MIDAS. Each of these may be individually customizable through the use of templates.
Send a post-booking email to your clients
For v4.24 we’re adding in an additional email notification template to the list – for “Booking Feedback”. The idea behind this is as follows. A short time after a client’s booking has taken place, MIDAS can automatically send them a courtesy follow-up email. This could simply thank them for their visit. It could also invite them to leave feedback on their room hire experience at your organization.
New “Booking Feedback” email template in MIDAS v4.24
As with all other editable templates in MIDAS, the new “Booking Feedback” template may be modified and customized to your particular requirements. Templates are accessed and modified via MIDAS Admin Options → Manage MIDAS → Templates. Your templates may be customized to include simple HTML code and placeholder variables.
As a side note, eagle-eyed viewers may also note from the above screenshot that we’ve also now made the Template Preview and Template Code areas vertically resizable! Previously these were both a fixed height.
Once you’ve customized your “Booking Feedback” email template, you can then enable it. You can set how long after a client’s booking has concluded MIDAS should wait before sending the email. These settings may be configured via MIDAS Admin Options → Manage MIDAS → Scheduled Tasks.
Enable a Scheduled Task to automatically email a client after their visit
For these post-booking emails to be automatically sent, you’ll need to have Scheduled Tasks configured on your server. If Scheduled Tasks are correctly configured, the “Last Run” time indicated in the above screenshot should show a time within the last 60 minutes. All our cloud-hosted customer’s MIDAS systems are pre-configured to run scheduled tasks. For self-hosted customers, if you’ve not yet configured Scheduled Tasks on your server, please refer to our KB article: How to configure your server to run Scheduled Tasks.
We hope our customers will appreciate this new notification and template addition to the forthcoming v4.24 update. In our next article, we’ll look at how the functionality of this new feature can be further enhanced with a brand-new optional addon. So stay tuned to our blog to discover more in the coming days!
In this blog post, we’ll take a look at SPF and why its important in ensuring email from your MIDAS room booking system is reliably delivered.
SPF stands for “Sender Policy Framework” and its purpose is to prevent unauthorized people from forging your e-mail address and pretending to be you. SPF has been around for a number of years now, but in recent times has been growing in popularity as more and more websites and email providers start enforcing it.
As our MIDAS web based room booking systems are capable of sending email on your behalf, it’s important to understand how SPF works and how it can help solve email delivery issues in MIDAS.
Take for instance the following example Scenario:
Your MIDAS system is running on domain “A” (i.e. your-organization.mid.as)
Your MIDAS system is configured to send emails to appear as though they are sent from an email address belonging to domain “B” (i.e. your-organization.com)
An email is sent from your MIDAS system to a recipient with an email address on domain C
In the above example, the receiving mail server for domain C queries the SPF record on domain B to check whether domain A is authorized to send mail on behalf of domain B. If it isn’t the email is rejected.
An SPF record is simply a TXT record in a given domain’s DNS, and a simple example may look similar to this:
v=spf1 +a +mx ~all
The format of an SPF record begins with a version number; the current SPF version is “v = spf1”. Following the version string, any number of expressions may be included which are evaluated in the order they appear. These consist of an optional “qualifier” (+, -, ~, or ?) and a “mechanism” (all, a, mx, ip4, or include). The first mechanism that is matched in the SPF record determines the result of the entire valuation of the SPF record.
Qualifiers:
Qualifier
Result
Description
+
Pass
Defines an authorized sender (If no qualifier is specified, + is assumed)
–
Fail
Defines an unauthorized sender
~
SoftFail
Defines an unauthorized sender (however it may not notify the sender that their email failed)
?
Neutral
Defines a sender whose legitimacy isn’t determined (In such instances, sending is allowed)
Mechanisms:
Mechanism
Applies if…
all
always
a
An A (or AAAA) record of the polled (or explicitly specified) domain contains the IP address of the sender
mx
An A (or AAAA) record of the polled (or explicitly specified) domain contains the IP address of the sender
ip4
The specified IPv4 address is the IP address of the sender or of the specified IPv4 subnet which contains it
include
An additional SPF request for the domain specified in the include statement contains the IP address of the sender
SPF records cannot be over 255 characters in length and cannot include more than ten “include” statements.
Email delivery will be allowed if it originated from the same domain it was sent (+a).
Email delivery will also be allowed if it originated from the specific IP address 1.2.3.4
Email delivery will be rejected if it originated from the IP address 5.6.7.8.
Email delivery will be allowed if it matches the rules defined in the SPF record on “somedomain.com”
All other email sources will be softly rejected (~all)
Bringing it back to MIDAS…
If you run a cloud-hosted MIDAS system at the domain “your-organization.mid.as”, your organization’s own website is “your-organization.com”, and you wish to allow your MIDAS system to send email on behalf of addresses @your-organization.com, then you should setup/modify an SPF record on your-organization.com.
This SPF record would authorize your hosted MIDAS system to send email on behalf of your organization. Failing to correctly set an SPF record for your domain may mean that emails sent from your MIDAS system may not reach recipients.
For our hosted customers, you can simply include “include:_spf.midas.network” in your-organization.com’s SPF record. Your new/modified SPF record may then look similar to this:
v=spf1 +a +mx include:_spf.midas.network ~all
In the above example:
Email delivery will be allowed if it originated from the same domain it was sent (+a).
Email delivery will be allowed if it originated from the same mail server as it was sent (+mx)
Email delivery will be allowed if it matches the rules defined in the SPF record on “_spf.midas.network”. This will allow your hosted MIDAS system to become an authorized sender of email for your domain.
All other email sources will be softly rejected (~all)
Remember, SPF records are simply TXT records within your domain’s DNS. If you’re not sure how to set/modify DNS records for your own domain, you’ll need to defer to the domain’s administrator, registrar, or hosting provider who should be able to assist in making the necessary adjustments to your domain’s DNS record
You can also ask questions and discuss the new features of v4.25 over on Reddit.
