On 2024-08-16 at 08:03:05 UTC-0400 (Fri, 16 Aug 2024 08:03:05 -0400)
Alex <mysqlstud...@gmail.com>
is rumored to have said:
It says that SPF failed, but SPF_PASS was hit, presumably from our
connection to Microsoft, not their connection to the spammer client:
Correct. You can only check SPF on the first SMTP transaction guided by
an MX record and recorded by a trusted server.
Received-SPF: Fail (protection.outlook.com: domain of toppersrvs.com
does
not
designate 35.230.39.135 as permitted sender) receiver=
protection.outlook.com;
client-ip=35.230.39.135; helo=[127.0.0.1];
Received-SPF: Pass (mailfrom) identity=mailfrom;
client-ip=52.100.167.207;
helo=nam12-mw2-obe.outbound.protection.outlook.com; envelope-from=
administra...@toppersrvs.com; receiver=buckknives.com
ARC also failed:
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=fail (sender
ip is
35.230.39.135) smtp.rcpttodomain=buckknives.com smtp.mailfrom=
toppersrvs.com;
dmarc=none action=none header.from=toppersrvs.com; dkim=none (message
not
signed); arc=none (0)
Should I also somehow be checking these SPF failures?
You really can't with SA, because it is not generally safe to trust the
Received headers written by systems you don't control or have some sort
of explicit relaying arrangement with. Because the initial submission of
messages CANNOT be subjected to SPF tests, you don't want to test
transactions that are not following an MX record.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo@toad.social and many *@billmail.scconsult.com
addresses)
Not Currently Available For Hire
