Standard Bank SPF records

Peralex

New Member
Joined
May 31, 2016
Messages
7
Reaction score
0
Does anybody know somebody at Standard Bank's IT department?

I'd like to suggest to them that they update their SPF records from ~all to -all. This would hard fail any dodgy phishing emails that claim to be from Standard Bank, which I believe would be useful for all of their customers.

I'm getting 10s of these phishing emails per day, as are many of my users, some of whom are prone to typing their bank details into any available form with a Standard Bank banner.

  • Investec, FNB, ABSA, Nedbank, Tymebank have their SPF records set to hard fail.
  • Standard Bank, African Bank, Capitec have theirs set to soft fail.
 
Speaking about Standard Bank: As a start Everyone should send Every Single phishing attempt that they receive to their phishing@ email address , maybe if they get some idea of just how much they are causing to get into their customer's email boxes, maybe they will wake up and do what any sensible major professional IT user would and fix their SPF record.
 
Does anybody know somebody at Standard Bank's IT department?

I'd like to suggest to them that they update their SPF records from ~all to -all. This would hard fail any dodgy phishing emails that claim to be from Standard Bank, which I believe would be useful for all of their customers.

I'm getting 10s of these phishing emails per day, as are many of my users, some of whom are prone to typing their bank details into any available form with a Standard Bank banner.

  • Investec, FNB, ABSA, Nedbank, Tymebank have their SPF records set to hard fail.
  • Standard Bank, African Bank, Capitec have theirs set to soft fail.

If you have full control over the receiving email server then you should be able to configure it to quarantine any emails using a "standardbank.co.za" from-domain that soft fail. This would be far easier than trying to convince Standard Bank's IT department to change their policies.
 
Does anybody know somebody at Standard Bank's IT department?

I'd like to suggest to them that they update their SPF records from ~all to -all. This would hard fail any dodgy phishing emails that claim to be from Standard Bank, which I believe would be useful for all of their customers.

I'm getting 10s of these phishing emails per day, as are many of my users, some of whom are prone to typing their bank details into any available form with a Standard Bank banner.

  • Investec, FNB, ABSA, Nedbank, Tymebank have their SPF records set to hard fail.
  • Standard Bank, African Bank, Capitec have theirs set to soft fail.

Check LinkedIn and send a message to their CEO. Either Sim or one of their many Heads
 
Does anybody know somebody at Standard Bank's IT department?

I'd like to suggest to them that they update their SPF records from ~all to -all. This would hard fail any dodgy phishing emails that claim to be from Standard Bank, which I believe would be useful for all of their customers.

I'm getting 10s of these phishing emails per day, as are many of my users, some of whom are prone to typing their bank details into any available form with a Standard Bank banner.

  • Investec, FNB, ABSA, Nedbank, Tymebank have their SPF records set to hard fail.
  • Standard Bank, African Bank, Capitec have theirs set to soft fail.
dont waste your time , they dont care
 
dont waste your time , they dont care
Yes they don't care.
I pointed this all out to them ages ago but they did nothing.
The SPF record is actually invalid!


mxtoolbox.png
dmarc.png
I am noticing loads of phishing emails coming through on various mail servers claiming to be from standard bank.

And the reason the messages are accepted by the MTA’s is because you have badly configured SPF and DMARC records.

This is terribly poor state of affairs for a bank of your standing.

Your DMARC should have a P=reject policy.

Your SPF should have -all (Not ~all which basically means accept anything “soft fail”)

Your SPF in one of your include lookups fails with too many “Void lookups” because it has a mx record check to itself (spf1.standardbank.co.za) which is just a text record so obviously fails!

If you want the MX to be included it cannot be in any of your include: links.
It should look like this:

v=spf1 mx include:spf1.standardbank.co.za include:spf2.standardbank.co.za include:spf3.standardbank.co.za include:spf4.standardbank.co.za -all

And every group entry of include: spf1, spf2, spf3 etc end in -all


DMARC should be:

v=DMARC1;p=reject;rua=mailto:[email protected];ruf=mailto:[email protected];fo=1;

Tue 2021-10-12 12:50:18.729: 09: Performing SPF lookup (ns1.lexien.co.uk / 159.89.120.21)
Tue 2021-10-12 12:50:19.005: 09: * Result: none; no SPF record in DNS
Tue 2021-10-12 12:50:19.005: 09: ---- End SPF results
Tue 2021-10-12 12:50:19.005: 09: Performing SPF lookup (standardbank.co.za / 159.89.120.21)
Tue 2021-10-12 12:50:19.180: 09: * Policy: v=spf1 include:spf1.standardbank.co.za include:spf2.standardbank.co.za include:spf3.standardbank.co.za include:spf4.standardbank.co.za ~all
Tue 2021-10-12 12:50:19.180: 09: * Evaluating include:spf1.standardbank.co.za: performing lookup
Tue 2021-10-12 12:50:19.538: 09: * Policy: v=spf1 mx a ip4:196.8.96.0/19 ip4:196.34.31.150 ip4:165.193.56.42 ip4:204.14.232.64/28 ip4:204.14.234.64/28 ip4:205.217.12.155 ip4:216.12.128.84/29 ip4:69.169.231.249 ip4:134.213.38.184/32 ip4:134.213.38.185/32 ip4:134.213.43.128/32 ip4:197.97
Tue 2021-10-12 12:50:19.562: 09: * Evaluating mx: no match - zero 'mx' type records
Tue 2021-10-12 12:50:19.746: 09: * Evaluating a: no match; no A record or error
Tue 2021-10-12 12:50:19.746: 09: * Evaluating include:spf1.standardbank.co.za: permerror; too many void lookups
Tue 2021-10-12 12:50:19.746: 09: * Result: neutral
Tue 2021-10-12 12:50:19.746: 09: ---- End SPF results
 

Attachments

  • pic1.JPG
    pic1.JPG
    68.4 KB · Views: 19
What i did was permanently cache a "corrected" version of their SPF records on my mail servers.
(Of course that means any changes they make won't reflect)

But the servers all give up trying to process the SPF record as the syntax isn't correct anyway.
 
If you have full control over the receiving email server then you should be able to configure it to quarantine any emails using a "standardbank.co.za" from-domain that soft fail. This would be far easier than trying to convince Standard Bank's IT department to change their policies.

They will all soft fail because the servers give up processing the SPF record because it is invalid.
It will never pass to begin with and if it was -all you wouldn't get any messages from them.

But a good thought none-the-less.
 
If you have full control over the receiving email server then you should be able to configure it to quarantine any emails using a "standardbank.co.za" from-domain that soft fail. This would be far easier than trying to convince Standard Bank's IT department to change their policies.

Thanks. That is (roughly) the solution that I eventually implemented, although the mail server software combination I'm using requires a per-user filter, and I just delete those messages rather than quarantining them. That could probably be improved on though.

Improved DNSBL choices subsequently made the filters virtually obsolete too.
 
What i did was permanently cache a "corrected" version of their SPF records on my mail servers.
(Of course that means any changes they make won't reflect)

But the servers all give up trying to process the SPF record as the syntax isn't correct anyway.

Thanks. That's probably the easiest option to implement actually.

The SPF software I'm using seems to survive the incorrect/invalid SPF records (for better or for worse), so it'll probably work fine.
 
Last edited:
Top
Sign up to the MyBroadband newsletter
X