I am getting this message when sending Email to Gmail.
this message does not have authentication information or fails to pass 421-4.7.0 authentication checks. To best protect our users from spam, the 421-4.7.0 message has been blocked.
I have try adding SPF,DMARC and DKIM but still getting the same error message.
Related
I don't have any technical problems, but I have a question that I would like to be answered out of curiosity.
Here is my current understanding of how email works:
One of the privileges of having your own domain is that you can hook it up to IMAP/POP3/SMTP servers and use them to send and receive messages to and from "anyone#yourdomain.com". With spam being such a problem, however, the SMTP server that you use to send messages must add a bunch of headers (DKIM, SPF, etc) to each message that you send in order to prove that the SMTP server has the authority to send emails from that domain. The receiving SMTP server can cross-check those headers with DNS records that it finds to verify the legitimacy of the email message.
So if you want to send emails with your domain cheaply, you can use Gmail's "Send Mail As" feature. I followed this help article to get mine working: https://support.google.com/domains/answer/9437157
Note: I unchecked the "Treat as an alias" option during the setup.
But wait... no additional DNS configuration required? I have my domain registered with Cloudflare, and there are no entries related to Google in there.
There is this step in the setup process:
But it seems that this only for Google to prevent you from using their servers to send spam. What is stopping Google from impersonating any email address they want? Why do receiving SMTP servers trust an email from "anyone#yourdomain.com" if Google's SMTP servers have no way of adding legitimate SPF/DKIM headers?
The short answer is that nothing prevents Google from doing this, and that DMARC was created for exactly this case.
There is nothing that stops Google from impersonating any domain. However, there are things receivers can (and should) do when they receive an email which isn't send from the server indicated in the From: field.
Try sending an email from the alias you just added to a different #gmail.com inbox. You will see that it says via gmail.com behind the sender email address. But other email receivers might do more: flag this message with red exclamation marks and scam warnings, throw it into spam or even deny receiving it completely. Gmail probably has some hardcoded trust, but try doing this from your own SMTP server and the above will very likely happen.
As you say in your question, you can authorize your emails by marking gmail.com as an authorized sender with SPF (which protects against forging from other domains, but doesn't stop Google), or even sign your emails with DKIM (not possible from Gmail UI, but you can do this in some email clients or send email with a custom Python script like me; Google can't do this without knowing the key).
However, that only solves one side of the problem – authorizing legitimate email messages. But what if an SMTP server still receives an unverified email? What if they have previously received an email from the same sender which was DKIM signed? What if DKIM passes, but SPF fails?
Because the behavior in that case is largely unspecified, and also the sender wants to check if their DKIM/SPF authorizations are actually working, and if anyone is attempting to spoof them, another standard was created: DMARC. It introduces another DNS TXT record where you can say what checks are required to pass, what to do if they fail, and also what basic analytics should the receivers report to the owner of the domain.
Of all webmail client providers, Google's Send mail as is actually the most well-implemented for a variety of reasons.
First of all, how it works is not different from when you set up POP3 or IMAP using a mail client like Outlook or Thunderbird. You have to specify the domain and port where you receive emails from, and the domain and port where you send emails from. For example, Google's incoming and outgoing servers for IMAP are as follows:
imap.gmail.com:993
smtp.gmail.com:465
The Send mail as feature is a partial implementation of that. It only implements the outgoing part.
How mail clients like Outlook and Thunderbird send emails, is basically that it sends the email to the outgoing mail server, and the outgoing mail server then sends the email. Usually, outgoing mail servers will require some sort of authentication, and will allow authenticated users to only send from specific email addresses.
Gmail works the same way. The outgoing mail server is the one that has to pass the SPF and DKIM tests, not Google's servers.
No other webmail clients do this. Hotmail used to do this, but they recently removed the feature. Now, the option is very difficult to find, and they just rewrite your FROM address and sends your email from Hotmail's SMTP server, which creates delivery problems.
They don't provide you with the option to send emails from another SMTP server, because this allows people to very easily set up virtual mail servers that can send emails under a domain of your choice, but use say a typical free Hotmail account to store incoming mails. This takes away business from their paid services, because both Hotmail and Gmail sell the option to host your company emails. I'm sure Google also knows about this, but it is really awesome of them to still keep the option available to free Gmail users.
If you want to learn more about virtual email servers, you can check out this article here: https://blog.terresquall.com/2022/01/setting-up-a-virtual-postfix-mail-server-part-1/
I integrated twillio for signup user in my application. From my application twillio SMS send to User for One Time Password(OTP). If user can verify OTP then and then he can register in my App.
But Sometime Twillio give error code 30004. But I want to send SMS forcefully to user without any restriction. Is there any way to fulfill my requirement.
I also read this page of twillio for my error https://support.twilio.com/hc/en-us/articles/223134167-Limitations-sending-SMS-messages-to-Indian-mobile-devices
But I want to send SMS to user any how.
Twilio developer evangelist here.
I am guessing, since you mention the article on limitations of sending SMS to India that you are trying to send to an Indian device.
As you have read, there are a number of issues with sending to India that all follow from India's classification of services like Twilio as marketing. For this reason, you are unable to send messages outside of the hours of 9am - 9pm and if a number is on the Do Not Call registry your message will never be delivered.
If you are trying to implement two factor authentication for India then I recommend you do so using an authenticator application. You can do this using Twilio's Authy API or by generating a secret and sharing it to applications like Authy or Google Authenticator.
This is more secure than 2FA over SMS and means you do not need to send SMS and rely on delivery in India. Instead the authentication can happen between the server and the device. This is what GitHub did for their 2FA and you can read why about that here.
Let me know if that helps at all.
Error 30004 "Message Delivery - Message blocked" when Sending SMS
If a message you sent is not delivered to the end device and returns a 30004 error code, this means that delivery of your message failed because the destination is blocked from receiving this message
I have a PHP mailer that sends out auto emails to confirm registration and alerts when the customer's online number is pinged.
I have only one customer complaining about not receiving alert emails to her Knology account. She can receive the registration confirmation, but not an alert email.
Any ideas why?
I have set up my cpanel email address in Gmail under Check mail from other accounts (using POP3) and also under Send mail as (Mail is sent through: mail.mydomain.com Secured connection on port 587 using TLS)
Looking at Roundcube, I can see the received mails in there, but no sent mails - even though Gmail is sending via my domain server.
Is there a way to be able to view received AND sent mails that go through Gmail ?
Unfortunately emails do not work like that. There is no security as to where an email can be sent from.
I can send an email to anyone in the world and make it look like it was sent from you, most SMTP servers don't verify this information (hence why Gmail can send email from your domain even without your credentials).
Also, although this should theoretically be possible since it's being sent through your domain's SMTP server, it would take a lot of data to be able to store ALL mail that passes through it as associate it with every account. That's why some web email clients only store sent items for around 30 days.
Good luck with finding a suitable solution. This is why many companies use an Exchange server since it provides complete tracking of sent and received emails and disallow the use of Gmail.
I'm sending mail to a third party-service from Gmail using Google Apps Script. This third party requires the sender email address be registered with them. If the sender is not registered, an error/marketing message is sent back to the original sender.
When the message is sent from Gmail manually, it is processed as expected by the third party. When the message is sent by a script, the message is not processed by the third party and no error response is sent as described above. After adding a different gmail address as a BCC on one such message, I found the script generated message shows "mailed-by: bounce.secureserver.net" and "signed-by: gmail.com"
I'm worried GAS is impersonating the sender in such a way that the third party does not recognize the sender as a registered address. Or, the third party may be dropping the messages as spam. (http://productforums.google.com/d/topic/apps-script/tGxlioK1ejg/discussion)
Community feedback on this problem is most appreciated.
According to Google's documentation, the sendEmail() method sends an email as the user running the script. That being said, additional parameters are automatically added to the email's header, and these might trigger some filtering rules on the recipient side. There is not much you can do about that, beside using a third-party email service like SendGrid which might do a better job at ensuring that your email will go through.