SPF started blocking because of own IP RSS Back to forum
@Winfried:
Hello Winfried,
The SPF Test uses the "Sender IP" for its checks, which represents the IP address of the SMTP host responsible for delivering the email to your organization's (broader) network. The 'Remote Peer IP' refers to the IP address of the last connected host that submitted the email to the ORF server. These two addresses match only if no intermediaries were involved in the email delivery, meaning the server sending the email also connected to the ORF server for submission.
The "Sender IP" address is determined using two lists:
1) The Intermediate Host List (IHL): This list defines the boundary between your network and the broader Internet. When external SMTP hosts such as front-ends, security gateways, firewalls, and third-party filters owned by your organization but situated outside your network boundary send emails in a non-transparent fashion (they add their IP to the email's message header), from a public IP address, it is crucial to include their respective IP addresses or ranges in the IHL. Failing to do so could result in ORF being unable to determine the correct Sender IP address, potentially causing false positives in tests like SPF. (ORF Administration Tool: Filtering > Intermediate Hosts)
2) The Received Header List: This contains the IP addresses of the SMTP hosts that processed the email on its way to your mail server. Each delivery "hop" is logged in the email's message header, recorded sequentially under 'Received:' header fields.
By using the aforementioned lists, ORF can correctly identify the sender's IP address. False positives in the SPF Test may occur due to:
- Incomplete or incorrect IHL list: For instance, the external IP address of an email security service or proxy might be missing from the list.
- Compromised message header: A mail server, firewall, or email filter could have altered or removed all, or some of the "Received:" header fields in the message header.
- Incorrect SPF policy: The sending domain's SPF record is missing the IP address or range of the authorized sending server.
Related help pages:
https://vamsoft.com/support/docs/orf-help/6.8.3/adm-intermediatehostlist
https://vamsoft.com/support/docs/orf-help/6.8.3/headeranalysis
https://vamsoft.com/support/docs/orf-help/6.8.3/adm-spf
Please let me know if this has helped in resolving the reported issue.
@Daniel Novak (Vamsoft):
Hi Daniel,
I'm talking about THIS servers OWN IP address.
The exchange server running ORF has a natted IP4 and a public IPv6 address and no intermediate host in front of it.
I've added the anonymized headers of the forum notification.
SPF test previously failed because abcd:abcd:ab:3::2 was not allowed to send in the name of vamsoft.com.
As a workaround I've added abcd:abcd:ab:3::2 to the IHL, but as this is the server running ORF, it doesnt make sense to add itself to the IHL.
Winfried
Received: from mx01.my-domain.tld (abcd:abcd:ab:3::2) by backend.my-domain.tld
(abcd:abcd:ab:2::11) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id xx.x.xxxx.xx; Mon, 7
Aug 2023 11:45:28 +0200
Authentication-Results: mailserver.mail.local; none
Received: from mailserver.mail.local (abcd:abcd:ab:3::2) by
mailserver.mail.local (abcd:abcd:ab:3::2) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id
xx.x.xxxx.xx; Mon, 7 Aug 2023 11:45:25 +0200
Received: from smtp.vamsoft.com (3.223.187.111) by mx01.my-domain.tld (10.0.0.2)
with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id xx.x.xxxx.xx via
Frontend Transport; Mon, 7 Aug 2023 11:45:25 +0200
Received: from vs39 (vs39.vamsoft.com [34.214.185.69]) by smtp.vamsoft.com
(Postfix) with ESMTP id 99B7BD28C5 for <>; Mon, 7
Aug 2023 09:45:24 +0000 (UTC)
MIME-Version: 1.0
From: Vamsoft ORF <>
To: <>>
Date: Mon, 7 Aug 2023 11:45:23 +0200
Subject: [ORF Forum] A new comment has been posted
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64
Message-ID: <.local>
Return-Path:
X-CrossPremisesHeadersFilteredBySendConnector: mailserver.mail.local
X-OrganizationHeadersPreserved: mailserver.mail.local
X-MS-Exchange-Organization-AuthSource: backendserver.domain.local
X-MS-Exchange-Organization-AuthAs: Anonymous
@Winfried:
Unfortunately, without knowing the actual content of the email headers, I won't be able to assist you. Could you please send the following information to for analysis?
- The copy of the email (please do not forward it, send the email as an attachment)
- The configuration file called orfent.xml. It can be found in the ORF program data directory (default: C:\ProgramData\ORF Fusion).
- The ORF text log files from the past two days (orfee-2023-08-07.log, orfee-2023-08-06.log). They can be found on the configured ORF logging path (ORF Administration Tool: System > Log > Text Log - Configure > Settings).
Hi,
I recently upgraded from older 5.4.1 to 6.8.3 to get IPv6 support and I just realized that it started tonight at 2 am (0 am GMT) to block many e-Mails due to my own local IPv6-Adress not being allowed to send in the name of the external sender!?
In LogViewer Remote Peer IP is correct and does validate just fine in SPF-Checker, this servers own IPv6 address is listed as "Sender IP"
Sender gets:
550 5.7.23 SPF check failed: servers:own:local:ipv6:address is not authorized to send in the name of "external-sender-domain.com".