I have a Google App Engine app, with two custom domains (let's say, for example, a.com and b.com).
Domain b.com is a Google App alias for a.com i.e. Under Google Apps Admin Console -> Domains -> Add/Remove Domains b.com is listed as "Domain alias for a.com".
I would like our app to be able to send email from our AppEngine app from addresses at b.com, as in me#b.com or an email alias like alias#b.com. The documentation indicates that it is possible, but it does not work as documented or I have overlooked something.
If I try to send email with the App Engine Mail api from me#b.com or alias#b.com I get the error of "InvalidSenderError: Unauthorized sender."
The remedy for this would seem to be, as the title of this question suggests, to add authorized senders under:
Cloud Console -> App Engine -> Settings -> Application Settings -> Email API authorized senders
When I attempt to add e.g. me#a.com it is added to the list of authorized senders, as expected. When I attempt to add me#b.com, alias#a.com or alias#b.com it fails.
The specific error I get from Cloud Console when I attempt to add the addresses is:
Unable to add authorized senders
You don't have permission to add these users to the authorized senders list. Learn more
Following the above link, the relevant bit about permissions would be:
... a message must be sent by ...
Any email address listed in the Cloud Platform Console under Email API Authorized Senders
...
... domain administrators of domains managed by Google Apps can add any user in their domain to the list.
If you have one or more aliases set up for your Google Apps domain, you can send email from email addresses that use the domain alias. For example, adding "xyz#domain.com" to the Authorized Senders list will have the effect of also allowing sending email from "xyz#alias.com".
The document notes that SPF records must be properly configured as the documentation indicates, and they are, namely:
$ dig a.com txt
...
a.com. 604556 IN TXT "v=spf1 include:_spf.google.com ~all"
...
$ dig b.com txt
...
b.com. 604556 IN TXT "v=spf1 include:_spf.google.com ~all"
...
Although not necessary, DKIM has been configured from all the domains, and all the MX records point to Google Apps.
Under Google Apps Admin Console -> Users -> Me -> Account -> Aliases the following are among those listed (among others):
me#b.com
alias#a.com
alias#b.com
So the question would be: What, if anything, am I overlooking here that is either a.) preventing sending from the domain aliases and/or b.) preventing sending from the alias email addresses in general? If I hae not overlooked something, what recourse may follow?
As an aside, a workaround would be to use a third party mailer e.g. Mandrill, MailGun, or SendGrid. Those are overkill, a hassle, and unnecessary complexity for what is a very simple use case on our end, so a solution over AppEngine would be ideal.
I ultimately solved this by using PostMark.
There are a number of other solid options, including SendGrid, Mailgun, Mandrilla, MailChimp, and others.
We settled on PostMark because it has an agreeable templating system and focuses on transactional email deliverability.
Related
If I have a domain example.com that is using gsuite (DNS settings at registrar has gmail cnames, spf & txt records etc) and I have another service sending on behalf of the domain (Klaviyo). Do the gmail DKIM and DMARC settings help to strengthen the deliverability of those emails sent by the other service (Klaviyo)?
To answer your question: A DMARC reject or quarantine policy helps improve deliverability for all parties that send on behalf of your domain AND properly authenticate by SPF or DKIM, in alignment with your domain.
DKIM consists of a cryptographic key pair. You publish the public key on the Internet and you use the private key to sign headers of your outbound emails. This signing is done on the sending server. So unless Klaviyo is using Google servers to relay your messages, those messages are not being DKIM signed by Google.
You should follow the instructions provided by Klaviyo here, so that the emails you send from their platform, using your email domain, will authenticate properly and will NOT fail DMARC.
Update:
Say you own the domain myexample.com, then you should publish a TXT record at the root of that domain that looks like "v=spf1 include:_spf.google.com ~all". Additionally you can add any other services or servers to this record as you see fit. You don't need to add Klaviyo to your SPF record as they will try to authenticate from the send.myexample.com domain used in the bounce address. That is what you created the first CNAME for. It redirects to an SPF (and MX) record hosted at Sendgrid. Additionally, Klaviyo will authenticate those emails using DKIM.
In order to make DMARC work, you need to publish another TXT record at _dmarc.myexample.com, if you haven't already, looking like: "v=DMARC1;p=none;rua=mailto:DMARC#myexample.com;". Then you'll start receiving aggregate reports at the mailbox you supplied. Once you're confident you've included all required parties in your authentication scheme, you can move to a p=reject policy in order to protect your domain.
Yes, DKIM and DMARC settings do help deliverability.
I assume that Klaviyo does what my company Autoklose is doing as well, and that's using Gmail API to send the email in your name. That means that they only indirectly affect the sending process and the email itself is sent from Google servers and not Klaviyo's servers.
Also, you have to be aware that DKIM & DMARC are only two of the factors in successfully delivering your email. For example, having DKIM & DMARC correctly set gets you positive points but if your domain is blacklisted, it still might not get delivered.
We would like to block a malicious user from sending our employees emails automatically through google admin api.
For example, when we notice that user hacker#malicious.com sends our employees phishing emails, we would like to block it (malicious might be very similar to our domain name).
We can't find any option how to do this on admin-sdk.
However, we know that there are options to do this manually, since when we go to Apps-> Google Apps -> Settings for Gmail -> Advanced Settings on admin.google.com, we see several options to achieve this:
Blocked senders: Block or approve specific senders based on email
address or domain.
Content compliance: Configure advanced content filters based on
words, phrases or patterns.
Routing: Routing begins once you start delivering email to Google's
servers.
Receiving routing: Set delivery routes for inbound messages, and for
messages received from internal addresses.
How can we block inbound emails with admin sdk?
There's no API to manage blocked senders list in the Control Panel. However, you can create filters for your users using the Email Settings API.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 4 years ago.
Improve this question
I have recently acquired a domain name via Google Domains. I have set some configuration to have it point at an OpenShift application via Cloudflare. Cloudflare requires me to set their DNS servers, which I did in Google Domain.
At Cloudflare, I have created two CNAME records (and nothing else). One is an alias from my mydomain.com to some.url.at.openfshit.com, and the other is from www to mydomain.com.
Yet, within Gmail Domain, I have also set an email using my domain name which is to be forwarded to a private email. But, I don't receive any emails when testing.
I am wondering whether I could have my emails forwarded properly. Is it a matter of creating a MX record at Cloudflare? If yes, with what configuration?
P.S.: I have set a MX record using instructions available here, but I get:
Delivery to the following recipient failed permanently:
contact#mydomain.com
Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the server for the recipient domain chartvibes.com by aspmx.l.google.com. [2607:f8b0:4001:c20::1b].
The error that the other server returned was:
550-5.1.1 The email account that you tried to reach does not exist. Please try
550-5.1.1 double-checking the recipient's email address for typos or
550-5.1.1 unnecessary spaces. Learn more at
550 5.1.1 https://support.google.com/mail/answer/6596 p123si522326ioe.111 - gsmtp
The MX records you're using are for G Suite accounts. You can still forward emails with Cloudflare and Google Domains, but you'll need different MX records. As Overdrivr pointed out in a comment below, you can find your MX records in the DNS settings in Google Domains. Once you're in the DNS settings page, look for a collapsible panel called "Email forward" under the "Synthetic records" section. You should see something like this
Then, make a backup of your Cloudflare DNS setup, erase all MX records and add the ones listed in your account using the number right before the mail server (e.g., 5, 10, etc.) as its priority.
It might take a few minutes for the changes to take effect. If you try to send an email right after changing the records, it's likely that you'll get a message saying that the address could not be found, but it'll have the G Suite mail server in the Remote-MTA field (aspmx.l.google.com) instead of gmr-smtp-in.l.google.com. If this is the case, just wait for a few more minutes and try again
I'm not sure if you already have a solution to this, but if you do, I'm interested in how to do it too. Could you please post your solution here if you find one ?
The bad news is, it cannot be done because the way Google Domains work. Google Domains has email forwarding, but it works only when you're using Google's DNS servers. It's the same with all hosting services or whatever they're called.
I think Google just has an email forwarding service that can forward upto 100 alias email addresses per domain to an actual email address. But the actual email address has to exist somewhere. The ones you set up in the Domains console are just aliases or forwarding instructions.
For Cloudflare email forwarding to work, you need to use the SMTP servers where the actual email addresses exist, but since Domains has no actual email service servers, the emails sent out are failing with email account does not exist. The instructions you mentioned are for the Google Apps, which have actual email/gmail addresses set up, but they cost $5/user/month.
The only solution that I can think of to get around this issue is to have our own mail server, and have cloudflare point to those, and then forward/deliver the emails from that mail server.
Hope this helps.
EDIT :
I probably didn't research this well enough before, but looks like people are getting around this issue by using a third party email forwarding service called mailgun
The actual article describing how to use it is on lowendtalk
Some discussion surrounding it is here
We currently have two domains, domain1.com and domain2.com
There are Google Apps/Email accounts for each domain.
I would like to migrate the accounts from domain2 over to domain1 so that when you're signed in to account#domain1.com you can send and receive messages from both domains.
I have done this before with my personal gmail however never domain-wide with numerous accounts.
Is it even possible to map all of the addresses like this without having to sign in to each individual account?
You need to migrate the all data (more info). The email portion of the migration (unless you use a third party tool) will be the only part that will be done at an admin level. The rest will need to be done on a user by user basis.
Once you've moved added the data from domain2.com > domain1.com, you need to delete the Google Apps account for domain2.com and add it as a secondary domain or domain alias for domain1.com. If you don't want uses to be logging in with user#domain2.com and only want them to send/receive as #domain2.com, an alias will likely be the best. Info on adding one of these can be found here.
The final step will be setting up a send as on each account so they can also send as their #domain2.com addresses (they'll automatically receive if you add as an alias). These instructions can be found here.
Good luck!
I need to be able to send emails from Google Apps (my gmail account) and from my website which is hosted on Bluehost. How do I create an SPF record that will allow me to send emails from those locations but will restrict sending emails from other locations?
Like this:
v=spf1 include:_spf.google.com a a:abc.example.org a:xyz.example.org -all
This says, include Google's SPF record (which will allow all their mail servers to send mail on behalf of your domain), and allow anything in this domain which has an A record, and specifically allow 2 other hosts by verifying their A records. Fail everything else.
For this to work, you will need to know exactly which mail servers outbound mail will come from via Bluehost. I don't know much about them, but that might be your own server, or their outbound servers. If the latter, you might also be able to use another 'include' clause to include their record so you don't have to keep up-to-date with any changes they make.
This site is a useful tool. Google offers others. http://tools.bevhost.com/spf/