lhutton wrote: ↑23 Feb 2024, 22:16
I'm an email admin (been doing my own mail for 17 years, did it for a university before we went Google) and yeah this is stupidly easy to fix.
But, it might not fix Gmail delivery completely as they are finicky as all get out (Sendgrid makes good money for a reason). I do see a SPF record, but no DMARC when I check their DNS. The SPF is an include: directive which, IMO, isn't the way I'd do it:
Code: Select all
deskthority.net. 243 IN TXT "v=spf1 include:zoho.eu ~all"
That's interesting since I could swear there was no SPF record the last time I checked.
In any case, looking at the headers of emails I have recently received from the DT server, the source IP is absolutely the web server, and the emails are not being relayed through zoho.eu mail servers. So I would expect the DT server to run afoul of "~all" thus causing mail sent by it to softfail.
They could fix this either by adding "a" to the TXT string as I mentioned previously (or "ip4:159.69.68.22" if they wanted to be explicit about it...but then that would require that they remember to specifically update the SPF record every time the IP address of the server had to change), or they could decide to simply reconfigure the server's outgoing mail to send everything through zoho.eu rather than attempt to deliver mail to recipient's servers directly. (Also, if they just listed "mx" in the record, since they already have three MX records that reference zoho.eu mail servers, they wouldn't need to bother with also putting "include:zoho.eu" in there, which would also ease future administrative burden if they ever change mail server providers). Thus why I suggested "a mx" earlier. "a:mech.deskthority.net" I added because it's not 100% clear to me if SPF check pass/fail would take in-addr.arpa PTR records into consideration or not.)
soyuz wrote: ↑23 Feb 2024, 22:27
Everything I've ever experienced with gmail is if you don't have SPF
and DKIM you're going nowhere. I think my domains that I don't care about as much where I haven't added DMARC records are still deliverable with just that.
On one of my vanity domains that I run a mail server on & have for years, I only have an SPF record. No DMARC, no DKIM set up. I can deliver mail to Gmail accounts with zero problems. In fact, I have a permanent forward in place from one of my mailboxes to one of my Gmail accounts. Mail is delivered just fine. Years ago, I had problems before adding an SPF record (+ also made sure I was "remailing" and not "forwarding", as true forwarding would trigger an SPF failure since it would look like my server was sending mail on behalf of domains that don't belong to me). Haven't had a problem since.
The Google article linked to previously with their requirements mentions that DMARC is only required if you sent > 5,000 mails to Gmail servers
on a daily basis. If all you're doing is running a mail server that's hosting mailboxes for actual, real people, then you probably don't need to worry about this. If you are running a system that sends out automated emails (like a phpBB server, say; or a listserv, or a Mailchimp-like service, etc.), you may or may not ever run into a problem here, depending on how busy and active of a user-base you have. My guess is DT isn't sending out that many emails, and so lack of a DMARC record is not the issue here (especially since this "requirement" appears to be new as of February, and DT has had problems delivering mail to Gmail inboxes for a LONG time now). But probably better safe than sorry, especially since it's such an easy "fix". However, it's almost surely not "the" problem.
lhutton wrote: ↑23 Feb 2024, 22:39
I've was a pretty early adopter of all three and Gmail still sometimes bins mail from my domains because it's a Tuesday it seems. They are infuriating to work with and I steer everyone I can clear of using a GMail account these days. Never had issues out of MS or anyone else.
As usual, it's the bad actors that are ruining things for everyone. Whether they are overreacting or not is debatable, but what's pretty obvious is that all of these rules and restrictions that they are implementing are in place in order to curb junkmail. Such a pursuit is a constant cat-and-mouse / whack-a-mole game for providers. They're likely also tight-lipped about all of the things that they are doing to try to detect garbage coming in, so as not to tip off the baddies about how they are detecting their junk & not show their entire hand / give them clues about how to circumvent the detection.
As for the rest of this thread, that discussion appears to be going about as well as I expected...sigh