Overview

SPF merge guide

A common mistake we see happening is domains having multiple SPF DNS records, which is not allowed. Having more than one SPF record will lead to deliverability issues, fraud oppurtunities and in general will negatively impact your domain reputation.

A domain can only have one SPF record. If you want to authorize a new email service to use your domain name, you should add the new rule to your existing SPF record instead of creating a new record.

In this article we'll show you have to merge a SPF record as recommended by an email service to your existing SPF record.

Decorative header with envelopes

Why combining records is needed

Per the SPF standard an email receiver should only evaluate one SPF record. If you have multiple DNS SPF records there is no guarantee which one will be used. Some receivers will even return an error if a domain has more than one SPF record, this may result in the email not being delivered.

For example, you have this SPF record:

v=spf1 include:_spf.google.com -all

This is a typical SPF record for Google G-suite uses, it allows Google to send email using your domain name. All other senders are rejected using the -all rule.

Now, say that we want use a service like MailChimp to send our newsletter. MailChimp recommends using an SPF record like this:

v=spf1 include:servers.mcsv.net ?all

Since we already have an SPF record, we must add Mailchimp as a new rule to our existing SPF DNS record. In other words: we must merge our existing SPF records with the recommendation given by Mailchimp.

Merging SPF records

SPF records can be combined by combining the rules in both SPF records.

A rule is one of the parts of your SPF record, it consist of an optional prefix, the mechanism, and an optional value. If the prefix is not set, it defaults to + (pass). The mechanism and optional value are separated using a colon.

The v=spf1 part is called a modifier (note that modifiers use = for separation instead a colon), an SPF record must start with the v modifier. So we'll retain the v modifier as the start of our new SPF record.

v=spf1

Then we add both rules to our new record.

v=spf1 include:_spf.google.com include:servers.mcsv.net

Finally we must define a default behaviour for all senders that do not match the rules, which is done using the all mechanism. The all mechanism must come last, because SPF records are evaluated from left to right.

v=spf1 include:_spf.google.com include:servers.mcsv.net -all

This is now our new SPF record. It replaces the old record. The new SPF record allows Google and MailChimp to send email using our domain name, and all other senders are blocked using the -all rule.

After you made your changes, make sure to use an SPF validator tool to validate and inspect your new SPF record.

Choose an all prefix

As you might have noticed, in our example we used -all whilst MailChimp recommends ?all in their documentation. So whats up with that?

As a reminder, here are the acceptable values for prefixes:

Prefix Effect
+ A sender matching this mechanism should pass SPF validation
- A sender matching this mechanism should fail SPF validation
~ A sender matching this mechanism should soft-fail SPF validation
? A sender matching this mechanism should be treated as neutral

Read about all SPF rules in our main article on SPF.

The all mechanism matches every sender, so it is typically used as the last rule in SPF (remember, SPF record is evaluated from left to right). For SPF to be effective, the all mechanism can be used with - (fail) or ~ (soft-fail) prefix.

A +all rule should never be used, as this would allow all senders to use your domain name. And ?all should not be used either, as it effectively disables SPF.

Wait a minute! Why does MailChimp recommend ?all then? Well, because MailChimp does not know what your domain setup looks like, and they don't want to be responsible for causing a deliverability disturbance with your domain. Say you had a misconfiguration in SPF (or weren't using SPF at all), there was no method for receivers to validate a sender for your domain, so everyting was accepted. Now imagine MailChimp recommending you to add a ~all or -all SPF rule, suddenly all your email could be rejected by a receiver, not ideal!

So, here is what you should do.

The TXT type vs SPF type DNS record

When SPF was first defined in RFC4408 it had its own SPF type DNS record. The TXT type record was used as a backwards-compatible option. The SPF record type never caught on though and the majority of domains used the TXT type instead. When the SPF standard was refreshed with RFC7208 it was decided that the SPF type record was to be deprecated in favour of the TXT type record.

Although it is still allowed to use a SPF type record, its use is disencouraged, it is recommended to use the TXT type record instead. Although it is technically allowed to use both SPF and TXT type at the same time, you risk accidentally changing one and not the other. It is therefore recommended to only use the TXT type SPF record.

Conclusion

A domain can only have one SPF record. When authorising new services to send email for your domain you should add them to your existing SPF record instead of added an additional SPF record.

An SPF record must start with v=spf1 and typically end with a all rule. The all rule should be used as ~all, or -all, depending on how confident you are that you have all authorised email services listed in your SPF record. In between the v=spf1 and all parts you add the various rules to allow services to use your domain to send email.

Further reading


Mailhardener is an email hardening platform. It helps you to monitor your domain and email traffic to take full advantage of the email security standards. This helps prevent fraud and improve deliverability.
Sign up now