If your MIDAS booking system is currently configured to send emails via Microsoft’s SMTP servers, it’s time to take action.

Microsoft has announced that it will be retiring support for SMTP AUTH (also known as “Basic Authentication” for SMTP) in 2026. Once this change takes effect, any application which is configured to use Microsoft SMTP endpoints for outgoing mail will no longer be able to send emails.

For MIDAS, if you’re using Microsoft’s SMTP servers, this means that booking confirmations, reminder emails, and other automated notifications sent from MIDAS would silently fail – potentially disrupting your organization’s scheduling and communications.

Here’s what you need to know, and what steps to take before the deadline.

What Is SMTP AUTH and Basic Authentication?

SMTP AUTH is a method that allows applications to authenticate with a mail server using a username and password in order to send outgoing email. It has been widely used for decades.

Why is Microsoft removing Basic Authentication and SMTP AUTH?

It’s worth noting that Microsoft’s decision to retire SMTP AUTH is driven by their own platform strategy around modern authentication – it doesn’t mean that sending email via SMTP is inherently insecure. Under the hood, SMTP works the same way it always has, and the username/password authentication used by SMTP hasn’t fundamentally changed. What Microsoft is retiring is the ability to authenticate to their mail servers this way, as they push users towards OAuth-based access within their ecosystem. MIDAS does not currently support OAuth, but this is not a concern — there are plenty of reliable, independent SMTP providers that continue to support standard SMTP authentication without any issues.

Are You Affected?

You may be affected if your MIDAS booking system’s outgoing email settings are currently configured to use any of the following SMTP servers:

• smtp-mail.outlook.com — used by personal Outlook.com/Hotmail accounts
• smtp.live.com — an older endpoint also associated with Outlook.com/Hotmail/Live accounts
• smtp-legacy.office365.com — a temporary fallback endpoint for Microsoft customers that stilled relied on SMTP AUTH after the initial Basic Auth deprecation push.
• smtp.office365.com — An Exchange Online endpoint used by Microsoft 365 services.
• outlook.office365.com — another Exchange Online endpoint sometimes used in place of smtp.office365.com

You can check your current email sending settings via MIDAS Admin Options > Email.

The good news is that the fix is straightforward, and we’ve made it as easy as possible for MIDAS customers.

For Cloud-Hosted MIDAS Customers

If you’re on our cloud-hosted platform, we have the simplest possible solution for you: switch to MIDAS’s built-in Zero-Configuration Email Delivery.

This option requires no SMTP credentials, no third-party accounts, and no technical configuration on your part. MIDAS handles email delivery on your behalf, so you don’t need to worry about SMTP servers at all. You can find full details on how to enable this feature in our dedicated guide:

👉 Zero-Configuration Email Delivery for MIDAS

We strongly recommend all cloud-hosted customers make this switch at their earliest convenience – and certainly before Microsoft’s 2026 deadline.

For Self-Hosted MIDAS Customers

If you run MIDAS on your own server or hosting environment, you’ll need to update your outgoing mail settings to use an alternative SMTP provider. Fortunately, there are several excellent options available, many of which offer generous free tiers that would suit most MIDAS installations.

We recommend the following providers:

SMTP2GO

SMTP2GO is a reliable, cloud-based email delivery service with a free tier that allows up to 1,000 emails per month. It’s straightforward to set up and works seamlessly with MIDAS’s outgoing mail settings. Simply create a free account, verify your sending domain, and update your MIDAS SMTP settings with the credentials provided.

Mailgun

Mailgun is another popular transactional email service offering a free tier for low-volume sending. It provides robust deliverability, detailed sending logs, and is well-suited for automated system emails like those generated by MIDAS. After signing up and verifying your domain, update your MIDAS SMTP configuration with your Mailgun credentials.

To update your SMTP settings in MIDAS, navigate to MIDAS Admin Options > Email and enter the new SMTP server details provided by your chosen transactional email delivery service.

Don’t Wait Until It’s Too Late

According to Microsoft, their revised SMTP AUTH Basic Authentication Deprecation Timeline is as follows:

• Now to December 2026: SMTP AUTH Basic Authentication behavior remains unchanged.
• End of December 2026: SMTP AUTH Basic Authentication will be disabled by default for existing tenants. Administrators will still be able to enable it if needed.
• New tenants created after December 2026: SMTP AUTH Basic Authentication will be unavailable by default. OAuth will be the supported authentication method.
• Second half of 2027: Microsoft will announce the final removal date for SMTP AUTH Basic Authentication.

While Microsoft’s deadline is the end of December 2026, we recommend customers make this change sooner rather than later.

Email is a critical part of how MIDAS keeps your staff and visitors informed – from booking confirmations to reminders and notifications. A disruption to outgoing mail can go unnoticed until someone realizes they never received a confirmation, which can cause real-world scheduling problems.

Taking a few minutes now to update your settings will ensure uninterrupted email delivery well into the future. If you have any questions or need assistance, please don’t hesitate to contact our support team – we’re happy to help.

The post Microsoft SMTP AUTH Deprecation in 2026: What You Need to Know appeared first on MIDAS - Room Booking System | Blog.

The ability to send email is essential for any booking system.

From booking confirmations and reminders, to invoices, notifications, and password resets, booking and scheduling systems rely on email.

MIDAS naturally supports the sending of email, but we’ve made some exciting and significant improvements to email sending for our cloud-hosted customers for v4.42.

But first, let’s look at the existing ways in which MIDAS can send email.

Until now, the sending of email by MIDAS has been through a choice between “Sendmail” or “SMTP”.

What is Sendmail?

Available on Linux-based servers, Sendmail is a built-in server application for sending email directly from the server itself. Read more about Sendmail.

What is SMTP?

SMTP (or Simple Mail Transfer Protocol) is the standard language used by computers to send emails across the internet. Read more about SMTP.

Sendmail vs SMTP

Both Sendmail and SMTP options have been available in both our cloud-hosted and self-hosted editions.

“Sendmail” has long been the default ‘out of the box’ email transport setting for cloud-hosted customers. However, we’ve always encouraged customers to move over to SMTP as soon as possible.

That’s because generally email deliverability rates are substantially higher when MIDAS is configured to send email through a customer’s own SMTP server, than if instead sent directly through our own servers.

Whilst Sendmail is configured to work ‘out of the box’ for cloud-hosted customers, SMTP requires a little more configuration.

To configure MIDAS to send email via SMTP, you will need:

• The address of your SMTP server
• The correct port number
• The SMTP username and password
• The correct SSL, TLS, or STARTTLS encryption method setting

You will also need to ensure that your SMTP server accepts connections from your cloud-hosted MIDAS system. In addition, your organization’s domain must be configured to allow MIDAS to send email on behalf of your domain.

This requires significant configuration and setup. We want to simplify this for our cloud-hosted customers. That’s why we’re introducing cloud email sending.

Introducing “Cloud Sending”

For MIDAS v4.42, we’ve introduced a new “Cloud” option for sending email. This new option is available to all cloud-hosted customers, and replaces the previous “Sendmail” option. (Sendmail continues to remain an option for self-hosted customers).

With the new cloud email option selected, you won’t need to specify an SMTP host, or enter credentials or specify ports – MIDAS will take care of all of that!

We have partnered with a dedicated transactional email provider specializing in high-deliverability email delivery services, to provide efficient and reliable email delivery for cloud-hosted customers who select the “Cloud” email sending option.

Zero Configuration Email Sending

To complement our new “cloud” email offering, we’ve also included a “Zero Configuration” option.

With this option enabled, MIDAS and Mailgun will seamlessly handle email delivery for your MIDAS system. You won’t need to configure an outgoing email address, nor will you need to update your organization’s domain’s SPF (Sender Policy Framework) DNS record – email will just ‘work’ right out of the box.

Of course, if you wish to customize the “send from” or “reply to” addresses, you can untick the “Zero Configuration” option and change those settings.

But in its simplest form, our new “cloud” email sending and “Zero Configuration” options mean that brand new cloud-hosted email systems can now reliably send email right from the outset.

Migrating from Sendmail to Cloud email sending

For our existing cloud-hosted customers, if you’re currently using the “Sendmail” option in your MIDAS system, you’ll be automatically migrated to “cloud” sending soon after we update you to v4.42.

If you do not wish to use the new “Cloud” sending option, you should update your MIDAS settings to instead send email via SMTP.

You can change your MIDAS email settings via MIDAS Admin Options → Manage MIDAS → Email.

If your cloud-hosted MIDAS system is currently configured to send email via SMTP, this setting will be unaffected when we update your booking system to v4.42. Of course, you can then always change over to use the cloud email sending option at any time.

The post Zero Configuration Email Delivery for Cloud-Hosted Customers appeared first on MIDAS - Room Booking System | Blog.

As this can be done without requiring a login or a user account. When making a “public” booking/request, the person simply needs to enter their details. This will typically include their name and contact email address.

When a public web booking/request is made, MIDAS checks the email address that’s been entered against its existing client database.

If a single matching client with the same email address already exists in the client database, MIDAS will associate the booking/request with that existing client.

This negates the need for a person to have to re-enter all their information (i.e. address, phone number, etc) each time they make a web booking or request.

MIDAS can also be configured to allow individuals to update their information each time they make a web booking or request.

Multiple clients with the same email address

But what if there is more than one existing client with the same email address as the person making the web booking / request?

In these instances, MIDAS will not only compare the email address given, but also the client and organization names provided.

If there is a single exact match based on this additional information, MIDAS will associated the booking/request with the one matching client.

Again, MIDAS can be configured to update the existing client record at time of web booking / request with new details supplied by the individual.

The problem

There is however an “edge case” where the above options don’t quite go far enough.

Take for example an individual who uses their personal email address to make web bookings or requests for multiple different organizations they’re associated with.

That’s no problem if there are existing client records for the client for each of their organizations. But it becomes an issue if this is a brand new client. It’s also an issue if this is a person with just a single existing client record under one of their organizations.

Here’s an example to illustrate:

Let’s say Jeff is associated with two organizations – let’s call them “A” and “B”.

Let’s also assume that Jeff is a brand new client. There is therefore currently no client record with the same email address existing in your MIDAS system.

Jeff makes a booking request using his personal email address on behalf of organization “A”. A new client record is created for Jeff using this information.

A short while later, Jeff makes another booking request. He uses his personal email address again, but this time he’d like to make a request for organization “B”.

When Jeff makes his second request, MIDAS will see that there is already a single client in its database matching Jeff’s email address. One of two things will then happen, depending whether the “Allow client record updates” setting has been enabled in MIDAS.

If the “Allow client record updates” option is disabled, MIDAS will reuse Jeff’s original details (i.e. organization “A”). This will result in both his booking requests being for organization A.

If the “Allow client record updates” option is enabled, MIDAS will update Jeff’s original details (i.e. to become organization “B”). This will result in both his booking requests being for organization B.

…but that’s not what we want! We want his first request to be for organization A, and his second for organization B.

The solution

Instances of someone making web bookings / requests on behalf of multiple organizations using the same email address are uncommon. But we still wanted to better accommodate this scenario.

So for MIDAS v4.37 we’ve introduced a new “Account for multiple clients/organizations sharing the same email address” setting.

Enabling this setting will automatically create additional client records for each client/organization variant using the same email address.

The result – in our illustrative example above – would be that Jeff can make booking requests for either organization A or B (or even a future organization C) using his personal email address without issue.

The post Better support for “shared” email addresses appeared first on MIDAS - Room Booking System | Blog.

We first introduced invoicing capabilities to our MIDAS room booking software way back in 2009.

Since then, it’s fair to say that invoicing has been the area that we receive the most suggestions from our customers for new features and capabilities.

That’s why over the years we’ve been constantly expanding and improving the invoicing capabilities in MIDAS.

In the past 12 months alone, we’ve allowed customers to set even more flexible venue rates. We’ve also added Zoho Invoice to the growing list of 3rd party platforms you can export MIDAS invoices to. Additionally, we also added a couple of handy invoice tools too.

Now, the ability to be able to directly email an invoice to a client from within MIDAS is something that’s not new. In fact, it’s been available in our software ever since invoicing was first introduced.

This feature allowed a user to send an email to a client, with a copy of their invoice included in the body of the email.

For many of our customers this has worked well for many years, and continues to do so.

However, as the web continues to evolve, sadly many email clients haven’t kept up with more modern formatting and layout standards. This prompted us to recently introduce an new “Email Compatibility” setting. This setting helps ensure that invoices sent via email to your customers display correctly in the body of the email when it’s viewed.

Whilst this means that everyone can view a correctly formatted invoice contained within an email sent from a MIDAS system, we know that some customers would still prefer to send an invoice as a PDF file to their clients.

Until now, in order to send an invoice from a MIDAS system to a client in PDF format, a user would need to “save” the invoice to a PDF file. This file would then need to be attached and sent via an external email program.

Let’s be honest, this isn’t ideal! It would be far simpler if you could send PDF versions of invoices to clients directly from within MIDAS.

That’s why starting from MIDAS v4.32, you’ll now have the option to be able to send invoices to your clients as PDF attachments, rather than “inline”.

To enable this option, cloud hosted customers can go to MIDAS Admin Options → Manage MIDAS → Email → Advanced. On this screen, tick the “Send invoices as PDF attachments” option and save changes.

For self-hosted customers, you’ll need to be running at least MIDAS v4.32. In order to enable this functionality, there’s also a couple of additional prerequisets you’ll need to install on your server first.

We’re also providing you with controls over the page size and orientation of generated PDFs. You can also control page margins too.

The post How to send invoices as PDF attachments appeared first on MIDAS - Room Booking System | Blog.

In MIDAS v4.30 we’ve introduced a new “Send invoices in compatibility” setting.

In this post, we’ll look at why such an option was needed…

Now, back in MIDAS v4.26 we made some changes to improve the way that invoices were rendered.

This involved updating some of the HTML code that MIDAS uses to display invoices to user newer standards.

Prior to v4.26, invoices were laid out using HTML “tables”. Using tables allowed data to be set out in columns and rows. This allowed a dedicated “row” for each item on an invoice, and dedicated columns for its description, quantity, rate, etc.

Since v4.26, MIDAS has instead used a more modern CSS “grid” layout. This allowed invoices to better adapt to fit different screen widths.

However, whilst all the browsers we support also support CSS “grid” layouts, sadly not all email clients do!

To our surprise, some editions of Outlook and Gmail don’t support CSS grid layouts. Instead, they actually modify any emails they receive so that when they are displayed any CSS grid layout information is “stripped” from them!

There is really no logic to this, or indeed consistancy!

For instance, Gmail’s “desktop” webmail strips out CSS grid information, but their “mobile” webmail doesnt!

Another example if Outlook; if you view an email using the Windows Outlook client, the CSS grid information is removed. If you view the same email using the MacOS Outlook client, the CSS grid information is retained!

Other popular email clients, including Thunderbrid and Apple Mail support CSS grid layouts without issue.

You can find a current list of which email clients support (or otherwise) CSS grid layouts here.

The result is that if you view an emailed invoice from MIDAS, how that invoice is presented depends very much on the recipient’s email client.

To illustrate, take a look at the following invoice….

Above is the exact same invoice viewed by two different mail clients. The first (and correctly displayed) uses Thunderbird to view the invoice. The second views the same invoice via outlook.com.

As you can see, because outlook.com strips out any CSS grid information from the HTML email, the result is that the email doesn’t display as intended. Rather than Description, Quantity, Rate, Tax, and Amount all being in separate columns, Outlook’s removal of the important CSS grid information causes these items to be displayed on separate rows instead!

We are at a loss to explain why certain email clients decide to “strip” out and remove CSS grid layouts, especially when CSS Grid Layouts are an official W3C specification, and supported by all modern browsers.

However, to work around this issue, we’ve now introduced a “Send invoices in compatibility” option. You’ll find this setting via MIDAS Admin Options → Manage MIDAS → Email → Advanced.

With this option enabled, MIDAS will revert to using HTML “tables”, rather than a CSS grid layout for invoices emailed through the system.

So if you have clients who aren’t able to view invoices you send them correctly, then enabling this setting should help.

We hope going forward that popular email clients – including Outlook and Gmail – will review their stance on not supporting modern layout standards – such as CSS grid. There’s really no reason not to support CSS grid. This is especially true for web-based email clients, where the client’s own browser support’s CSS grid, but the email client forcibly removes this information from emails.

The post Ensuring Email Compatibility With Older Mail Clients appeared first on MIDAS - Room Booking System | Blog.

MIDAS is no exception, and an extensive range of email settings and options are available in the software. Administrative users may configure these via MIDAS Admin Options → Manage MIDAS → Email.

One of the available email settings allows you to have email notifications sent from your MIDAS system to be sent from a particular email address.

Typically, for automated emails that you don’t require a response to, you may specify a “no-reply” style address.

However, what if you want to provide a way for your customers to contact you should they have any queries?

Well, you could use a real email address instead of a no-reply “black hole” inbox which isn’t monitored.

Or, from MIDAS v4.29 onwards, you could instead specify a “Reply To” email address. This can be different from the address that emails from your MIDAS system are sent from.

In the above example screenshot, all email sent from the MIDAS system will be sent as though it originated from the address “noreply@example.com”.

However, if a recipient of an email from this MIDAS system hits “Reply”, they’ll be composing a message that will be sent to “roomhire@example.com” (instead of “noreply@example.com”.

This new setting adds a standard “Reply-To” header to all outgoing email from your MIDAS system.

More information on the various email configuration options and settings in MIDAS may be found in the documentation.

The post Specify an alternate “reply to” email address appeared first on MIDAS - Room Booking System | Blog.

We have a useful “Why am I not receiving email from my MIDAS system?” article in our extensive Knowledge Base. Its purpose is to help users resolve common email deliverability issues.

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 “bookings@example.com” 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.

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.

The post SPF record checking in cloud hosted MIDAS systems appeared first on MIDAS - Room Booking System | Blog.

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:

• 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.

You can also ask questions and discuss the new features of v4.25 over on Reddit.

The post Client Notification Improvements appeared first on MIDAS - Room Booking System | Blog.

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.

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.

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!

The post New Booking Feedback Email & Template appeared first on MIDAS - Room Booking System | Blog.

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:

Mechanisms:

SPF records cannot be over 255 characters in length and cannot include more than ten “include” statements.

Example SPF record:

v=spf1 +a +ip4:1.2.3.4 -ip4:5.6.7.8 +include:somedomain.com ~all

In the above example:

1. Email delivery will be allowed if it originated from the same domain it was sent (+a).
2. Email delivery will also be allowed if it originated from the specific IP address 1.2.3.4
3. Email delivery will be rejected if it originated from the IP address 5.6.7.8.
4. Email delivery will be allowed if it matches the rules defined in the SPF record on “somedomain.com”
5. 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:

1. Email delivery will be allowed if it originated from the same domain it was sent (+a).
2. Email delivery will be allowed if it originated from the same mail server as it was sent (+mx)
3. 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.
4. 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

Further reading from our Knowledgebase:.

• Emails fail with “SPF fail – not authorized” or “DMARC Evaluation” errors
• Why do outgoing emails contain a warning that they may be “spoofed”?
• Why am I not receiving email from my MIDAS system?

The post Improve email delivery: The importance of SPF appeared first on MIDAS - Room Booking System | Blog.