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.

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?