Suped

Does an SPF record need to be in a specific order?

It’s a common question I hear from people setting up their email authentication: does the order of my SPF record actually matter? The short answer is yes, absolutely. The long answer is a bit more nuanced. While the order of various DNS records on your server isn't important, the internal structure and sequence of the components within your single SPF record are critical for it to work correctly.

An improperly ordered SPF record can lead to validation failures, which can hurt your email deliverability. Let's break down the specific rules of order you need to follow.

Suped DMARC monitor
Free forever, no credit card required
Get started for free
Trusted by teams securing millions of inboxes
Company logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logoCompany logo

The non-negotiable starting point

Every SPF record must begin with the same component: the version number. This is not optional. The version tells receiving mail servers that they are looking at an SPF record and which version of the specification to use for evaluation.

www.spf-record.com logo
SPF-Record says:
Visit website
Each SPF record begins with a version number; the current SPF version with "v=spf1". An unlimited number of expressions follow, which are evaluated in the order ...

The correct version string is v=spf1. Any other value, or its absence, will cause the record to be ignored or result in a permanent error. This must always be the very first part of your record.

How mechanisms are evaluated: left to right

After the version tag, you list your mechanisms. These are the instructions that tell the server which IP addresses or servers are authorized to send email on behalf of your domain. Common mechanisms include a, mx, ip4, and include.

The receiving server evaluates these mechanisms in the order they appear, from left to right. As soon as it finds a mechanism that matches the sending IP address, the evaluation stops, and a result is returned. This is why order is so important. Placing a very broad mechanism too early could cause the intended, more specific mechanism to be ignored.

For example, consider the record: v=spf1 include:example.com ip4:1.2.3.4 -all. If a server receives an email from the IP address 1.2.3.4, it will first check if the IP is authorized by example.com. If it is not, it moves to the next mechanism, ip4:1.2.3.4. It finds a match, returns a 'Pass' result, and stops processing.

The final instruction: the 'all' mechanism

The all mechanism is a catch-all. It always matches and should always be placed at the very end of your SPF record. It dictates what should happen to emails from senders that did not match any of the preceding mechanisms. The action is determined by a qualifier.

  • -all (Fail): This is the recommended setting. It tells receiving servers to reject any email that doesn't match the authorized senders. This provides the strongest protection against spoofing.
  • ~all (SoftFail): This suggests that the email should be treated with suspicion but not necessarily rejected outright. It's often used when you're not fully confident in your SPF record yet.
  • ?all (Neutral): This essentially says you have no policy for unmatched emails. It offers little protection and is not generally recommended.

Placing all anywhere but the end of the record would cause all subsequent mechanisms to be ignored, rendering them useless.

A crucial rule: only one record allowed

This isn't about the order of components but is a critical rule related to SPF structure. A domain must have only one SPF record. If you add a second SPF record, for example when adding a new email service provider, it invalidates all of them.

www.zoho.com logo
Zoho says:
Visit website
According to SPF standards and RFC specifications, each domain must have only one SPF record. Why it matters. When multiple SPF records are present: Email receivers will perform an SPF check, see multiple records and the check will result in a PermError.

When a receiving server sees multiple records starting with v=spf1, it results in a 'PermError', and your SPF authentication will fail. The correct approach is to merge the mechanisms from all your sending services into a single, correctly ordered TXT record.

Conclusion

So, to recap: the order of an SPF record is vital. You must start with v=spf1, list your mechanisms in a logical left-to-right sequence, and always finish with the all mechanism. By adhering to this structure and ensuring you only have a single record, you provide clear instructions to receiving servers, which is a fundamental step in securing your domain and ensuring your emails reach the inbox.

Start improving your email deliverability today

Get started