Emails bounce back from Gmail.

[Kitten Kong]

Hi everyone, I'm at a loss here. One of my friends asked me for help with their business email account.

Basically if they send a email to a Gmail account, it bounces back.

Yet if its sent to a Google mail account it arrives.

Any thoughts please?

 

[britechguy]

Can you clarify a bit more?

To me Gmail is Google Mail. I've never used an address for Gmail other than of the form xxx@gmail.com.

Also, what is the content of the bounce message she's getting?

 

[Kitten Kong]

Thanks for the reply.

She is currently driving back up to Cumbria, some 200 + miles away.

I'll ask the questions. And see what the reply is and let you know.

 

[Kitten Kong]

Can you clarify a bit more?

To me Gmail is Google Mail. I've never used an address for Gmail other than of the form xxx@gmail.com.

Also, what is the content of the bounce message she's getting?

I've previously had clients use googlemail, ie abc@googlemail.com

If you try sending it to abc@gmail.com it bounced

 

[britechguy]

I've sent a message to someone I know who works at Google to see if this rings a bell.

It makes no logical sense, since googlemail.com and gmail.com "go to the same place" and would almost certainly go through the same filtering mechanisms on the Google side. In the message I just sent myself using googlemail.com if I expand to show the short message header there's even a link Google includes saying, "Yes, this is you," and if you click through on it you end up here: https://support.google.com/mail/ans...ing-messages-sent-to-an-googlemailcom-address

If he can shed any light on what might be happening (or even if he can't) I'll report back what I hear.

 

[Sky-Knight]

I've got a client that's having issues in this vein, but likely unrelated? All mail from their M365 tenant is bouncing when going to any Gmail.com or GSuite hosted domains.

But from what we're seeing, it's all Proof Point's fault, they did something to their mail cluster and now a TON of vendors are blocking them. COX is straight up blocking them right now, and as soon as we disabled the connector that forces egress mail from M365 Exchange into Proof Point BOOOM good delivery.

Anyway, I digress, beware Proof Point is having issues right now, and if you have a client using it, they're going to need mitigation work until Proof Point can solve their reputation problems with their new IP block.

 

[callthatgirl]

I had this call on Thursday, the SPF and DKIM were not updated, client got them updated and will report to me this week to see if that helped. My client was using a very old hosting company, it's time for her to move to Exchange most likely.

 

[Markverhyden]

Can you clarify a bit more?

To me Gmail is Google Mail. I've never used an address for Gmail other than of the form xxx@gmail.com.

Also, what is the content of the bounce message she's getting?

Ditto. Never heard of googlemail.com. @Kitten Kong what is being used to send these emails. These days bouncing, as @callthatgirl mentioned, is often a SPF,DKIM,DMARC record issue.

 

[britechguy]

Never heard of googlemail.com

Apparently was far more commonly used "in the early days" and in non-US markets. But Google's own support pages state that a gmail.com and googlemail.com address resolve to one and the same thing.

 

[britechguy]

Proof Point

Well, that's interesting. I need to extricate my client who's going to M365 from Proof Point, which was clearly sold to them by Go Daddy and it's my understanding that Go Daddy has to do that part, too.

 

[seashore]

As @britechguy says, we need to see the bounce message. In the meantime, don't know whether it's the same issue, but (similar to @callthatgirl ) over the past 6 months when clients have received bounces from Gmail addresses I've then set SPF and all's good.

From Google:

Email authentication requirements for sending to Gmail accounts​

Starting November 2022, new senders who send email to personal Gmail accounts must set up either SPF or DKIM. Google performs random checks on new sender messages to personal Gmail accounts to verify they’re authenticated. Messages without at least one of these authentication methods will be rejected with a 5.7.26 error, or marked as spam. This requirement doesn’t apply to you if you’re an existing sender. However, we recommend you always set up SPF and DKIM to protect your organization’s email and to support future authentication requirements. If you need help setting up email authentication for your organization, contact your email service provider.

 

[callthatgirl]

I know about SPF records, but not that knowledgeable on DKIM. I have a guy I use if anyone needs his info, he's great and affordable for simple requests.

 

[Sky-Knight]

SPF / DKIM / DMARC are all required these days if you want to actually deliver mail.

ARC is there too... but I haven't mucked with that much yet.

 

[britechguy]

SPF / DKIM / DMARC are all required these days if you want to actually deliver mail.

True. But that still doesn't explain why a message addressed to xyz@googlemail.com goes through just fine but not when sent to xyz@gmail.com, when the originator of said message is the same.

That dichotomy remains mysterious, to say the least.

 

[YeOldeStonecat]

I'd run the domains at MXTOOLBOX.COM
Agree focus on the basic DNS records to ensure they're in place. It's shocking how many "IT people" set up mail for someone...without doing the proper DNS records.

SPF is the old old way to show the servers listed...are able to send email on behalf of that domain. Yet it's still SHOCKING to find how many domains don't even have SPF configured. It's like....this is old basic stuff...from over 20 years ago!

DKIM is basically...a modern fancier version of SPF. Should be a standard now...yet...we usually don't find it configured. 365 has a very easy hand holding wizard to help the "IT people" configure DKIM. Google also has one...very easy past hand holding wizard. Anyone who manages email for a business should have this stuff down pact.

Regardless...run the domains through ALL the tests (click that drop down menu to reveal more goodies)....at MXTOOLBOX.COM

 

[britechguy]

stuff down pact

Pat. Down pat. And they should make a pact to get it down pat!

 

[Sky-Knight]

SPF and DKIM aren't the same thing... not even related to the same thing... You can't post about ignorance while displaying ignorance, it's painful.

1.) Sender Policy Framework (SPF), is a DNS record that provides an authoritative list of servers authorized to send email for a given domain.
2.) DomainKeys Identified Mail (DKIM), is a cryptographic approach to signing email messages to be checked against published public keys to verify the mail was sent from a host that has the appropriate private key, and that the mail hasn't been tampered with.
3.) Domain Message Authentication Reporting (DMARC), is a DNS record that tells the world where to report message issues as well as how much to trust and utilize DKIM and SPF.

1.) Is for telling the world what should be sending mail for you.
2.) Is for giving the world the ability to verify mail actually came from your equipment and it's not been tampered with.
3.) Is for telling the world how your anti-spam and anti-spoofing situation is configured so it can make proper decisions.

You need all three, each component is unique and true to what it does. None of them are terribly valuable alone, all of them together form the standard required to fight spam, and mail impersonation.

The Authenticated Received Chain (ARC), for DMARC is yet another extension further, that provides a full chain of custody of the mail to the recipient. I haven't done much with this yet, because it's got huge implications. If you use any 3rd party spam filtration at all ARC will fail. Because ARC basically says only the servers involved with owning the actual mail on either end get to see it. If anything else mucks with it at all, ARC notices and slams the door. This requires substantial configuration, and I find I spend too much time on DMARK and SPF to even think about doing ARC later. It's all very easy when the client uses just GMail or M365, but once they toss in SendGrid, ConstantContact, or SMTP2GO things get MUCH more difficult. The documentation gets spotty, the integrations get more complex, and the client's purse strings tend to get rather thin on figuring it all out. So I've just been content to ignore ARC for the older more well documented options.

The irony is... ARC is supposed to help with all this, but so far... it hasn't. M365 can slap an ARC seal on a mail that came from an improper place and because it's so sealed the world is supposed to know it's now legitimate. But... adoption rates... oy.

 

[YeOldeStonecat]

"not even related to the same thing?" Who ****** in your cheerios? Are you seriously going to stand on a podium and try to say that?

I'll go RIGHT to a trusted source....I feel like pasting links to dozens of big name email security services...but I do need to get some work down so I'll go to the first one.

Quoted and copied and pasted and linked from Mimecast....

What Is DKIM?

Learn how using DKIM (DomainKeys Identified Mail) can prevent email spoofing. Understand how to validate DKIM records with Mimecast.

www.mimecast.com

"DKIM, or DomainKeys Identified Mail, is an email authentication method that uses a digital signature to let the receiver of an email know that the message was sent and authorized by the owner of a domain..........the validation is done on a server level

Simply put, A DKIM record is a line of text within the DNS record that contains the public key which receiving mail servers can use to authenticate the DKIM signature"

The next line is also copied and pasted from Mimecast..their worlds, not mine. I'll bold print the important parts.

"SPF is just like DKIM, an email authentication technique that can be used by utilizing the DNS (Domain Name Service). DKIM provides the ability to specify which email servers are permitted to send email on behalf of an organizations domain. Authenticating legitimate senders with SPF gives the receiver (receiving systems) insights on how trustworthy the origin of an email is."

..end of quotes.

SPF is basically an earlier technique that took the approach of a "white list"...it white lists servers that can send email on behalf of that domain.

Now....yes....DKIM also ADDs the ability to verify that the email has not been molested in transit. Since it gets attached to the email and goes along for the ride.

THE END GOAL IS TO WORK TOGETHER TO LIMIT THE SERVERS TO THE SERVERS YOU SPECIFY!!!! SPF whitelists the servers you specify are legit for the domain. And with DKIM, instead of whitelisting servers, it leverages the keys of the servers you add to the domains DNS records (which...itself there states which servers are legit to send on behalf of the domain)...also DKIM adds the protection during the journey to ensure they arrive at the destination unmolested (but that's not the cause of this threads topic thus unrelated)...yes it's more advanced than SPF but the end goal is the same when they work together.

They work together, they compliment each other, two different approaches, same goal.

DMARC I don't care about doing into that but it ties together info from the above two. I p=quarantine and nothing else.

 

[trevm999]

Think of it like a website certificate. If the private key is compromised, you can't just take the private key and add it to your own web server and suddenly web clients recognize you as that website. That's only part of the attack, the next part would have to be to convince web clients to use one of the name specified in the certificate to access the your new web server, or you actually have to have control of the infrastructure.

DKIM is the private key. If that's compromised, DKIM will pass. SPF is the names specified in the certificate. Just because DKIM passes doesn't mean that the email is physically coming from your infrastructure.


One of the great thing about DMARC, is that it convinces email providers to check the FROM header. Otherwise a scammer can put FROM: me@mydomain.com and have the actual server it's sent from be some random server and domain that has a valid spf and dkim, and spf and dkim will pass, but it won't be checked if there's alignment with the from header.

 

[YeOldeStonecat]

Good spam filters can fail SPF without DMARC...for example, even Microsoft's Defender for 365 has the option to reject or quarantine or junk...email that fails an SPF check..without a DMARC.
However...yes it's proper to have a DMARC record in place.
IMO it's proper to have all 3 in place...SPF, DKIM, and DMARC. They all work together, compliment each other to get to the goal one should want. No business grade email should be set up without all 3 of those records in place. Should be done from day 1. Or if the email was set up a long long time ago without them...log into that DNS control panel YESTERDAY and get them set up pronto! No excuse, they're easy, literally can get done in mere minutes, get 'er done!