In the continuity of my first article on " What is SPF? ", I propose a second article still dedicated to SPF.
While analyzing the SPF records of the TOP 100 E-commerce & CAC40 companies, I noticed that some SPFs had errors and that these could cause major problems with domain security or the proper delivery of e-mails (if these are used to send e-mails).
And when you know how important it is to protect your infrastructure against external threats (understand here spam and phishing)It is important to remember some rules of configuration or use. This is how the idea of this article was born... List you 10 tips to set up and use SPF on your domains.
Tip #1: We ALL need SPF...
It should be remembered that any domain that is not properly protected with the available authentication systems (SPF, DKIM, DMARC, BIMI) is a godsend for any pirate (or ill-intentioned person). The latter can use it without your knowledge to launch a spam or phishing campaign on your customers, your employees and/or your service providers.
Tip: Even if your domain is not used for sending e-mails (and even more if he is there)If you have a website, think about protecting it to reduce as much as possible the risks of misuse that can seriously damage your reputation and your brand!
Tip #2: Avoid using an obsolete mechanism...
According to RFC 4408 (cf. Request For Comments - official documents describing the technical aspects and specifications of the Internet)the PTR mechanism (cf. Pointer Record - record linking an IP to a domain name) has become obsolete and its use is not recommended because it slows down SPF reading. What's more, it's not as reliable as other mechanisms in the event of DNS errors. (see Domain Name Server).
Tip: Avoid any integration of the "ptr" mechanism in your SPF record. If it is necessary, prefer to add the associated IP in hard copy (using IP4 or IP6).
Tip #3: Declare SPF in a TXT record...
As of 2014, there is only one way to publish an SPF record, namely via a TXT record of the domain (cf. text recording that allows relaying information to third parties like SPF, Google Postmaster Tools code, ...)This one is easier and more practical.
Tip: Check now the method that was used to publish your SPF record in order to be sure that it is well conformed. If it is not the case, simply copy and paste the code into a new TXT record for your domain via your hosting company.
Tip #4: Limit the number of mechanisms...
Again, RFC 7208 indicates that the number of mechanisms (and modifiers) must not exceed 10 searches or else ISPs/Webmails will ignore your SPF record. The mechanisms involved are :
- Include
- MX
- A
- PTR (this mechanism is obsolete and should not be used anymore)
- Exist
Please note that IP4, IP6, All mechanisms will not count in the searches because it does not require a search on a domain name. BadExample with the domain "manomano.fr". This one has a total of 12 searches:
Tip: Do not hesitate to check your SPF record now to see if the number of mechanisms is correct. If it is not, you will have to simplify it.
#5 Tip: Do not declare too many MX resources...
(Still) Our beloved RFC 7208 states that the evaluation of each MX record must not result in more than 10 type "A" records (cf. which links a domain name to one or more IPv4) or "AAAA". (cf. which links a domain name to one or more IPv6). If the limit is exceeded, the MX mechanism should produce a "permerror" result and thus SPF will fail.
The MX record refers to 19 records of type A :
Tip: If you add the MX mechanism in the SPF record, remember to check that it does not refer to too many searches (if necessary, simplify it).
Tip #6 : Put one and only one SPF record per domain...
There can be only one SPF record per domain (always declaring it in the TXT record). If you have one 2èmeit will not be read and therefore interpreted. On the other hand, a domain can have several DKIM keys declared in its TXT record (we will see this in detail in a future article).
- No BadExample on the TOP 100 E-Commerce companies, nor on those of the CAC40, but I already had business at this problem on an audit. The customer was using 2 routers and had created 2 SPF records (instead of one SPF record with 2 mechanisms "include").
Tip: If you have several external sources to declare in your SPF record, you have two solutions: either add all the IPs in hard copy (be careful not to exceed 255 characters)or add several "includes". (be careful not to overlap too much) referring to the IP of your router (for example : spf.splio.com => refers to all IPs used by Splio) but under no circumstances should you create an SPF record by external source on your domain.
Need help?
Reading content isn't everything. The best way is to talk to us.
Tip #7: Declare at least one mechanism in SPF...
One of the objectives of SPF is to protect a domain name from abuse by third parties. To help you block this illegitimate traffic, you will need to declare in the TXT record of the domain all the mechanisms (from a simple IP to the SPF of your router) who will be allowed to send emails with your domain name.
Even if I understand the approach of locking a domain that would not be used by prohibiting all traffic, it is still risky to say that we is sure to 100% that it will never be used because sf tomorrow Airbnb decides to send e-mails (even internal) with this areaall ISPs/Webmails checking SPF would block all their emails.
Tip: Even if you don't send emails with a domain that you own, remember to add at least some mechanisms to your SPF recordThis is to avoid any change in routing strategy that would have an impact on the (unless you are called Airbnb).
Tip #8: Forget the "+all" mechanism/qualifier...
The use of the mechanism/qualifiers (+all) will allow anyone to finally use your domain since you allow all IPs to broadcast with your domain (it's a gift!). As a reminder, SPF must be set to "restriction" mode to be really effective.
At a pinch, this mechanism (+all) can "potentially" (I say potentially) be used at the very beginning of the implementation of SPF if your infrastructure is heavy but must necessarily be coupled with DMARC. In any case, it should only be used in the very very very short term and a switch to "~all" should take precedence quickly before the switch to "-all".
All the "All" mechanisms (including those included in the "include) are in "+".all"which means that alls e-mails will be accepted by ISPs/Webmails (without any restrictions - so it doesn't matter if the IP used with the laredoute.en or declared in SPF or not...). I would add that no DMARC record is present on the main domain, which makes it "incredibly" vulnerable. And SPF a here no interest !!!
Tip: Prefer the default "~all" mechanism/qualifier if you are not ready to switch to "strict" ("-all") mode.
Tip #9 : Check its configuration after any modification...
When your SPF registration is in place (or if you modify it at a moment T)it is important to use an external tool (as Mxtoobox or Dmarcanalyzer) which will allow you in a fraction of a second to check that your SPF registration is correct. Be aware that if it returns an error, you may be tagged as "suspicious" by the ISP / Webmail and therefore see your emails not being delivered or delivered as spam.
- No BadExample on the TOP 100 E-Commerce companies and of the CAC40. A client for whom we do monitoring had made changes to our recommendations but had unfortunately makes a syntax error that made SPF invalid.
Tip: ALWAYS remember to check your SPF record after any creation or modification to make sure everything is ok (especially since it will only take you a few seconds). During this step, tell all your teams not to send any e-mails.
Tip #10: Monitor SPF via DMARC
Setting up SPF on your domain is fine, Adding DMARC is better! With the aggregate reports provided by DMARC, you can monitor SPF flows and identify :
- Non-legitimate IPs that send emails with your domain and without your knowledge!
- Legitimate IP's but forgotten in the SPF settings (and makes the traffic non-compliant).
You will have no other way to know if a non-legitimate IP is using your domain (unless you receive a spam directly on your professional or personal address).
- No BadExample for this point 10 even if still today, 42 TOP100 E-Commerce companies with SPF registration have not yet deployed DMARC on their main domain against 14 CAC40 companies.
Tip: If you haven't yet taken the plunge and implemented DMARC on your main domain, go for it. The advantage of DMARC is that you can have detailed visibility of IP traffic passing through your domain. And as I said at the beginning of this article, no company is safe from spam and phishing.
Conclusion
Now it's up to you to produce or optimize your SPF record. I'm repeating myself once again, but no company is safe from a phishing attack one day, so the implementation of authentication systems (SPF/DKIM/DMARC/BIMI) Is borderline "mandatory." Think about it if 🙂
P.S.: I hope that the companies mentioned as examples will take the opportunity to correct theirs (if you read me :p)
You can also read our latest articles on email authentication:
- What is SPF?
- DMARC usage in CAC40 companies in July 2020
- BIMI is good, eat it!
- Deliverability: SPF, DKIM, DMARC, ... what you need to know about email authentication!
Badsender, emailing expertise agitator! Badsender is a team of craftsmen specialized in the various disciplines surrounding email marketing! Our emailing agency intervenes on questions of strategy, design, orchestration and deliverability. We offer this expertise in the form of coachingWe can also provide services such as audits, or act as an outsourced production force.
