Thunderbird email rejected by Gmail
Email Send from Thunderbird gets : \- These recipients of your message have been processed by the mail server: xxxxxxxxxxx@gmail.com; Failed; 5.3.0 (other or undefined mail system status)
Remote MTA gmail-smtp-in.l.google.com: network error - SMTP protocol diagnostic: 550-5.7.26 The MAIL FROM domain [mindspring.com] has an SPF record with a hard\r\n550-5.7.26 fail policy (-all) but it fails to pass SPF checks with the ip:\r\n550-5.7.26 [65.20.63.171]. To best protect our users from spam and phishing,\r\n550-5.7.26 the message has been blocked. Please visit\r\n550-5.7.26 https://support.google.com/mail/answer/81126#authentication for more\r\n550 5.7.26 information. v13-20020a2e960d000000b002c033848085si9415366ljh.54 - gsmtp
When send from Earthlink Webmail, NO Problem. I upgraded Thunderbird... No help.
Gmail POSTED the following:
Email authentication requirements & recommendations
We require that you set up these email authentication methods for your domain. Authenticated messages:
Help protect recipients from malicious messages, such as spoofing and phishing messages. Help protect you and your organization from being impersonated. Are less likely to be rejected or marked as spam by Gmail.
Set up email authentication for each of your sending domains at your domain provider. In addition to following the instructions we provide, you should also refer to your domain provider's email authentication instructions. To verify messages are authenticated, Google performs checks on messages sent to Gmail accounts. To improve email delivery, we recommend that you always set up SPF, DKIM, and DMARC for your domains. Make sure you're meeting the minimum authentication requirements described in Sender Guidelines. Messages that aren’t authenticated with these methods might be marked as spam or rejected with a 5.7.26 error. If you use an email service provider, verify that they authenticate your domain’s email with SPF and DKIM. We recommend you always use the same domain for email authentication and hosting your public website. SPF SPF prevents spammers from sending unauthorized messages that appear to be from your domain. Set up SPF by publishing an SPF record at your domain. The SPF record for your domain should reference all email senders for your domain. If third-party senders aren't included in your SPF record, messages from these senders are more likely to be marked as spam. Learn how to define your SPF record and add it to your domain. DKIM Turn on DKIM for the domain that sends your email. Receiving servers use DKIM to verify that the domain owner actually sent the message. Learn how to turn on DKIM for your domain. Important: Sending to personal Gmail accounts requires a DKIM key of 1024 bits or longer. For security reasons, we recommend using a 2048-bit key if your domain provider supports this. Learn more about DKIM key length. DMARC DMARC lets you tell receiving servers what to do with messages from your domain that don’t pass SPF or DKIM. Set up DMARC by publishing a DMARC record for your domain. To pass DMARC authentication, messages must be authenticated by SPF and/or DKIM. The authenticating domain must be the same domain that's in the message From: header. Learn how to add a DMARC record at your domain. We recommend you set up DMARC reports so you can monitor email sent from your domain, or appears to have been sent from your domain. DMARC reports help you identify senders that may be impersonating your domain. Learn more about DMARC reports. When you set up DMARC, you can then optionally set up BIMI to add your brand logo to messages sent from your domain. Learn how to add your brand logo with BIMI. ARC ARC checks the previous authentication status of forwarded messages. If a forwarded message passes SPF or DKIM authentication, but ARC shows it previously failed authentication, Gmail treats the message as unauthenticated. We recommend that senders use ARC authentication, especially if they forward email regularly. Learn more about ARC authentication.
모든 댓글 (9)
Have you contacted Mindspring about the fact Google are now refusing their emails because they have failed to correctly configure their mail server in the DNS system?
There is nothing to say the Earthlink web mail actually uses any of the same infrastructure your SMTP server you send via using Thunderbird does. I am see more and more ISP mail where is does not, and the technicians often do not even know the legacy SMTP servers are still used. I think it has something to do with most US based companies hiring Microsoft trained folks and the Microsoft proprietary systems do not use SMTP. So you need to talk to the folk that have not managed their system correctly.
Mindspring (Outlook) email is NOT being refused by Google. As I stated, IF I send an email through Mindspring' webmail page, it goes through.
IF I send the same email to the same address via Thunderbird, it does NOT go through, it gets kicked back with the error message as stated above. Thunderbird IS sending it through Earthlink's perimeters and settings, so it is not going through any other mail server. How is it then that Earthlink, using SMTP still can send my email through, but Thunderbird using the same SMTP, can't?
If Mozilla no longer plans to support Thunderbird, Let me know NOW.
You are misunderstanding Matt's helpful comments. SPF and DKIM problems are with the email provider's server setup. This problem is not being created by Thunderbird and cannot be fixed by Thunderbird. You need to notify Mindspring of the issue. We have seen recently that other email provider's emails are being rejected for the same reason and it appears that Google is hardening down on security.
Tell me them, How is Mindspring going to change settings for Thunderbird to work, IF it already works with their webmail? I will contact them, but what if they simply say "Hey, it works with our webmail!" What exactly do THEY have to change to get Thunderbird to work?
There are several internet sites that explain the techniques for that. It works for their website because they know they own the server. But Google does not own their server and Google looks for ownership information on the server. Try to access the same email account with another email client and you will encounter the same error. It's not Thunderbird.
OK I appreciate hearing that it won't work on other email apps...Saves me the trouble of trying. I'll contact Earthlink and tell them to ficxi it,
Thanks
To begin gmail is increasing its authentication processes for sound logical reason, ie, protecting against scammers pretending to other than who they are. Hence, Verisign explained it me along the lines: any reference to an email address needs a current SPF, DKIM or DMARK record or domain. If it has such it can be verified by google/gmail. Verification requires proof of ownership of the underlying domain, ie, bit to the right of the @. Verifying requires a TXT record, which requires the appropriate DNS for that domain. If you using only an ISP email, then that ISP is responsible for verification, on the other hand if the client owns the domain, it isn't the ISP that is responsible it is the client. Maybe in this example Thunderbird is generating an intermediary into the authentication process prior to the ISP, hence could be leading to the authentication challenge, ie, a mismatch between, say the sending and recieving DNS.
cyclonecomputer said
Tell me them, How is Mindspring going to change settings for Thunderbird to work, IF it already works with their webmail? I will contact them, but what if they simply say "Hey, it works with our webmail!" What exactly do THEY have to change to get Thunderbird to work?
They have to fix the DMARC setting in DNS to identify the server as a legitimate sender of mail when Google probes the DMARC doing a reverse DNS to ensure the sender is sending from an authorized server for that domain it is getting back that it is not.
Unfortunately your provider might not actually employ anyone competent enough to fix the issue. They certainly will not be working a support phone if they do. You will nee to get the issue elevated to an actual engineer that knows about DNS and DMARC.
The person who answers the phone is paid to read scripts and get you off the phone in the least time possible. Resolution is not in the financial equation that goes with free support. That is why they go can you send from web mail, then all is good. Because that is what the script says to tell you.
I'm not an Mindspring (or Thunderbird YET have raised another thread about that) client, just getting the same issue with my ISP and gmail. Works fine through their webmail but fails from my email host via ISP to all gmail accounts. In my case it is the host, so I've suggested, no more than that, it might be Thunderbird. My non guro thought is, as mindspring.com is the failure, the bit to the right of the @, it is the owner of the second level domain, ie, mindspring... that is responsible for the verification, and hence all the individuals to the left of the @