SPF Softfail
Hi All,
Firstly: I'm a member of a club, got volunteerd as "Website Guru" as I was about the least ignorant member of the club, but I don't know much about websites.
Our website is on a shared server, hosted by an Australian web-hosting company. I can log into cPanel to see all the settings.
cPanel version 102.0.18
OS Linux
Server name CP11
Our website sends acknowledgement emails from a PHP page to members when they upload. The emails always (?) have SPF Softfail, members with gmail get a prominent yellow warning that it is phishing or spam.
Our SPF text record is:
v=spf1 +mx +a +ip4:xxx.xxx.xxx.xxx +ip4:yyy.yyy.yyy.yyy +include:relay.mailchannels.net -all
This was not set up by me - presumably when the club bought its website (before I was a member) it came ready-configured.
I opened a support ticket with the web-hosters, sent them email source with "SPF Softfail" and screengrabs saying "Beware it's phishing". They told me the SPF record was correct, ignored all the supporting data, and closed the ticket and won't re-open it.
Yeah, I know, we should change web-hosters, but that's not my call - club committee not yet keen to change.
I searched this forum, found quite a few people with similar problems. The general advice seems to be: check your SPF record, DKIM record and DMARC record. I don't really know enough to do that.
What I did try was including or excluding "-all" at the end of the SPF recod - no change, still SPF Softfail.
The SPF record looks correct. It seems all our email is routed through a Canadian company called relay.mailchannels.net, though through random servers of theirs. Different tests arrive from different IP addresses within relay.mailchannels.net's IP address range, and different server names e.g. hamster.birch.relay.mailchannels.net
Looking at the source of an email (see below for full source) the relevant lines are:
spf=softfail (google.com: domain of transitioning ourusername@cp11.ourisp.com.au does not designate 23.83.209.80 as permitted sender) smtp.mailfrom=ourusername@cp11.ourisp.com.au
Received-SPF: softfail (google.com: domain of transitioning ourusername@cp11.ourisp.com.au does not designate 23.83.209.80 as permitted sender) client-ip=23.83.209.80;
Looking up whois.com shows 23.83.209.80 is relay.mailchannels.net (as specified in our SPF record).
So I added their IP address range to the SPF record - that was one suggestion on one of the forum threads. I changed it to:
v=spf1 +mx +a +ip4:xxx.xxx.xxx.xxx +ip4:yyy.yyy.yyy.yyy +ip4:23.83.208.0/20 +include:relay.mailchannels.net -all
No luck, still SPF Softfail.
Near the bottom of the source are 2 lines:
Received: from cp11.ourisp.com.au (cp11.ourisp.com.au [xxx.xxx.xxx.xxx]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by 100.101.255.191 (trex/6.7.1); Mon, 20 Jun 2022 06:48:34 +0000
X-PHP-Script: ourclub.org.au/test_mail.php for 118.209.199.213
The xxx.xxx.xxx.xxx IP address matches our SPF record.
Looking up whois.com 118.209.199.213 is IInet.com.au, one of the 3 or 4 really huge ISPs in Australia. They are not (directly) our web hosters, our web hosters are a much smaller company.
Also note that our username, as in ourusername@cp11.ourisp.com.au in the SPF Softfail line, is just 8 random letters - what we use to log into cPanel.
Why is the SPF record not working?
How can I fix it?
Or is the only solution to ask our web-hosters, as it doesn't seem to be a cPanel problem?
Thanks in anticipation,
Rob
Email source:
Original Message
Message ID
Created at: Mon, Jun 20, 2022 at 2:48 PM (Delivered after 5 seconds)
From: Automatic acknowledgement
To: test_gmail
Subject: gmail test
SPF: SOFTFAIL with IP 23.83.209.80 Learn more
Delivered-To: me@gmail.com
Received: by 2002:a05:7010:34ca:b0:2d7:38ca:529e with SMTP id z10csp2499482mdi;
Sun, 19 Jun 2022 23:48:36 -0700 (PDT)
X-Google-Smtp-Source: AGRyM1vye08YWYmN793S5RS4qcbOCN2/XvaDUXxJABk8zS8DwN9g70WQc8L7a4SuwzrM3TetKpWR
X-Received: by 2002:a17:902:ea0f:b0:164:1a71:bef1 with SMTP id s15-20020a170902ea0f00b001641a71bef1mr22232418plg.52.1655707716586;
Sun, 19 Jun 2022 23:48:36 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1655707716; cv=pass;
d=google.com; s=arc-20160816;
b=gCwAip7PhZ+o7gWkrvvaNuz4jO0yacEBrv/c2OlPXqsr3oucQ2EAvaIxybWKp3Gxaq
vESOhFR/ozKD7zQ3JW0doLo16XFdQ4y6Nka+xmBITB5RpqEqwKNAb8w5FerVkLyac+o2
tHuFSQkSXFg0M0aCITdydCtnPm+InRrOd58J9c6h4N0hmmvajK5DYakI2/9petudiITz
kqiZypxKJQlfKJu/DtruzLKaIhnshsPKoLUUOi6NIi/v2E3BEDW8H6yViqfNCk/JfhuF
/pREceFKwrUH+1rCrPm1dqfjwOvgwQgqz7FtMTTHidAqt+yukrPoyicB9AY4iX1VdJ5o
E04A==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
h=date:message-id:from:subject:to;
bh=Pb6s/Xlf4u1eDlYyO0NCaMRMrCg6xDNkK5byz8RDY1s=;
b=P5EoyCBzd+BTn+QnzTx7ck3anB0h7Y4pNTwPOR+FK+pM5n+pjG5xwUve373se+U5pW
MCV3vZvvMYFHKMpttIpHDxskhFcc9Pk97KtW7rAtUM8liXTRqxaXCvJ2qdXWK2Puq0+Y
tl/OY5GW4WY9tLVmrxhd7qsRmd3iaCdh5eEfHZyEkGHmbPyAkNPFYSC3zrbegzDnE6Nl
I3ediFDAwwW0CNqHb7AKZnPdv7tHS8TyIxqC2p7AqrQYoB/QuIy99YBjTopfSyArenIT
ZxEe+F03T3iG0UnH2ntmxylgwOK77fxZwWQj5xPeE2228aILUrBk9AdISSi5PKr5dpPq
mHzA==
ARC-Authentication-Results: i=2; mx.google.com;
arc=pass (i=1);
spf=softfail (google.com: domain of transitioning ourusername@cp11.ourisp.com.au does not designate 23.83.209.80 as permitted sender) smtp.mailfrom=ourusername@cp11.ourisp.com.au
Return-Path:
Received: from hamster.birch.relay.mailchannels.net (hamster.birch.relay.mailchannels.net. [23.83.209.80])
by mx.google.com with ESMTPS id l10-20020a17090b078a00b001e8895ce589si13591917pjz.186.2022.06.19.23.48.35
for
(version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
Sun, 19 Jun 2022 23:48:36 -0700 (PDT)
Received-SPF: softfail (google.com: domain of transitioning ourusername@cp11.ourisp.com.au does not designate 23.83.209.80 as permitted sender) client-ip=23.83.209.80;
Authentication-Results: mx.google.com;
arc=pass (i=1);
spf=softfail (google.com: domain of transitioning ourusername@cp11.ourisp.com.au does not designate 23.83.209.80 as permitted sender) smtp.mailfrom=ourusername@cp11.ourisp.com.au
X-Sender-Id: ourisp|x-authuser|ourusername@cp11.ourisp.com.au
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 2BAD28E11A5; Mon, 20 Jun 2022 06:48:35 +0000 (UTC)
Received: from cp11.ourisp.com.au (unknown [127.0.0.6]) (Authenticated sender: ourisp) by relay.mailchannels.net (Postfix) with ESMTPA id 4BBD48E1F51; Mon, 20 Jun 2022 06:48:34 +0000 (UTC)
ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1655707714; a=rsa-sha256; cv=none; b=4mZZJWKw88GpQnL5OXszu0zFJZy2GZZB4KfILitPS3s1H1RVyjhcJKXdNu9mQ8bqMroQk0 wfbbY0Cy6B/RbUqB9/5guwxuva1FZAPZ5cM/xZ6QoyWDE58pYLtNjs1qBIL/dPcGLrjOD8 IMRs9+R3QFDJ2WlPW5elL8i2FtPOahqwOB0u22Hh3crbzrhlGcMc1tHW0TpCsWx3fzXAYm ZyVt7MlIuoVPWqACMf9zefFOe02Ee2+rEcbhdlslOAxaba3p1crYclPwC6hZH/BCVU+B1A pOWcu1rV4/eGBtpDlLAfyhecQPLFTZqKlLHMj9JN2PiYM7LTCPwifxOO/9ly7A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1655707714; h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc; bh=Pb6s/Xlf4u1eDlYyO0NCaMRMrCg6xDNkK5byz8RDY1s=; b=ZpYIR/YNe6ZOzPTTurxnetkbG2iRa9yfeXemcwFoZ5hlZwHGeePy6qmMESDgZw/P5jXm+1 o4VhewSLFoSU0Yy5+hCzqRxScSaE1fuzoL5thi/W13r2YhtdwAV4mMZqH9p4GZN9S0QUpp T4BOSvySUD1I42WIlS9G+tus64MQtVjBSWGW16BC2BgFQqYf6AVRpfwOHbi2GfaABPVc1k 0bv2tuPEl/TEtQIfBigqAnaFHiacpoFkkBXn6S+ta3W1apS6P2Ee7WO2AzP2Xu+hl9zLsq GFigXojANTmW7lZsISqbJPoJ5D+atuEx8ODHCMxJP99fOZ8Z444hmhRA7Lrx3w==
ARC-Authentication-Results: i=1; rspamd-848669fb87-xl24g; auth=pass smtp.auth=ourisp smtp.mailfrom=ourusername@cp11.ourisp.com.au
X-Sender-Id: ourisp|x-authuser|ourusername@cp11.ourisp.com.au
X-MC-Relay: Neutral
X-MailChannels-SenderId: ourisp|x-authuser|ourusername@cp11.ourisp.com.au
X-MailChannels-Auth-Id: ourisp
X-Blushing-Name: 470583ff6b3e2b69_1655707714938_793864700
X-MC-Loop-Signature: 1655707714938:951196268
X-MC-Ingress-Time: 1655707714938
Received: from cp11.ourisp.com.au (cp11.ourisp.com.au [xxx.xxx.xxx.xxx]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by 100.101.255.191 (trex/6.7.1); Mon, 20 Jun 2022 06:48:34 +0000
Received: from ourusername by cp11.ourisp.com.au with local (Exim 4.95) (envelope-from ) id 1o3BD5-0001g8-Jl; Mon, 20 Jun 2022 16:48:31 +1000
To:
Subject: gmail test
X-PHP-Script: ourclub.org.au/test_mail.php for 118.209.199.213
X-PHP-Originating-Script: 1060:test_mail.php
From: Automatic acknowledgement
Message-Id:
Date: Mon, 20 Jun 2022 16:48:31 +1000
X-AuthUser: ourusername@cp11.ourisp.com.au
test message
-
Hey there! First of all, but not being familiar with the tools, you've definitely done your homework! You're correct that this isn't a cPanel problem, but we'll still see if we can come up with something. I'm not sure the SPF record is formatted correctly as the additional "+" signs could be causing the issue. Instead of this: v=spf1 +mx +a +ip4:xxx.xxx.xxx.xxx +ip4:yyy.yyy.yyy.yyy +ip4:23.83.208.0/20 +include:relay.mailchannels.net -all Could you try this? v=spf1 ip4:xxx.xxx.xxx.xxx ip4:yyy.yyy.yyy.yyy ip4:23.83.208.0/20 include:relay.mailchannels.net +a +mx -all and see if that changes things? 0 -
Thanks for the reply. Unfortunately the version of cPanel we have 102.0.18 doesn't let us change the SPF record directly - it's all done through selecting text boxes on a web page, then joined together by cPanel. No option to actually edit the text - can't remove the + characters, can't change the order of the bits and pieces. The preview box at the bottom is not editable. 0 -
Ah, thanks for that. If you're using the interface tool, then it's definitely correct. I'm just not as used to seeing the + before each address, but a bit more research shows me that is fine. Unfortunately I don't have any other good ideas as to why you'd be experiencing those issues. It might be best to try and reach out to Gmail support directly to see if they could give you more details on specifically why they are flagging the message. As another possible test, do you experience the same issue with other major providers, like Yahoo or Hotmail? 0 -
Are you setting the SPF record for [font="courier new">cp11.ourisp.com.au? The line: [font="courier new">[plain]spf=softfail (google.com: domain of transitioning ourusername@cp11.ourisp.com.au does not designate 23.83.209.80 as permitted sender)[/plain] Would seem to indicate that the message is being sent by [font="courier new">[plain]ourusername@cp11.ourisp.com.au[/plain] Perhaps that's not the intended sender? What nameservers or DNS server is handling world-wide Internet traffic for the hostname [font="courier new">[plain]cp11.ourisp.com.au[/plain] The cPanel interface will only update the DNS record on the DNS server that the cPanel server is authorized to use (i.e. the same server itself or an attached DNS cluster). If you are using a 3rd party nameserver service (i.e. CloudFlare), then updating the SPF record in the cPanel interface will have no bearings on what the rest of the world sees when it does an SPF lookup. If you're on Linux, then running: [font="courier new">dig cp11.ourisp.com.au TXT will show the SPF record as the rest of the world sees it. Just don't run this command on the same server that is hosting the account, because you may be using local DNS on that server (not recommended). If it's not showing the SPF record that you have set in your cPanel, then you're either not using the correct nameservers or there is a DNS issue some where that is preventing the update. 0 -
Hi sparek-3, The server is not ours; it's a shared server run by a web-hosting company in another city. Edit: I run windows but learnt today how easy it is to make a bootable linux thumbdrive. Ran the dig command and got: cp11.ourisp.com.au 1440 IN TXT "v=spf1 +mx +a +ip4:xxx.xxx.xxx.xxx ~all" SERVER: 127.0.0.53#53 (127.0.0.53) *Note: the xxx.xxx.xxx.xxx matches the first IP address in our SPF record. My two takeaways from this are: 1. The SPF record I fill in on cPanel isn't used - it's different, no reference to the second IP4 address, no reference to relay.mailchannels.net. Our webhosting company must set the SPF record elsewhere, presumably for the entire cp11 shared server in toto, hosting as it does 10 or 20 or 50 websites/domain names. 2. There is a ~ tilde before "all", not a minus sign. That was mentioned on one of the other threads I looked at a few days ago; changing it to a minus sign fixed the other person's problem, from memory. Now I can't find the thread. But the ~ is not what I put into cPanel, again making me think that our SPF record is set elsewhere, not by me through cPanel. Are those two guesses reasonable? Your question regarding who the sender is is interesting. As far as we're concerned emails go out from the address "donotreply@ourclubname.org.au". We have various mailboxes set up in cPanel e.g. president@ourclub.org.au, info@ourclub.org.au etc. Send an email to those addresses and it arrives and auto-forwards. When I go to "Email Deliverability" in cPanel I get one option: Manage Domain for ourclub.org.au The Manage Domain page (anonymised) screengrab is shown. Mail HELO is cp11.ourISP.com SPF record "NAME" is ourclub.org.au So the answer to your question is - I don't know what the SPF record is associated with - the cp11 server or the webaddress ourclub.org.au and I'm also not sure who the intended sender is. But I guess it's ='donotreply@ourclub.org.au'>donotreply@ourclub.org.au Edit: I suspect it's ourclub@cp11.ourISP.com that is the sender. The web-hosting company consider us to be their client "ourclub" residing on their server cp11, along with 10 or 20 or 50 other websites. They send our email from their cp11 server. Lower down there is a reverse DNS pointer PTR record pointing from the cp11 server to our domain name, presumably for incoming email? (When I do a who-is on the IP address zzz.zzz.zzz.zzz it comes back "Permission denied.") I also don't know what nameserver is handling Domain Name lookup for the CP11 server.... OK a quick google shows 3 nameservers ns1-, ns2-, and ns3.ourisp.com.au but they are reported having IP addresses and being owned by another company in Australia that I've never heard of. cPRex, not sure about other big email companies, but on my small local ISP mails that come in to my personal email address also have SPF softfail. I never noticed because it was not enough to trigger their spam-filter. Following the link on the "Manage Domains" page to the "Zone Editor" I can text-edit the SPF record. Also MX records and A records. Not really keen to alter anything; too much chance of breaking it through ignorance. Thanks everyone for all the help. Rob 0 -
I'm wondering if the issue is simply that the DNS is managed on a separate machine by the host, and they just need to update the SPF to what you have configured in cPanel. 0 -
cPRex I think you're right, sparek-3 too. The nameservers at the third-party company have incorrect SPF record, and I can't change that through cPanel to our web-hoster's server. Our web-hoster has overlooked the problem, easy enough to see how they could have - in their place I would have, too. I've passed on all your and sparek-3's ideas to our web-hoster, hopefully you're right and they'll recognise that and fix the problem. Thanks again for your help. Rob 0
Please sign in to leave a comment.
Comments
7 comments