Visit Freshworks.com Visit Freshworks

Freshdesk very long SPF record is a problem

  • 10 January 2022
  • 32 replies
  • 6683 views
L
Rank
Userlevel 1
Badge

Hi, we are using Freshdesk support desk and until now Freshdesk has been sending email’s on our behalf. This means that we have to add email.freshdesk.com to our SPF record. This means that Freshdesk alone adds 8 DNS queries to our SPF record and the standard allows for only 10 in total.

For comparison Microsoft adds two for the whole of Office 365.

Now, what i have feared has happened and we have passed the limit and our SPF record is not valid anymore. I don’t know if we added the one or if Freshdesk added another sub record.

There is really two problems, one is the size of the record to begin with and the other is that Freshdesk can add subrecords at anytime without any of their customers knowing and pushing that client over the limit.

I think therefore it is very important for suppliers that have SPF that is used by alot of customers to be very small and maintained correct.

One solution is to create your SPF record and then only add ip addresses to this record that you then maintain when something is moved or reconfigured. This would reduce the number of DNS queries from 8 to 1.

We are depended on our SPF, Dkim and DMARC to be perfect to run our business and we are therefore reconfiguring the service to send the mail directly through our Office 365 tenant so we can remove the records.

This can be a solution for other customers that have the same problem.

32 replies

C
Rank

+1

I’m an mail security professional and this is a serious problem that Freshworks needs to start taking seriously. This SPF config is bad practice and exemplifies both bad attitude and a lack of email security knowledge. 

B
Rank
Badge

I believe that the new DKIM setup that was implemented can possibly solve this now.  When you go into the DKIM Settings (under Email Settings → Advanced Settings), one of the CNAMEs it asks you to create is “fwdkim1.<yourdomain>”.  When sending an email from your domain through the Freshdesk mail server, it uses that as the server address, so when checking the SPF it does a lookup of the TXT record on this CNAME, rather than on your root domain.  As a result of all this, you no longer need to have the Freshdesk domains in your root domain’s SPF record at all anymore, since it will use this CNAME instead.

This is alluded to in the Solution article here that mentions it has “SPF check within the DKIM records”:

https://support.freshdesk.com/support/solutions/articles/223779-email-domain-verification-using-dkim-records

I’ve implemented it this way on our domains and they are all passing SPF when sent through Freshdesk, although I made no changes to the root domain’s SPF record.

JTAVOLARO
Rank
Userlevel 5
Badge +8

I’m amazed that this SPF issue is still not resolved.

Freshworks, what is the plan to fix this problem?

Juliana Rozario
Rank
Userlevel 3
Badge +5

Hello @GlitchNZ, Good day:) I hope you are well!

Apologise for the delay in getting back to you. As mentioned earlier in the thread, you can add instead of adding email.freshdesk.com, you can include any one of the region-specific records that suit your account settings. 

SPF records

US - fdspfus.freshemail.io

EU - fdspfeuc.freshemail.io

AUS - fdspfaus.freshemail.io

INDIA - fdspfind.freshemail.io

Kindly have this checked and if you have any issues in setting up the SPF records feel free to DM us your queries I'd be happy to take this forward.

Cheers!!

Juliana Rozario
Keer
Rank
Userlevel 5
Badge +12

Hello @brian_c, our apologies for the delay in helping you in this thread. I am glad you were able to set up DKIM which is helping in solving this issue. However, for SPF records, instead of adding email.freshdesk.com, you can include sendgrid.net and any one of the region specific records that suits your account settings. 

SPF records

US - fdspfus.freshemail.io

EU - fdspfeuc.freshemail.io

AUS - fdspfaus.freshemail.io

INDIA - fdspfind.freshemail.io

 

I hope this helps in tackling the number of lookups made. We’ll certainly pass the feedback to our engineering team to see how we can optimise it better. Thanks for elaborating how DKIM covers SPF look up as well in your reply. 

 

Have a good day! 

Cheers, Keer, Freshworks Community Team
Freshman
Rank

Hello @brian_c, our apologies for the delay in helping you in this thread. I am glad you were able to set up DKIM which is helping in solving this issue. However, for SPF records, instead of adding email.freshdesk.com, you can include sendgrid.net and any one of the region specific records that suits your account settings. 

SPF records

US - fdspfus.freshemail.io

EU - fdspfeuc.freshemail.io

AUS - fdspfaus.freshemail.io

INDIA - fdspfind.freshemail.io

 

I hope this helps in tackling the number of lookups made. We’ll certainly pass the feedback to our engineering team to see how we can optimise it better. Thanks for elaborating how DKIM covers SPF look up as well in your reply. 

 

Have a good day! 

this works for our customer 

Gez
Rank

Hey there, could I suggest adding this region specific trick to your primary SPF article:

https://support.freshdesk.com/en/support/solutions/articles/43170-creating-an-spf-record-to-ensure-proper-email-delivery

It seems like a good work around - though I’m waiting to confirm our emails still pass SPF checks.

M
Rank
Badge

Also want to know when this will be fixed.  The autospf.com service is a solution, but for a small company, there is no way this would get approved if we asked management.  They would say “can you find a different solution instead of freshdesk”.

GlitchNZ
Rank

Work arounds are a great temporary solution to a problem, but when it comes to security, it is important the underlying issue is actually solved.

Freshworks needs to understand that their current approach to SPF is wrong, and they need to fix it. Nothing in this thread suggests they have any intention of doing so, which is why I have had to move to another provider.

It’s not just wrong in that workarounds are needed to make it work, its wrong because Freshworks  is being a bad internet citizen by forcing customers to disable security or use workarounds instead of providing a working solution that encourages good security practice.

I would much prefer to use Freshdesk, so when they do get around to having a product that meets minimum security requirements, I hope they do call me back and we can get back to working together again.

Until then, my best advise to other Freshworks customers who care about security is to use something else.

DavidA
Rank

Guess I found the source of our companies SPF issues. Currently running both fresh desk and fresh service which makes 16 lookups. Hopefully something can be done here.

K
Rank

Hi there,

 

In anticipation of Google and Yahoo’s upcoming change to require DMARC on bulk senders, I’ve been reviewing my SPF records for Fresh Service and have confirmed that email.freshservice.com now commands an incredible 11 lookups - 10 nested lookups within the main DNS entry.

 

This means that Fresh Service lookups alone exceed the maximum allowed by SPF, which is quite remarkable.

 

I’m relieved to see that I’m not the only person who has highlighted this, and if I’m understanding the advice correctly, it seems that we only need to include one of the nested lookups - fdspfeuc.freshemail.io (EU). [source]

 

Can I confirm this is a solution, and not a work-around?

 

I’m also not clear on why, if this is acceptable, we were ever asked to include the other lookups in the first place?

 

Lastly, I can see that fdspfeuc.freshemail.io is not one of the nested lookups within email.freshservice.com. Is this not a problem?

 

Regards,

Robert

A
Rank

Can’t believe for the last few weeks I’ve been struggling to find out why a lot of our incoming and outgoing emails were being flagged as spam, and it was all due to FreshService!!!

 

Seriously lads, it appears this issue has been flagged for years in the forums and you are not even suggesting that you are looking into this. 

 

I know there are SPF flattening services around, but there is no way we are going to pay for another service just to fix FreshService’s issues, when I could just move to another supplier for less cost.

 

I think I may have to look again at Zendesk for my companies ticketing support, since this issue doesn’t look like it will be fixed any time soon.

 

All joking aside, I did just about squeeze in under the 10 SPF limit by using the workaround of just including sendgrid.net and fdspfeuc.freshemail.io.

 

Guys at FreshService, I know you are reading my posts now as my last post is being reviewed before it can be posted, please ask your documentation team to at least include this workaround in your help documentation that refers to adding in the SPF settings for your platform, at least it will help those people that have at least 1 SPF setting already, which is probably everybody! 😁

Thanks,

Ant.

K
Rank

  

Hi there,

 

In anticipation of Google and Yahoo’s upcoming change to require DMARC on bulk senders, I’ve been reviewing my SPF records for Fresh Service and have confirmed that email.freshservice.com now commands an incredible 11 lookups - 10 nested lookups within the main DNS entry.

 

This means that Fresh Service lookups alone exceed the maximum allowed by SPF, which is quite remarkable.

 

I’m relieved to see that I’m not the only person who has highlighted this, and if I’m understanding the advice correctly, it seems that we only need to include one of the nested lookups - fdspfeuc.freshemail.io (EU). [source]

 

Can I confirm this is a solution, and not a work-around?

 

I’m also not clear on why, if this is acceptable, we were ever asked to include the other lookups in the first place?

 

Lastly, I can see that fdspfeuc.freshemail.io is not one of the nested lookups within email.freshservice.com. Is this not a problem?

 

Regards,

Robert

 

Just an additional note to say that I removed email.freshservice.com and added emailus.freshservice.com and this reduced the total number of lookups to 2, which is far more reasonable.

 

I believe fdspfeuc.freshemail.io is for Freshdesk, which is not the service we use - worth bearing this distinction in mind when troubleshooting your own environment.

 

Also, as we’re based in the UK we incorrectly assumed we would be part of the Fresh Service EU server farm; consulting with FS support, we were informed we’re hosted on US servers. This is also something you will have to check when trying to whittle down your lookups.

 

Another thing we were advised to do was include 3 DKIM records, and a 4th, which was described to me as relating to SPF. Now, anyone who knows how SPF works will tell you that’s not possible, as there can be only one SPF record for a domain, and unfortunately nobody from Fresh Service could sufficiently explain the syntax of the record to me. Despite having published it, I’m still unclear what it’s for or why it’s needed.

 

All in all, quite a needlessly challenging issue.

 

Robert

Kajal Vats
Rank
Userlevel 1
Badge

Hi @Ant-TTG 

Greetings for the day!

Apologies for the inconvenience caused here.

Glad to hear that the issue has been resolved now. Regarding the SPF query, as you mentioned you can add the region specific lookup which is "fdspfeuc.freshemail.io" and "sendgrid.net" to avoid this issue.

That said, we will pass on your feedback to our backend team to update the documentation accordingly.
Feel free to drop a note for any further help.

Cheers,
Kajal, Freshworks Community

1Adam12
Rank

@Kajal Vats I’m not sure this issue is resolved yet for many of us - the “workaround” still consumes a minimum 4 lookups, which if you have other platforms that send on behalf of a domain quickly ends up past the 10 lookups limit.

SWY
Rank

Yes to all of this.

SPF records are a limited resource.  My records for M365 delivery are primary and non-negotiable.

Freshworks is doing the SPF version of manspreading on the subway.  Not cool.

Jason-UK
Rank

Hi

I might be a bit late adding my input, but here goes:-

You can flatten it further by creating another couple of txt records and having them as includes in your first SPF record here’s what we used (without the rest of our includes):

yourdomain.com     

"v=spf1 include:_spffreshdesk.yourdomain.com include:_spffreshdesk2.yourdomain.com ~all"  

_spffreshdesk.yourdomain.com
"v=spf1 ip4:167.89.0.0/17 ip4:208.117.48.0/20 ip4:50.31.32.0/19 ip4:198.37.144.0/20 ip4:198.21.0.0/21 ip4:192.254.112.0/20 ip4:168.245.0.0/17 ip4:149.72.0.0/16 ip4:159.183.0.0/16 ip4:223.165.113.0/24 ip4:223.165.115.0/24 ip4:223.165.118.0/23 ~all"

_spffreshdesk2.yourdomain.com
"v=spf1 ip4:223.165.120.0/23 ip4:3.222.0.24/29 ip4:198.21.4.52 ip4:167.89.31.27 ip4:167.89.127.244 ip4:3.120.181.200/29 ip4:3.7.25.40/29 ip4:13.127.153.86 ip4:52.66.154.99 ip4:13.127.210.61 ip4:3.25.47.0/29 ~all"

But now we’re moving over to Mimecast’s managed SPF which works dynamically, so no more SPF worries I guess

Best regards

 

 

S
Rank

email.freshservice.com now takes up 10/10 slots.

tyler.courtney.ocsd
Rank

We’re battling this as well. Just three DNS entries over our limit after including “email.freshdesk.com”. Such an annoyance.

MobilityRoute
Rank

This cuts the number of lookups to 4, if I’m not mistaken, because within each of those addresses (sendgrid.net and fdspfus.freshemail.io in my case) is yet another include (ab.sendgrid.net and fdspfus2.freshemail.io respectively).  Still too many - now freshdesk takes up almost half of the SPF instead of almost all… so an improvement but still not really acceptable the way things work today.

 

 

Couldn’t agree more. Freshworks really needs to address this. We’re likely looking to switch from Freshsales for this among other reasons. We really want to use a bunch of the Freshworks suite of products, but it’s these type of backend oversights and poor implementation that break things, especially when security and reliable systems is critical. Email reputation is critical, so SPF, DKIM, and DMARC are absolutely necessary.

GlitchNZ
Rank

+1

This is a major problem for us - we need space in our SPF for other tools and FreshDesk having so many records is making it impossible for me to enable dmarc, which creates security risks for our organization.

Given they have been aware of this for four months and have done nothing, we have no option but to move to another service provider.

A note for Freshdesk - every other service provider using email I have come across has at most 2 DNS lookups - and some of them have way more complicated requirements than you. You’re argument that you need to have 8 is simply invalid and will undoubtedly cost you customers. Perhaps you should look at a delegation tool as a short term solution?

A
Rank

By the way, I did manage to just squeeze in under the SPF 10 limit by using the sendgrid.net and fdspfeuc.freshemail.io.

But I’m still pissed for wasting so many hours investigating our Spam issues when this could have been easily avoided. If you are not going to change your own SPF lookups, then at least update your help documentation to explain this workaround for people who already have at least 1 SPF setting, which is probably everybody!! 😁

alyssia.correa
Rank
Userlevel 7
Badge +7

Hello @Ant-TTG - thank you for flagging this and i’m sorry for the inconvenience. I have passed this on to my team, please let me get back to you

Ally, Freshworks Community Manager
BradS
Rank
Badge

We are a freshdesk, freshsales, freshmarketer customer since 2016 and we know how painful their spf (and other Enterprise software) records are to manage. So we created https://www.autospf.com - it will help solve your problems with vendors who have long SPF records. 

E
Rank

I am also affected by this issue and I must say it's such a big mess. Especially if you are not expert in this field you have no chance to solve this issue. I also dont want to spend 370$ for a SPF flattener.  It's incredible that Frehsdesk has no solution to this. We have a lot of issue with Emails going to spam from Freshdesk. They are doing an incredible bad job here in documentation as well.

Reply


Terms of UseCookie settings