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 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.
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
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 rule to our existing SPF DNS record. In other words: we must merge our existing SPF records with the recommendation given by Mailchimp.
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 consists of an optional prefix, the mechanism, and an optional value.
If the prefix is not set, it defaults to
The mechanism and optional value are separated using a colon.
v=spf1 part is called a modifier (note that modifiers use
= for separation instead a colon), an SPF record must start with the
So we'll retain the
v modifier as the start of our new SPF record.
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 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
After you made your changes, make sure to use an SPF validator tool to validate and inspect your new SPF record.
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:
||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.
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.
+all rule should never be used, as this would allow all senders to use your domain name.
?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 everything was accepted.
Now imagine MailChimp recommending you to add a
-all SPF rule, suddenly all your email could be rejected by a receiver, not ideal!
So, here is what you should do.
?all(pass all senders) or
~all(still pass, but do use the SPF validation result for spam detection).
-allto block any other (unauthorised) senders.
SPFtype DNS record
When SPF was first defined in RFC4408 it had its own
SPF type DNS record.
TXT type record was used as a backwards-compatible option.
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 discouraged, it is recommended to use the
TXT type record instead.
Although it is technically allowed to use both
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.
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 adding an additional SPF record.
An SPF record must start with
v=spf1 and typically end with an
all rule should be used as
-all, depending on how confident you are that you have all authorised email services listed in your SPF record.
In between the
all parts you add the various rules to allow services to use your domain to send email.