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 opportunities 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 term to your existing SPF record instead of creating a new record.

In this article we'll show you have to merge an 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 use with Google Workspaces (formerly known as G-suite), it allows Google to send email using your domain name. All other senders are rejected using the -all term.

Now, say that we want to 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 term 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 terms in both SPF records.

A term is one of the parts of your SPF record, it consists 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 of 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 terms to our new record.

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

Finally, we must define a default behavior for all senders that do not match the terms, 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 term.

After you make your changes, be sure to use an SPF record 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 what's up with that?

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

Prefix Effect
+ Any sender matching this mechanism should pass SPF verificaton
- Any sender matching this mechanism should fail SPF verification
~ Any sender matching this mechanism should soft-fail SPF verification
? Any sender matching this mechanism should be treated as neutral

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

The all mechanism matches every sender, so it is typically used as the last term 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 term 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 verify a sender for your domain, so everything was accepted. Now imagine Mailchimp recommending you to add a ~all or -all SPF term, 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 favor of the TXT type record.

Although it is still allowed to use a SPF type record, its use is discouraged, 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 authorizing new services to send email for your domain you should add them to your existing SPF record instead of adding an SPF record.

An SPF record must start with v=spf1 and typically end with a term using the all mechanism. The all mechanism should be used as ~all, only in specific cases would -all be acceptable (read: why Mailhardener recommends SPF softfail over fail). In between the v=spf1 and all terms you add the various terms 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