This makes a ton of sense to me. Getting email delivered these days is an absolute nightmare. I personally use Postmark, but it's true that I still had to set up my SPF record manually, and I think @LiberalArtist 's suggestion is right on the money.
Possibly relevant (and a bit of show and tell): It’s so common for businesses we work with (at work) to forget to update their SPF records that I wrote a Racket script to generate helpful notices. When we get legitimate email quarantined for SPF failures (about once a week on average), I open a terminal and run a
raco command with the email’s “From” domain and the IP address of the sending server:
raco canned spf example.com 184.108.40.206
The script then looks up the domain’s SPF record, does a reverse-lookup of the sending server’s IP address to determine what service they’re using to send emails, does a WHOIS lookup to figure out their registrar, and generates a notice incorporating all that info, and copies it to the clipboard so all I have to do is open a new email and paste it in:
I’m the IT admin at [company]. We’re having trouble receiving emails from your organization; they are being sent from a server that example.com does not list as one of its legitimate servers. When this happens, the emails are marked as Fraud and cannot be released for delivery by anyone except a system administrator.
I’ve included some details about the problem and how to fix it below. If you do not have access to your company’s DNS records, please forward this email to someone in an IT role. If anyone would like to contact me directly, I would be happy to help: my direct number is […]. (A phone call might be best in this case — because of this email issue.)
This problem is likely hurting the deliverability of your emails to other companies as well. SPF checks are one of the basic ways that companies are increasingly using to combat spam and phishing threats.
Some or all of the emails being sent from @example.com to Winsted are being delivered by a server with the IP address 220.127.116.11, but this address is not listed as a legitimate server in the SPF records for example.com.
example.com's current SPF record is:
v=spf1 include:mailgun.org ~all
Your email headers indicate that your organization is using Google Domains to send your emails, and indeed, your SPF record shown above is missing some or all of the servers used by Google Domains.
Since your organization sends email via Google Domains, you MUST include the directive
include:_spf.google.comin your SPF record. (Define your SPF record—Basic setup - Google Workspace Admin Help)
The example.com domain appears to be registered through “Network Solutions, LLC”. The person at your organization with access to the Network Solutions, LLC account for the example.com domain should log in and update the above SPF record.
This code is awesome, so many thanks for sharing it! Based on the fact that you & @LiberalArtist are both suggesting the same change to SPF, I think it's probably the right change. Indeed, I've made this change. @Grafcube , are you willing to give this another shot?
I just tried registering again. I haven't received anything yet so I'll wait a bit (since when I tested with gmail it took about 8 hours to arrive). I'll update here if it works.
Wow, so sorry that this is taking such an absurd amount of time. At this point I'm again wondering whether there's a blacklist; so, for instance, gmail may be refusing to relay this mail to your address because your server rejected email before.
I continue to believe that the right solution here is just to generate the code by hand. That's not something that I believe I have access to, sadly.
Oh! Another ridiculous hack workaround. I could create the package for you, pointing to a repo of yours, and add you as an owner of the package. You wouldn't be able to edit the package meta-info until you get your SEKRIT MAJIC KODE but you would still be able to update the repo normally, thereby making changes to the package.
I just tried to email verifications codes to (1) a live.com email address, (2) a yahoo.com email address, (3) a gmail.com email address and (4) my work address, which is gmail but with a company domain.
In all cases, I received the verification code within seconds, in the time it took to switch to the email tab in my browser and hit refresh. Also in all cases, the verification email was delivered to Inbox and not marked as spam.
Whatever the problem might be, it does not seem that live.com, Yahoo or Gmail simply reject emails from pkgs.racket-lang.org.
I guess it would be better if you added the package for me. I'll push my repo later today. I would ideally prefer to register and do it myself though so if there's any way for me to receive the code on either of my preferred emails that would be better. I just tested again with my disroot, tutanota and throwaway gmail and it arrived on gmail almost immediately. Nothing on disroot or tutanota.
I made a temporary email address and registered for the package server to test. Here's the result as I received it, including the authentication headers added by Google and Fastmail (the provider I used): https://paste.debian.net/1270454
In particular, the header
X-Mail-from: firstname.lastname@example.org (line 20) indicates that the original SMTP envelope sender was
email@example.com. Thus, the changes to the racket-lang.org SPF record didn't help. Here's Fastmail's SPF evaluation (lines 111–117):
Received-SPF: none (plt-scheme.org: No applicable sender policy available) receiver=mx3.messagingengine.com; identity=mailfrom; envelope-from="firstname.lastname@example.org"; helo=mail-pl1-f169.google.com; client-ip=18.104.22.168
Ultimately we should figure out how to make the SMTP envelope sender be
email@example.com to match the
From: The Racket Package Server <firstname.lastname@example.org> header. But, as a workaround, maybe setting the plt-scheme.org SPF record to:
"v=spf1 include:racket-lang.org ?all"
Do Disroot and Tutanota have especially strict spam blocking more generally? Ultimately Racket needs to fix our email settings, but they seem more likely to have helpful sysadmins that could offer advice than the behemoth providers would.
I'll contact Disroot support to see if there's anything they can do.
It's been 22 days and I haven't gotten a response yet. When I sent the mail I got an automatic response saying that due to high load it may take some time for a response.
I decided to post on forum.disroot.org instead and when I checked for similar threads I found this one which might be of interest: Unable to receive notification & OTP emails - support - Disroot - Forum
Nevermind I just tried again and I got the email immediately. I have successfully created an account.
No idea if the SPF thing solved it and I just had to wait or if something else changed but it looks like it works now.
Edit: I just tried with Tutanota though I don't intend to actually create an account with it and the email arrived immediately. I did also see a concerning message though so that might be a problem:
The question mark goes to this site: Tutanota FAQ