Email delivery issues using Outlook

[Greg M]

Hello,

A clientis asking me to help with an email issue.

The email account is hosted on a cPanel server as part of a regular hosting account, the client uses outlook (2016 I think). Now their SPF, DKIM etc is all set up and checks out fine. However the client's local IP address is dynamic so whenever they send outgoing emails using the outlook client it passes their local IP in the message headers. This is a problem because every time their IP changes the SPF fails on messages they send. Further if the client decides to use her laptop from another location it will use that IP address which is also an issue.

An example of the message headers in gmail is below. So for example if the client is responding via email to a phone call or to a contact form This is causing the clients outgoing emails to wind up in spam folders because it is not passing verification.

Delivered-To: [email protected]#####.co.uk
Received: by 2002:a05:6839:128c:0:0:0:0 with SMTP id f12csp519126nkh;
Wed, 15 Sep 2021 12:12:05 -0700 (PDT)
X-Google-Smtp-Source: ABdhPJwn1QbOZPabHYYGyN6g09ueeqW8tQxZvpV4sJI5NmNgyEdHKAVzW3DGMmUp/d9KWPLlR8A17rsDKCE=
X-Received: by 2002:aca:5f09:: with SMTP id t9mr896099oib.157.1631733125092;
Wed, 15 Sep 2021 12:12:05 -0700 (PDT)
Authentication-Results: mx.google.com;
spf=softfail (google.com: domain of transitioning [email protected] does not designate {Client IP Address} as permitted sender) smtp.mailfrom=[email protected]
Received-SPF: softfail (google.com: domain of transitioning [email protected] does not designate {Client IP Address} as permitted sender) client-ip={Client IP Address};

SRS is enabled on the server too.

What needs to be done to resolve the issue? Is there a way to make the emails sent via outlook use the servers IP address rather than the clients? The client is losing business because for example if someone calls for info and they tell them they'll email it out quite often it goes to spam or doesn't arrive at all. Obviously an "easy" fix is to use webmail but the client really prefers using outlook. So I'm hoping someone can shed some light on this please?

Thanks

 

[cPRex]

Hey there! Out of curiosity, can you reproduce the issue with another mail client? As you've said, it wouldn't make sense for the local IP address of the client to show up in those headers as that would never properly verify SPF, so it seems that there may be something else going on with that particular system.

 

[Greg M]

Hey there! Out of curiosity, can you reproduce the issue with another mail client? As you've said, it wouldn't make sense for the local IP address of the client to show up in those headers as that would never properly verify SPF, so it seems that there may be something else going on with that particular system.

Thanks for the reply.

I haven't managed to yet client isn't that tech savvy, However if they are willing to give me their password I'll try it from my laptop using another mail client.

Problem is I have tried googling this for Exim, Cpanel and outlook. I don't see anything relative coming up. If you include outlook in the search term you just get results for exchange servers.

I can't say I've ever come across this one before.

 

[quietFinn]

In your client's Outlook's settings, is the "Outgoing Server" the cPanel mail server?

 

[cPRex]

Oh, good idea to check that, @quietFinn

 

[Greg M]

In your client's Outlook's settings, is the "Outgoing Server" the cPanel mail server?

I'm requesting remote access to check this. The client should have followed the standard set up instructions provided via cpanel. You reckon their outgoing server is defined as something else maybe?

Will hopefully get access to remote desktop or something

 

[cPRex]

It definitely has to be something odd with the configuration or else every user in the world running Outlook would be experiencing similar issues when sending mail.

 

[Greg M]

It definitely has to be something odd with the configuration or else every user in the world running Outlook would be experiencing similar issues when sending mail.

Yeah I admit it definitely seems something on my clients end, I've never come across this issue before and google is really not much use, so definitely a rare issue. I'm waiting for a response on the remote access. Just wanted to check it wasn't a bug server side first, as I'd look pretty stupid remote connecting for no reason

 

[mtindor]

Hello,

A clientis asking me to help with an email issue.

The email account is hosted on a cPanel server as part of a regular hosting account, the client uses outlook (2016 I think). Now their SPF, DKIM etc is all set up and checks out fine. However the client's local IP address is dynamic so whenever they send outgoing emails using the outlook client it passes their local IP in the message headers. This is a problem because every time their IP changes the SPF fails on messages they send. Further if the client decides to use her laptop from another location it will use that IP address which is also an issue.

An example of the message headers in gmail is below. So for example if the client is responding via email to a phone call or to a contact form This is causing the clients outgoing emails to wind up in spam folders because it is not passing verification.




SRS is enabled on the server too.

What needs to be done to resolve the issue? Is there a way to make the emails sent via outlook use the servers IP address rather than the clients? The client is losing business because for example if someone calls for info and they tell them they'll email it out quite often it goes to spam or doesn't arrive at all. Obviously an "easy" fix is to use webmail but the client really prefers using outlook. So I'm hoping someone can shed some light on this please?

Thanks

When Google receives an email from a mailserver (versus from an authenticated or unauthenticated user connecting directly to a Gmail SMTP server), they are not going to be scrutinizing your client's actual IP address to determine SPF. They are going to be scrutinizing the IP address of the mailserver IP address that connected to them.

Are you sure "Client IP Address" is your client's actual IP address at the time? If so, based from the limited information that header it looks like they are making a direct connection to Google to send their email to you and not connecting to their cPanel-hosted mailserver in order for the cPanel server to relay it.

I know you likely wouldn't (and probably shouldn't) trust me from Adam, but if you ask on the forums I don't think I've ever steered anyone wrong or jeopardized privacy when they asked me a question. With that said, if you PM me and are willing to share more details of much headers and such I'd be glad to try and help you figure this out.

There simply is not enough information in that limited message header for anyone to tell you what is going on. But I'm fairly confident in saying that if the email chain of delivery is _supposed_to_be_ like what I show below, then that message header does not jive with the delivery method. I don't believe the email was delivered in the fashion outlined below.

client's computer --> authenticated SMTP connection to your hosting server --> relay from your hosting server to recipient mailserver (supposedly Gmail)


Mike

 

[quietFinn]

Are you sure "Client IP Address" is your client's actual IP address at the time? If so, based from the limited information that header it looks like they are making a direct connection to Google to send their email to you and not connecting to their cPanel-hosted mailserver in order for the cPanel server to relay it.

That's what I was thinking too.

 

[Greg M]

Hi guys

This is the address I'm given when I ask the client to verify their IP or just google "My IP" it's dynamic so whenever I add it to SPF obviously it doesnt last long.

I'm due to go away on holiday so if the client doesnt get back to me before then I'll pick this up in a weeks time.

Also regarding Gmail, the client sent the email to my [email protected] cpanel account, however for work I use a Gsuite account, this is set up to download the messages from my cpanel inbox. So while the headers are a little different, Gmail is checking the original sender and not the relay..

Here's a copy of the message headers via roundcube. The client IP is still the same as what Gmail reported and as far as I know, this is still the Clients local IP address.

Return-Path: <[email protected]>

Delivered-To: [email protected]

Received: from myserver.hostname.co.uk

by myserver.hostname.co.uk with LMTP

id Yg+LBMhAQmHlfQAAT4FOzA

(envelope-from <[email protected]>)

for <[email protected]>; Wed, 15 Sep 2021 19:51:52 +0100

Return-path: <[email protected]>

Envelope-to: [email protected]

Delivery-date: Wed, 15 Sep 2021 19:51:52 +0100

Received: from [{CUSTOMER IP}] (port=56942 helo=DESKTOPE9F4AJ9)

by myserver.hostname.co.uk with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

(Exim 4.94.2)

(envelope-from <[email protected]>)

id 1mQa0d-0008Ng-QT

for [email protected]; Wed, 15 Sep 2021 19:51:51 +0100

From: <[email protected]>

To: "'Greg'" <[email protected]>

Subject: Test Email 1

Date: Wed, 15 Sep 2021 19:51:51 +0100

Message-ID: <[email protected]>

MIME-Version: 1.0

Content-Type: multipart/alternative;

boundary="----=_NextPart_000_0F8B_01D7AA6B.20D03EA0"

X-Mailer: Microsoft Outlook 16.0

Thread-Index: AdeqYrkwK3QfxumTRsKLxpu9n1Lo6g==

Content-Language: en-gb

 

[thowden]

Hi

Everything stated so far seems to confirm that the 'customer' has Outlook set to use their local 'whatsmyip' IP as their outbound mail IP. How? No idea, but its wrong.

The customers CPanel account should be configured so that their DNS includes mail.customerdomain.co.uk with the CPanel server IP and likewise its MX record would use mail.customerdomain.co.uk as its CNAME, or optionally, MX points directly to customerdomain.co.uk and that has an A record for the CPanel server IP. The SPF remains the same using +ip4:CPanel Server IP and/or +mx or +A

Outlook should be configured with 'mail.customerdomain.co.uk and the [email protected] as the account name with the relevant password.

The customers 'whatsmyip' IP address is NEVER used for SPF, and is never (should not ever be) tested for SPF as it is just a random client IP, authenticating to the CPanel mail server.

As a last thought, if that customer has a local office server (like an old SBS server) they might still be trying to send via that server which has a changing IP. Not appropriate and the resolution is still as above, use the CPanel server as the authentication point and let it send the email.

I don't think I am saying anything different, just differently, perhaps?

Hope this helps.

Tony

 

[mtindor]

Now, that's a different story. If your customer is using POP3 to fetch their email that is hosted on your server into their Gmail account, I can tell you that just last week I had a customer (who does the same thing - POP3 FETCH of external mail into their Gmail account) contact me about all of the email that they retrieve from their corporate account going into the Spam folder in Google. I researched the issue enough to realize that Gmail has some brokenness going on, that wasn't broke two weeks ago. Their POP retrieval is unreliable right now. And when I Googled some information about it, it isn't the first time this has occurred. The posts I could find on google were all older (perhaps five years old), but it was the very same symptoms.

I had my customer stop POP'ing his email from the cPanel server into Gmail and instead set up a forward in his email account (which wasn't on cPanel but rather on Smartermail) to Gmail. Nothing in Spam folder. All of his corporate email forwards to Gmail and goes into his Inbox.

On my customer's emails that he was POPing from a Smartermail server into Gmail had both failed SPF and DKIM. He sent me about five to look at (full message headers taken from the messages after they arrived in the Gmail Junk Folder). Every one of them passed SPF / DKIM all the way through the chain until Gmail POP'd them in. They were then shown as failed in Gmail.

The Smartermail server (like cPanel) has SRS available and it is enabled. His emails that get forwarded from his Smartermail account into Gmail pass both SPF and DKIM checks at Google.

Google has something broken. Convince your client of it and tell him to instead forward his emails from cPanel to Gmail for a while. At least they will show up in his Inbox. He can always set up a POP again in Gmail to pull items from his cPanel account a month down the road to see if Google has fixed their brokenness.

And yes, I don't care if you are a huge goliath like Gmail / Yahoo / AOL / Comcast / Microsoft -- you can and do have broken systems once in a while. Customers often find that hard to believe.

In my customer's case, they use Mimecast for spam filtering. And I had sent him an email from my Gmail account.

[email protected] --> mimecast spam filtering --> our Smartermail server --- POP3 FETCH connected and pulled down the email

The IP address of our mailserver was not even shown in the Gmail headers of the email that my customer POP3 FETCHED. Gmail ran checks against the Mimecast server IP address. Definitely brokenness in Gmail's POP3 FETCH. I don't know if during the POP3 FETCH Gmail is deleting crucial items, or if they started doing SPF / DKIM checks on POP3 FETCHd mail all the sudden and didn't before. But one of the two happened recently and broke their POP3 FETCH reliability.

Delivered-To: [email protected]m
Received: by 2002:a0c:f70a:0:0:0:0:0 with SMTP id w10csp2381824qvn;
        Mon, 13 Sep 2021 12:53:55 -0700 (PDT)
X-Google-Smtp-Source: ABdhPJxlL+Az3JKTPbBZmsoS5RVFf4H88RDjdg2KxvSuUQZE7zSfOGOjFJiWEYABmyksIF/rwDMwvg1guqg=
X-Received: by 2002:a05:620a:24c1:: with SMTP id m1mr1354336qkn.309.1631562833615;
        Mon, 13 Sep 2021 12:53:53 -0700 (PDT)
Authentication-Results: mx.google.com;
       spf=softfail (google.com: domain of transitioning [email protected] does not designate 205.139.110.61 as permitted sender) [email protected];
       dkim=neutral (body hash did not verify) [email protected] header.s=20210112 header.b=To+8XPFG
Received-SPF: softfail (google.com: domain of transitioning [email protected] does not designate 205.139.110.61 as permitted sender) client-ip=205.139.110.61;
Received: by 2002:ad4:5c67:: with POP3 id i7mf7577174qvh.5;
        Mon, 13 Sep 2021 12:53:53 -0700 (PDT)
X-Gmail-Fetch-Info: [email protected] 1 mail.CUSTOMERDOMAIN.EXT 110 CUSTOMER_USERNAME
Return-Path: <[email protected]>
Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) by mail.CUSTOMERDOMAIN.EXT with SMTP (version=TLS\Tls12 cipher=Aes256 bits=256);
   Mon, 13 Sep 2021 15:51:36 -0400

Notice how there is no IP address of my mailserver in there, no header from my server containing SRS data (because my server did not forward it) -- Google POP3 FETCH doesn't allow for enough information to be pulled in to run a reliable SPF check. And then they decide to do SPF checks using my Gmail address and the mimecast IP, which of course failed.

A forwarded email (once it hit's Gmail) has the SRS address in the Return-Path line and my server's IP address in the Received: line that allows SPF to pass. No such data is available with a POP3 Fetch, which is why they shouldn't be SPF checking POP3 Fetch. Who knows what other checks they are doing on POP3 FETCH'd email that they shouldn't be doing. And this only started happening within the past two weeks.

Return-Path: <SRS0=9DLB=R4=MFD.TROUTRFP.C[email protected]CUSTOMERDOMAIN.EXT>
Received: from mail.CUSTOMERDOMAIN.TXT (mail.CUSTOMERDOMAIN.EXT. [209.xxx.xxx.xxx])
        by mx.google.com with ESMTPS id n15si19156425ybh.163.2021.09.15.06.31.39
        for <[email protected]>
        (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
        Wed, 15 Sep 2021 06:31:39 -0700 (PDT)

Mike

 

[Greg M]

Hi

Everything stated so far seems to confirm that the 'customer' has Outlook set to use their local 'whatsmyip' IP as their outbound mail IP. How? No idea, but its wrong.

The customers CPanel account should be configured so that their DNS includes mail.customerdomain.co.uk with the CPanel server IP and likewise its MX record would use mail.customerdomain.co.uk as its CNAME, or optionally, MX points directly to customerdomain.co.uk and that has an A record for the CPanel server IP. The SPF remains the same using +ip4:CPanel Server IP and/or +mx or +A

Outlook should be configured with 'mail.customerdomain.co.uk and the [email protected] as the account name with the relevant password.

The customers 'whatsmyip' IP address is NEVER used for SPF, and is never (should not ever be) tested for SPF as it is just a random client IP, authenticating to the CPanel mail server.

As a last thought, if that customer has a local office server (like an old SBS server) they might still be trying to send via that server which has a changing IP. Not appropriate and the resolution is still as above, use the CPanel server as the authentication point and let it send the email.

I don't think I am saying anything different, just differently, perhaps?

Hope this helps.

Tony

Thanks Tony,

Yeah I agree there must be something on the clients side. I haven't heard back when I asked for remote access to the laptop in question so I can't verify anything yet. Just thought I'd provide all the relevant info here in the meantime in case it's useful to someone else in the future. I can't replicate the issue my side and the DNS is handled by that cpanel server and does indeed hold the correct mail.domain.co.uk records. The client has used other email systems in their outlook in the past including office 365. However they assured me they followed the cpanel based settings when setting up this address. Again I can't verify myself until they give me remote access but like you and others have suggested I reckon they've maybe missed something. Client is as tech savvy, I have also sent a screenshot of the settings and they said it was correct. Just have to wait on the access.

 

[Greg M]

Now, that's a different story. If you're using POP3 to fetch your corporate mail into Gmail, I can tell you that just last week I had a customer (who does the same thing - POP3 FETCH of external mail into their Gmail account) contact me about all of the email that they retrieve from their corporate account going into the Spam folder in Google. I researched the issue enough to realize that Gmail has some brokenness going on, that wasn't broke two weeks ago. Their POP retrieval is unreliable right now. And when I Googled some information about it, it isn't the first time this has occurred. The posts I could find on google were all older (perhaps five years old), but it was the very same symptoms.

I had my customer stop POP'ing his email from the cPanel server into Gmail and instead set up a forward in his email account (which wasn't on cPanel but rather on Smartermail) to Gmail. Nothing in Spam folder. All of his corporate email forwards to Gmail and goes into his Inbox.

On my customer's emails that he was POPing from a Smartermail server into Gmail had both failed SPF and DKIM. He sent me about five to look at (full message headers taken from the messages after they arrived in the Gmail Junk Folder). Every one of them passed SPF / DKIM all the way through the chain until Gmail POP'd them in. They were then shown as failed in Gmail.

The Smartermail server (like cPanel) has SRS available and it is enabled. His emails that get forwarded from his Smartermail account into Gmail pass both SPF and DKIM checks at Google.

Google has something broken. Convince your client of it and tell him to instead forward his emails from cPanel to Gmail for a while. At least they will show up in his Inbox. He can always set up a POP again in Gmail to pull items from his cPanel account a month down the road to see if Google has fixed their brokenness.

And yes, I don't care if you are a huge goliath like Gmail / Yahoo / AOL / Comcast / Microsoft -- you can and do have broken systems once in a while. Customers often find that hard to believe.

In my customer's case, they use Mimecast for spam filtering. And I had sent him an email from my Gmail account.

[email protected] --> mimecast spam filtering --> our Smartermail server --- POP3 FETCH connected and pulled down the email

The IP address of our mailserver was not even shown in the Gmail headers of the email that my customer POP3 FETCHED. Gmail ran checks against the Mimecast server IP address. Definitely brokenness in Gmail's POP3 FETCH. I don't know if during the POP3 FETCH Gmail is deleting crucial items, or if they started doing SPF / DKIM checks on POP3 FETCHd mail all the sudden and didn't before. But one of the two happened recently and broke their POP3 FETCH reliability.

Delivered-To: [email protected]
Received: by 2002:a0c:f70a:0:0:0:0:0 with SMTP id w10csp2381824qvn;
        Mon, 13 Sep 2021 12:53:55 -0700 (PDT)
X-Google-Smtp-Source: ABdhPJxlL+Az3JKTPbBZmsoS5RVFf4H88RDjdg2KxvSuUQZE7zSfOGOjFJiWEYABmyksIF/rwDMwvg1guqg=
X-Received: by 2002:a05:620a:24c1:: with SMTP id m1mr1354336qkn.309.1631562833615;
        Mon, 13 Sep 2021 12:53:53 -0700 (PDT)
Authentication-Results: mx.google.com;
       spf=softfail (google.com: domain of transitioning [email protected] does not designate 205.139.110.61 as permitted sender) [email protected];
       dkim=neutral (body hash did not verify) [email protected] header.s=20210112 header.b=To+8XPFG
Received-SPF: softfail (google.com: domain of transitioning [email protected] does not designate 205.139.110.61 as permitted sender) client-ip=205.139.110.61;
Received: by 2002:ad4:5c67:: with POP3 id i7mf7577174qvh.5;
        Mon, 13 Sep 2021 12:53:53 -0700 (PDT)
X-Gmail-Fetch-Info: [email protected] 1 mail.CUSTOMERDOMAIN.EXT 110 CUSTOMER_USERNAME
Return-Path: <[email protected]>
Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) by mail.CUSTOMERDOMAIN.EXT with SMTP (version=TLS\Tls12 cipher=Aes256 bits=256);
   Mon, 13 Sep 2021 15:51:36 -0400

Notice how there is no IP address of my mailserver in there, no SRS data -- Google POP3 FETCH omitted multiple lines that they should have retrieved. And then they decide to do SPF checks using my Gmail address and the mimecast IP, which of course failed. If they were going to do SPF checks at all, it should have been against the email in the SRS header (which was not kept after the POP3 Fetch) and our mailserver IP (which was not kept after the POP3 Fetch).

Mike

Hi Mike.


Sorry, just to clarify it's only me that uses the Gmail option and despite the SPF checking the clients IP address, the headers I posted above from roundcube still show the same IP that gmail ran SPF on, so outlook is still sending a local WAN IP of the client and not my server IP. The client does not use Gmail for this account at all and the people she is emailing use a range of email services from standard personal free ones (gmail, yahoo, hotmail etc) to company ones.

The clients emails don't actually go into my own spam folder, gmail just gives it the red ! or ? inside the message which is fine for me personally. The client's main issue is that if she manages to follow up on the phone with someone who hasn't replied to her email, 9 times out of 10 its been found in the spam folder and my client has lost out on new business as it's one of these things where the early bird gets the worm. Generally if she meets a new client face to face or over the phone she will follow up by sending across the info the person is interested in. So, my client is initiating the first email to this new contact and quite often that goes to spam, the reason being seems to be purely the fact that her outlook is sending her local WAN IP as the sending IP and not using the cpanel server.

This is why I am trying to resolve the outlook IP issue, once sorted and assuming the sever keeps a good IP rep, emails should be delivered properly. I am just waiting for a response to my request for remote access (And yes I checked my spam lol)

I do appreciate the info though, we've had to deal with broken O365 and Gsuite systems before, so I too am aware that the 'big boys' can have broken systems too! We also use google sites for some stuff so don't get me started on broken haha.

 

[mtindor]

Hi Mike.


Sorry, just to clarify it's only me that uses the Gmail option and despite the SPF checking the clients IP address, the headers I posted above from roundcube still show the same IP that gmail ran SPF on, so outlook is still sending a local WAN IP of the client and not my server IP. The client does not use Gmail for this account at all and the people she is emailing use a range of email services from standard personal free ones (gmail, yahoo, hotmail etc) to company ones.

In your first post, you post a bit of the message header from a message in Gmail. If that email was sent by your client, through your mailserver, to your email account on cpanel and then forwarded to your Gmail account, you failed to include many important lines of the message header from the email received at Google. But, you said " however for work I use a Gsuite account, this is set up to download the messages from my cpanel inbox ". So you are using POP3 FETCH in Gmail to pull your emails in from your cPanel account to your G.Suite account. And I'm pointing out that POP3 FETCH in Gmail is a bit broken right now, from my standpoint. You shouldn't even bother including message headers from any POP3 FETCH emails in your Gmail account, as Gmail's POP3 Fetch is not going to show the IP address of your mailserver, nor will it show the SRS header (because the email wasn't forwarded). Gmail is running an SPF check against the only IP address it has available to run an SPF check against, your client's IP. If Gmail POP3 FETCH'd mail is going to have SPF checks ran against it, then Gmail needs to collect/use the IP address of the mailserver that it POP3 FETCH'd from . But as you can see, that isn't in the message header you showed from Gmail.

Your Gmail message header shows what I would expect if you POP FETCH'd it (and you admitted you did). It doesn't have the SRS information or your mailserver IP to work with. If the message had been forwarded from your cPanel account to your Gmail account it would have all that, and Gmail would not have ran their SPF check against your client's IP because it would actually have the IP address of your mailserver and the SRS information to do an SPF check.

You need to look at the message headers from a message sent by your client, via your mailserver using SMTP authentication, to an external email account (that isn't using POP3 FETCH). Then look at the message headers in that external email account and see if it's still failing SPF. And if it is, show us those message headers.