Any concerns with Google's new warning message from SPF and DKIM Signatures?

Hi Experts,

We have noticed when we use reporting applications (event viewer capture, backup reports, etc) to send e-mail reports to and from Gmail accounts (or those controlled by Google Apps) we now get the warning message that “This message may not have been sent by…” even though we are sending on both ends.  We understand why it happens, the reporting applications don't have the ability to use SSL for e-mail so we are stuck using the SMTP server our ISP provides which means Google never gets the DKIM signature they want on the e-mail that shows its coming from them.  We don't have any e-mail accounts with our ISP and and to avoid confusion was just listing our normal Google controlled addresses in the to and from fields.  Is there any concern getting this message from Google?  The messages come through so far but want to make sure it won't eventually become blacklisted or anything.  It seems the message only shows up in the Gmail interface, it doesn't come up in any e-mail clients accessing Google.  

See this link for what we mean: http://mail.google.com/support/bin/answer.py?answer=185812

Thanks
JsmplyAsked:
Who is Participating?

Improve company productivity with a Business Account.Sign Up

x
 
PapertripConnect With a Mentor Commented:
We don't have our own domain in use.
Ahhh I see what you mean now.

So the bottom line here is that you can't have envelope or body From's saying @gmail.com or @google.com etc.

You can either:

A.  Customize the app at each site to make the envelope From (and preferably body From) the same as whatever the ISP is sending it as.  Of course this presumes you can actually relay through each ISP.
B.  Purchase a domain, setup SPF at very least, and make sure envelope From is yourdomain.com, and the body from should match that as well, but at the very least should not be @gmail.com, then the app config across sites can remain consistent.

Personally I would go with B -- the more you rely on each ISP, the more headaches you are going to have.
0
 
PapertripCommented:
Hi,

So it seems you have several variables here -- reporting app, gmail <-> gmail mails, gapp <-> gmail mails, relaying through your ISP, etc.

Let's take a different approach, paste the headers from one of those suspect emails so we can see the exact flow.
0
 
JsmplyAuthor Commented:
I'll try to clarify it to make it easier:

Reporting app (creates e-mail) > ISP SMTP Server sends email out for the reporting app (via Gmail address in to and from fields) > Received at Gmail account via Google (no ISP involvement)

Only issue is because it was sent through the ISP'S SMTP and not Gmail itself, Gmail gives the warning it might not actually be from the intended sender.

Does that make sense?  
0
Improve Your Query Performance Tuning

In this FREE six-day email course, you'll learn from Janis Griffin, Database Performance Evangelist. She'll teach 12 steps that you can use to optimize your queries as much as possible and see measurable results in your work. Get started today!

 
PapertripCommented:
Yep.
(via Gmail address in to and from fields)

That would be your problem.  Any specific reason you need the from address to be @gmail.com ?  You are basically doing exactly what DKIM attempts to prevent ;)
0
 
JsmplyAuthor Commented:
Just that we usually have all reports sent from the same To address (Gmail A) and received at the same From address (Gmail B) and because each site does not have the same ISP, it would take forever to find local ISP accounts for each one.  

Do you have a different recommendation?
0
 
PapertripCommented:
I'm not sure what you mean by other sites and ISP accounts.  If I understood the rest of your last reply correctly, then this should be able to be solved by doing the following:

envelope MAIL FROM = reports@yourdomain.com
body From = reports@yourdomain.com
Reply To = reports@gmail.com

In that scenario, your SPF and DKIM (if applicable) would be based on the envelope MAIL FROM (always is) but in this case it would be yourdomain.com instead of gmail.com.  Without the headers I'm taking a guess at the MAIL FROM being yourdomain.com.  Gmail is still sensitive to only the body From being gmail.com.

0
 
JsmplyAuthor Commented:
What I mean is, we use this software at several locations, the ISP varies from site to site.  We don't have our own domain in use.  Does that make sense?
0
 
PapertripCommented:
I should mention that, if you were to send those mails to some non-google receiver, and if that receiver is validating mails from gmail.com (many are), then you will fail both SPF and DKIM verification.
0
 
JsmplyAuthor Commented:
Thanks.  We may have to relay through the ISP for now until we can get the domain setup.  At least as a temporary solution.  That's already what is setup now, but the From address needs to be changed.  

New question then - Does the from address actually have to exist at the ISP?  For example, we already have all the apps configured to send to the appropriate ISPs, that's relatively easy as it's one of three possibilities.  However, the sites don't have ISP e-mails setup or in use.  Does that matter?  For instance, if the ISP is comcast and we use smtp.comcast.com to send the e-mails out and the from Envelope is sitename@comcast.com does that matter if that address actually is setup?  It would become a serious pain to try to manage that.  Thx
0
 
PapertripCommented:
Nope it sure doesn't, the important part here is the domain -- comcast.com -- That is what SPF and DKIM work from.
0
 
JsmplyAuthor Commented:
Thanks.  Assumed as much going in but your answer was still correct.  The last answer was helpful, it's easy to make up a FROM address that matches the domain of the ISP providing the SMTP server, it would be difficult thought to guarantee the address actually exists with that ISP at each site as we rely on the actual account holders, etc.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.