GMAIL spf check uses the senders ip address not the server (so fails)

Problem reported by dean brown - 6/19/2023 at 8:43 AM

Submitted

5.7.26 This mail is unauthenticated, which poses a security risk to the

5.7.26 sender and Gmail users, and has been blocked. The sender must

5.7.26 authenticate with at least one of SPF or DKIM. For this message,

5.7.26 DKIM checks did not pass and SPF check

It checks the users public ip address, instead of the email server's address, even though Outlook 2021 is setup to send email through the email server with SSL

This doesn't occur on all gmail accounts as a test to mine works with no issue.

Build 8566

7 Replies

Reply to Thread

Kyle Kerst Replied

6/19/2023 at 8:59 AM

Employee Post

This error seems to point at their message lacking authentication information for the domain itself; SPF/DKIM/DMARC/etc. Can we have you open a ticket for this so we can help track it down?

Kyle Kerst Lead Internal Network/System Administrator SmarterTools Inc. smartertools.com

dean brown Replied

6/19/2023 at 10:31 AM

Thx, case opened

Lasse B. Replied

6/21/2023 at 1:29 AM

Seems like intermediate mail server IP addresses are checked in the Spam Checker. Your Gmail Mail Server IP may be white listed and the Spam Checker looks at an intermediate IP address instead. Have the same issue when sending from Microsoft as the Spam Cheker module checks an intermediate IPv6 IP address which is (and never will be) listed in a SPF record. I have a case open for the issue/bug.

Kyle Kerst Replied

6/21/2023 at 9:51 AM

Employee Post

On the SmarterMail side you do need to add intermediary server IPs to the Settings>Antispam>IP Bypasses list to ensure SmarterMail bypasses that IP during spam checks and checks the appropriate IP that is behind it, and Gmail may have something similar on their end. That being said, SPF records for domains should be configured to include all IP addresses that send on behalf of the domain.

Kyle Kerst Lead Internal Network/System Administrator SmarterTools Inc. smartertools.com

dean brown Replied

6/21/2023 at 10:11 AM

Thx, but it looks like the problem is occurring outside of my control. The receiving users email server uses somekind of AV system that is changing the the ip address to not match the proper one (thus failing the SPF check).

Lasse B. Replied

6/21/2023 at 11:49 AM

@Kyle: I don't know if we have the same understanding of intermediate mail servers. But I mean everything between the Originator and Gateway Systems in the sender's mail environment. That would be "Delivery" and "Relay" servers, which may is added with the designation "Received:" in the mail header for log tracking. But nothing else either. Not for use for SPF validation.

Maybe the list with "Received:" in the header is also referred to as "reverse-path" so that ex. delivery notifications can find the way back and notify the originator about delivery.

So for an email header like the one below. SmarterMail must NOT attempt to check the IPv6 address:
2603:10a6:20b:58c::15 (which it unfortunately does)

Only 40.107.247.56 should be checked. If I read the "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1" (https://datatracker.ietf.org/doc/html/rfc7208#section-2) correctly.

Return-Path: <visit@mydomain.dk>
Received: from EUR02-AM0-obe.outbound.protection.outlook.com (mail-am0eur02on2056.outbound.protection.outlook.com [40.107.247.56]) by mail.mydomain.dk with SMTP
(version=TLS\Tls12
cipher=Aes256 bits=256);
Wed, 21 Jun 2023 09:52:31 +0200
ARC-Seal: ***removed for better readability***
ARC-Message-Signature: ***removed for better readability***
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
smtp.mailfrom=mydomain.dk; dmarc=pass action=none header.from=mydomain.dk;
dkim=pass header.d=mydomain.dk; arc=none
DKIM-Signature: ***removed for better readability***
Received: from AS4PR02MB8624.eurprd02.prod.outlook.com (2603:10a6:20b:58c::15)
by DB4PR02MB8557.eurprd02.prod.outlook.com (2603:10a6:10:38b::13) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6500.37; Wed, 21 Jun
2023 07:52:17 +0000
Received: from AS4PR02MB8624.eurprd02.prod.outlook.com
([fe80::6c19:6bd5:8491:3648]) by AS4PR02MB8624.eurprd02.prod.outlook.com
([fe80::6c19:6bd5:8491:3648%5]) with mapi id 15.20.6521.023; Wed, 21 Jun 2023
07:52:17 +0000
From: The User <visit@mydomain.dk>
To: Another User <user@smartermail-server.dk>

The header is just a modified sample to show the meaning of "intermediate" servers.

Zach Sylvester Replied

6/21/2023 at 12:54 PM

Employee Post

Hey Dean,

An interesting test would be to turn off the append received line on the message.
This would be in Settings->Protocols.

Please give that a try and let me know your results.

Thanks,

Zach Sylvester Software Developer SmarterTools Inc. www.smartertools.com

Back to Community Threads

Please leave this box unchecked

Reply to Thread

Enter the verification text