What is the correct include: statement for the Quickbooks / Intuit.com SPF record to allow it to work without reporting too many lookups?

Thanks for posting to the Community, @rob-wilde.

We have lots of includes to allow it to work without reporting too many lookups when sending invoices, sales receipts, estimates, statements, etc.

Aside from include:intuit.com, you can try using different server hostnames that on the list through this article: 3 solutions for when customers aren't receiving your emails. There you can see the possible solutions if your customers were unable to receive statements.

Additionally, you can reach our Intuit Developer site if you have more questions about SPF.

Feel free to place a comment below if you have other concerns about QuickBooks. I'll be around to help. Stay safe and well!

Thanks for your response @Jovychris_A

I've seen the list of possible includes but I can't add all of them as I am limited to just 10 including my own. Is there a way to determine which I need to include to allow emails from Quickbooks to my customers in a reliable way.  Using include:intuit.com has some success but not every email gets delivered.

Many thanks

Rob

Thanks for getting back to us, @rob-wilde.

To ensure that I'm on the same page, may I if you're getting any error messages when some of the emails are not sent? Any additional information will help me provide the best resolution.

Though we can't suggest the specific include:intuit.com, you can use any of the includes outlined in the article shared by my colleague above. Just in case, here's the link: 3 solutions for when customers aren't receiving your emails.

Please click the Reply button below to add more details, and I'll get back to you as quickly as possible. I'm always here to help. Have a good one!

Thanks for your response.

We aren't seeing any NDR's as the emails are being sent by Quickbooks and not directly by us. We have no way to check in any email logs to determine the reason. Quickbooks log only shows that email was sent. When we check the SPF record for our domain in MXTools we can see that there are too many lookups (11) so we are guessing that whichever sending domain is being used by Quickbooks isn't being cached in the SPF record and therefore our emails are rejected by some of our customers mail systems that use SPF, DKIM and/or DMARC

Thanks for sharing more details with us, @rob-wilde.

If they haven't received the email notifications yet by using the server hostname through the article. It might be caused by the following interferences below:

• The email was moved to their Junk or Spam folder.
• They use a custom email domain (example: [email address removed]) or an email client (Outlook, Exchange, AOL, Thunderbird, etc.).
• Their internet service or domain provider blocks the QuickBooks email address.

They must follow these steps so that they can receive the emails you've sent.

1. Open your email and check your Spam or Junk folder.
2. If it’s there, move the email to your Inbox.

If the issue persists, I'd suggest contacting your IT person or domain provider for assistance to temporarily turn off Sender ID filtering or get help on what’s causing they are unable to receive the email.

I'll respond to you as fast as I can if you need further assistance. I'd be happy to help. Have a great weekend!

It looks like the recipient server is marking the emails from Intuit as SPAM as they are coming from an IP address that is listed on Blacklists. ie 167.89.58.229

Here is an extract from the header file;

"HeaderValue": [

        "MAILSPIKE-H2: \"trusted sender\"",

        "SORBS: \"Currently Sending Spam See: http://www.sorbs.net/lookup.shtml?167.89.58.229\"",

        "BADWHOIS: This E-mail came from e.notification.intuit.com, and is listed in BADWHOIS.",

        "ENVMISMATCH: Env sender (bounces+2327135-5441-User.name=userorg.[email address removed]) From: ([email address removed]) mismatch.",

        "MESSNIFFER: Message failed MESSNIFFER: 53.",

        "MESSNIFFER-SCAMS: Message failed MESSNIFFER-SCAMS: 53.",

        "WEIGHT5: Weight of 54 reaches or exceeds the limit of 5.",

        "WEIGHT15: Weight of 54 reaches or exceeds the limit of 15.",

        "WEIGHT20: Weight of 54 reaches or exceeds the limit of 20."

I note that the IP address (167.89.58.229) is not on the list of Intuit addresses at https://quickbooks.intuit.com/learn-support/en-us/manage-intuit-account/unable-to-receive-intuit-ema...

I have been experiencing the same issue with QuickBooks Online throughout this year.  It looks like Intuit does not have an SPF record for their sub-domain notification.intuit.com which they use to email out my QuickBooks Online invoices.  All my customers that have spam filtering with SPF record checking cannot receive my invoices due to this problem.

Can anyone at Intuit solve this problem???  I call tech support and they do not understand.

Hi IT_Guy69,

Have you tried the steps shared by my colleagues above? You can let your customers check the invoices on their Spam or Junk folder.

If it's not there, I recommend reaching out to our Techincal Support team. We have designated agents that can check your account and investigate what's causing the issue.

Here's how you can reach out to them:

1. From the ? Help button, click Contact Us.
2. Enter, This E-mail came from e.notification.intuit.com and is listed in BADWHOIS.
3. Click Let's talk.
4. From there select either Get a callback,  Schedule a call, or Start a chat.

Feel free to tag my name if you need help. Stay safe!

Hi Adrian_A,

Thanks for the reply!  Unfortunately the email is being caught at the recipient's server level before it can make it to their mailbox.  Their admin does have the ability to whitelist the sender's address but I am trying to avoid contacting all my customers who check for a valid SPF record to do so.

Your replay said that the email should be sent from e.notification.intuit.com which is not the address I show  sending my invoices and may be the issue.  The e.notification.intuit.com does have an SPF record whereas just notification.intuit.com that my QuickBooks Online account uses does not.  I have been using QuickBooks Online for almost 15 years so maybe my account is setup differently than most.

Would you please look into this difference of e.notification.intuit.com vs notification.intuit.com to see if this problem can be solved on your end?  Maybe an SPF record could be added to notification.intuit.com or my account can be set to send email using e.notification.intuit.com instead to solve this problem.

Thanks!

Allow me to share additional information about this topic, @IT_Guy69.

Intuit or QuickBooks has the list of acceptable server hostnames that you can check under the Server Hostname section from this article. If you receive emails other than that, you can send a message to spoof@intuit.com so Intuit can review this further if the email provider is legit or not.

Or you can reach out support as suggested by Adrian_A above.

Let me know if you have any other questions. I'm always here to help. Take care always!

So why doesn't Intuit just create it's own _spf.intuit.com TXT record in its DNS server that all your customers can just add an "include" in their own domain SPF record? That way you would own and control your own list of (approx) 30 servers that send out mail for your clients. You could swap out and in new hostnames based on your capacity and system changes and just update your own record once and mitigate customer frustration.

Other benefits include not wasting your staff resources to respond to these sorts of emails and not wasting the time and energy of your customers in trying to explain the problems. It's just what good companies do for their clients.

I understand that SPF and DKIM records are new addition to the email security methodology for all of us but the problem is just going to get worse unless it's managed proactively.

And @rob-wilde, if you also include a DMARC record in your DNS zone with your email in the rua parameter, I believe you should get an aggregated list (depending on my mail service provider) of which messages have failed because of a failed SPF lookup. You can then verify and if necessary add these to your SPF record. Mine come in a .zip file so I had to modify my filter rules to permit DMARC reports with a ZIP file.

Yeah, I'm kind of in a similar situation.  Because QBO cannot send fully authenticated email on my behalf, the DMARC situation seems to send most correspondence to spam folders.  It would be nice if QBO would make a tool so I could have fully authenticated messages send on our behalf.  I've already accomplished this with my email provider, and my security provider, but QBO remains a problem.

THANKYOU.  Registered just to up vote your comment. Found it super odd that articles on SPF were linking to those long list as if they were a workable solution.

It's verging on irresponsible to expect the QuickBooks users to use the domain list for SPF (10 lookup limit kills it) or the IP list which will looses reference and is unmaintainable when QuickBooks add or remove a IP (and they have as old stackoverflow questions show older lists).

They have to expect and understand customers will have other services as well as their own email host in the SPF also. How they have not set up a usable include:_spf.intuit.com reference is mind boggling.

I see many many questions about how to properly configured your SPF record to allow successful sending of invoice emails with Quickbooks Online but no one from Intuit has been able to provide a workable answer.

For the record, a list of dozens of IP addresses or host names that could change at any time without notice is not a workable answer.

A properly formatted SPF record is a workable answer.  Please provide this.

quickbooks, you MUST deal with this ASAP.  At this point this may drive myself and my customers to other products just because quickbooks can't properly do SPF/DMARC/DKIM to properly send authenticated authorized emails.

Feel free to have IT/email/security people at quickbooks reach out to me directly and we can discuss why this is so critical.

@tserreyn I can't agree more. It is crazy that after years this issue has never been resolved. If clients don't get invoices, what is the point of having QuickBooks? We need a simple professional SPF and DKIM solution urgently.

Please QuickBooks - get this sorted as without it you don't have a product suitable for professional (or any) use.

Thanks in advance!

ADMIN - please delete this duplicate post.

It is now Feb 2023 so has QBO fixed this SPF issue yet?

Below is the results from www.spf-record.com/analyzer where is keeps failing.

At mycustomdomain.com include:intuit.com include:_spf1.intuit.com include: _spf2.intuit.com the limit is exceeded (RFC7208)

I found the _spf1.intuit.com include was duplicating my standard email settings (outlook), causing me to exceed the limit of 10. --- I use GoDaddy as my email provider, so you'd need to change the first one to yours, and just in case you use salesforce, or another 3rd party, do this:  

WARNING.   if/when the list of IP addresses included in _spf1.intuit.com, then you may start getting your email sent to junk again.  

Example:

v=spf1 include: secureserver.net include:_spf.salesforce.com include:_spf2.intuit.com ip4:12.216.231.16 ip4:12.187.184.48 ip4:12.149.174.0/27 ip4:12.187.184.32/28 ip4:12.216.231.32/28 ip4:199.16.137.0/24 ip4:199.16.139.0/25 ip4:206.225.202.0/27 ip4:206.225.218.0/27-all

(iinclude:_spf1.intuit.cominclude:_spf1.intuit.com - expands to this: 

Try removing intuit.com (not sure it's needed) & spf2 (since it's included in the spf1).  Just keep your email domain and _spf1.intuit.com

include:mycustomdomain.com include:_spf1.intuit.com

It is now March 2023 and still no solution.  This is so ridiculous.  A $100 billion dollar company can't get it together to help companies fight spoofing.

I appreciate you for chiming in on this thread, safetyfirst.

Intuit takes account and data security very seriously. Please know that this isn't the experience we want you to encounter. Let me guide you in spotting scams and ensure you'll be able to file a report in QuickBooks Online (QBO).

The sender ID "do_ not_reply@intuit.com" isn't listed in the Sender Policy Framework (SPF), an email authentication system that prevents email spoofing. If Sender ID filtering is enabled, emails from do_not_reply@intuit.com are automatically rejected.

That said, you'll have to contact your IT person or domain provider to temporarily disable Sender ID filtering or get help on what’s causing you not to receive the email. 

Furthermore, it's best to get in touch with our customer support. This way, you can file a report about your experience, and we can take action, so this won't happen the next time.

I'll also share this article so you can recognize official Intuit correspondence and websites: Identify suspicious activity, phishing scams, and potential fraud.

Please don't hesitate to reply if you have concerns about spotting email spoofing in QBO. The Community is here to help anytime.

At this point the responses from the QuickBooks team are almost comical.  It's like you guys are trying really hard to not answer the question.  Let me break it down one more time and maybe you can escalate:

• QuickBooks sends email where the FROM address uses it's customer's configured domain.  For example, QuickBooks might send invoices to my customers using [email address removed]  because that's what I put in my QuickBooks settings.
• How does a mail server determine that this isn't a spoofed email?  Anyone can send an email FROM any domain.  SPF/DKIM/DMARC is the current standards-based answer to this problem.
• SPF basically says, "tell me what IP addresses can send emails on your behalf".  So when a server receives an email invoice from QuickBooks, it can check the DNS of mycompany.com and find out that in fact the owner of mycompany.com is cool with QuickBooks sending emails on their behalf.
• We as your customers need to know what IP addresses to allow for QuickBooks.  Because IP addresses are cumbersome to maintain, most companies just provide a DNS that resolves all of the IP addresses that might send emails.
• For example, if you want Google to send on your behalf, you just need to include _spf.google.com.  It took me a matter of minutes to find the right DNS to use for ZenDesk, HubSpot, and Amazon SES which are popular platforms that send emails on customers' behalf.

safetyfirst really hit the nail on the head. It's a simple problem, honestly. I think the core issue here is that the forum reps are customer service people, not IT people. If you work for Intuit, and you are reading this: this is a problem that could be resolved TODAY, but *only* someone with access to your website's back-end can make the change necessary to do so. There is *no* existing solution that you can propose to us to fix it, and any response other than "I have personally made sure a person with authority and access to change the website's settings looked at this tread" will not resolve it.

I've been tracking this thread since 2020 when it started, hoping an answer will appear. The current solution I'm pushing our accountant to try is seeing if we can make the emails that Quickbooks sends on our behalf just be honest that they were sent from Intuit, instead of trying to masquerade as us.