I want to buy a g-suit mail.
I already have a domain. I want to buy an email server from the g-suit.
When I visited g-suit pricing, there was "Per User" billing details. Actually I don't know what it means.
what is per user means? is that directs to per domain?
If I want to create 20 mail id in the same domain will it count as one user or 20 users?
as I already told, 20 mail id will be on the same domain name
like user1#mydomain.com, user2#mydomain.com ..... user20#mydomain.com
In this case you need to pay 20 users.
Here I add a link with a small discount
Per-User means, if you want to make alias mail it won't consider as a user. You won't get any separate Gmail for this mail. Alias mail won't get any extra storage.
Say your domain name is abc.com and you want to create three mail and want to pay for a single user then you will create salesteam#abc.com and two other mail will be sale1#abc.com and sale1#abc.com. Then you can send mail from salesteam#abc.com for all other mail.
Gmail's official statement is:
https://workspace.google.com/faq/
Related
I was trying to sign up for a new Gmail address and noticed that Gmail has an option in which you can use your custom email address without the need for having a GSuit paid membership.
Upon filling up the details, Gmail sends an OTP/code to the custom email and upon entering the right code the user can log in using that email.
How is it possible for Gmail to just get access to an email address without even the need for entering the password?
You are creating a google account. A Google account can be associated with any email id.
If you use a custom email id, you can use all the gsuite features like docs etc from that email id, but you cannot access your email via gmail.
To use gmail on a custom domain you have to pay ( change mx servers etc also )
This is done by using MX records.
Mail Exchange (MX) records are DNS records that are necessary for delivering email to your address.
In simple DNS terms, an MX record is used to tell the world which mail servers accept incoming mail for your domain and where emails sent to your domain should be routed to. If your MX records are not pointed to the correct location, you will not receive email.
MX records consist of two parts: the priority and the domain name. For example:
0 mail.EXAMPLE.com
The ‘0’ is the priority.
The lower the number means a higher priority.
The ‘mail.EXAMPLE.com’ is the mail server to which it connects. This is different - depending on what company is hosting your email.
Outgoing email servers connect to the MX servers in order of priority.
If you use more than one MX record and both have the same priority, it picks one at random. (This in effect load balances the connections.)
Your MX records are controlled at the company where your Nameservers are pointed.
Use MX records, provided by the G Suite Setup Wizard, to verify your domain (if you haven’t already verified it) and to set up Gmail as your professional email.
After you've switched to Google's MX records, you can receive your email in your Gmail inbox or through an email client like MS Outlook.
How it works
Keep setup instructions open and sign in to your domain host in another window or tab. Your host manages technical settings for your domain.
You’ll then update the MX record settings to direct your email to your G Suite account. It’s like registering a new address with the post office so that your mail gets delivered.
If you already use email with your domain (your email address ends with #yourdomain.com), you’ll start receiving messages in Gmail instead of with your old email provider.
Read more here https://support.google.com/a/answer/140034?hl=en
I would like to know if Office365 and Google Suit provides "Alias" for email id and domain. Actually, Alias is generally used to create 2 email IDs like abc#xyz.com and abc#pqr.com and both the emails coming to the same email id.
If anyone is aware about the same then please let me know.
With Exchange Online you can register multiple domains against a single account and use them for incoming emails, but outgoing email is currently always sent from the primary address defined for a user
so (eg) if you have abc#xyz.com as the primary and abc#pqr.com as an alias, then incoming email to both addresses will be delivered to the abc#xyz.com mailbox and replies always sent from that address
Suggest adding a vote to this item to see if MS can/will address it...
I'm building an app to allow my users to send email. I want the email to originate from their domain. Currently, email is sent on behalf of my Mandrill account with their name/email used for the From header. It "works" but most of the mail is not delivering as best as I think it could.
The way I see it, one option is to use a service like Mandrill, Mailgun, Sendgrid, etc and have my users update there TXT records to verify their domains, thus allowing me to send on behalf of my users. Is that correct?
I'm wondering if another option would be to collect SMTP credentials, and then send the message via SMTP for my user, thereby preventing my user from having to log in and update their TXT records before using my app to send messages. I think it would be far easier to simply add SMTP credentials. Is this possible?
"The way I see it, one option is to use a service like Mandrill, Mailgun, Sendgrid, etc and have my users update there TXT records to verify their domains, thus allowing me to send on behalf of my users. Is that correct?"
Correct you'll want them to minimally have an SPF record that says the service you use is allowed to send email for the domain. I.e. TXT v=spf1 +a +mx inlcude:sendgrid.net ~all
"I'm wondering if another option would be to collect SMTP credentials, and then send the message via SMTP for my user, thereby preventing my user from having to log in and update their TXT records before using my app to send messages. I think it would be far easier to simply add SMTP credentials. Is this possible?"
Not really. They'll need to make sure their DNS records minimally have a valid SPF (TXT) record, otherwise the major email providers and players will either drop their messages or mark them as SPAM/junk.
I have a PHP web app that is going to send out about 1,000 emails. I would love to test the performance beforehand. Is there any kind of service that provides dummy email addresses to send to, for this kind of testing? I can't find anything that's not just a general bulk-email service. The key here is I just want dummy addresses to send to.
If you have the ability to just purchase a domain name from a hosting service, I know at least 1&1 gives you like 2500 email addresses per domain so you could literally spam yourself to death and not worry about any other 3rd party. You can pick up a domain name for like
When you say "test the performance", do you mean you want to know about your deliverability rates, or how your emails look?
Deliverability Rates
This is entirely dependent on your SMTP server and the reputation of the IP that it will be sending from along with your domain's SPF records and the content of your email. To maximize this, I would recommend using a marketing email service such as MailChimp or MadMimi.
Appearance of Emails
You could always just send yourself a test email to see how it looks. An alternative is to use a service like PostageApp that has a built in template designer that has both an easy email preview function and a test send email function.
(Full Disclosure: I am the Product Manager of PostageApp.)
If you use "Post Hoc" you can send email to an unlimited number of email addresses. Post Hoc acts like an SMTP server, and receives the email messages that you are sending, but it does not forward them on anywhere. You do not need to set up any email inboxes ahead of time, so there is no problem if you have 1000 different unique email addresses. They do not need to be from a single domain -- you can use any email address you want. It stores the email messages received so that you can inspect them if necessary. You would run it locally so that there is no concern about network problems, and it is very low overhead since it does almost no processing of the email. This way, the performance measure will be mostly the sending side processing. Best of all, it is open source and freely available:
Find it on GitHub: GitHub for Post Hoc
Also see the blog post: PostHoc: Testing Apps that Send Email
Given multi-tenant application, How are vendors implementing email notifications from an email account setup and programming perspective:
Sending emails could come from a generic account: eg notifications#VendorName.com or noreply#VendorName.com, this seems reasonable considering reply addresses and lilnks can be contained within the email contents.
Receiving Emails: How would an application receive email, for instance; to generate support tickets or assign comments in an email to a project/task. I have seen ID's within the subject and some reply to addresses containing the account name eg: notifications#AccountName.VendorName.com
I realise one can programatically connect to a pop3 server and receive emails and look for the IDs with the subject, but is there a way of setting up and receiving email to a single pop3 account from multiple sub-host name email addresses (not sure on terminology there) eg: noreply#AccountName1.VendorName.com or noreply#AccountName2.VendorName.com and check the Account Name from the address? (similar to checking subdomains on a URL)
Any practices, experience, comments or sughestions?
(not sure its relevant, but using C# asp.net-mvc and services etc)
For sending notification emails, we have a notification send to address associated with each account and simply send from our domain to that address. Our from address is monitored and replies end up in the CSR work queue.
For inbound emails, we use FogBugz (from the makers of Stack Overflow) for case tracking. That accepts new cases via email (e.g. cases#mycompany.com). Tickets are auto-created from the email. My only complaint there is that the customer needs to check an obscure link for case updates (no "my cases" web portal, but maybe that will come out in an upcoming version of FogBugz).
We have a custom field in FogBugz to indicate the customer the ticket is from. We could theoretically write a plugin to FogBugz that auto-assigns that using the senders domain, but I guess the CSR's haven't complained loudly enough yet :-)
We (at muHive) are an inbound email/social conversations management product. If you are looking at a handling inbound email or social media conversations from customers, we have an impressive toolset.
For our own outbound needs, the simplest way is to use an Email sending API. Don't bother with SMTP sending by yourself. We use Amazon SES and have also tried Sendgrid which gave us additional benefits like delivery status and email parsing.
There are two ways in which you can handle multiple accounts to a catch all email address. If your target system can differentiate between different customers and assign tasks to the correct representatives based on either the content/sender, ask all your customers to send an email to support#company.com.
As you rightly said, you could also create *accountName_support#company.com* email addresses and use different accounts on whatever CRM/Support solution use to manage these emails.
Another approach is to have your customers send you an email to support#company.com and you use a rule based system (like muHive) to forward these mails to the appropriate account executives based on the customer/account who sent the mail.