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
Related
I want to point my MX records from my existing server (Hostgator) to Google mail, to receive in Google my new emails. If I don't delete the email addresses that I set up in Webmail, can I still access my old emails stored there, or will they be lost when I change the MX records in the DNS?
If you don't delete or cancel your eMail service with Hostgator then your existing eMails should remain in your Webmail account.
I'm guessing as I don't use Hostgator that you access your webmail via an address like webmail.yourdomain.com or directly via the Hostgator webmail (again a guess). If you use webmail.yourdomain.com then just leave this entry in your DNS and you will be able to continue accessing it as you do now once you change your MX records to Google.
Depending on how much mail you have in your current Hostgator account you could look at using Mailbox Imapsync https://imapsync.lamiral.info/X/ which will allow you to 'move' your eMails from Hostgator to Google Mail.
I've used ImapSync a few times and it works well but I have not tried to send anything to Google.
If you do try it with Google please let me know if it works for you.
Suppose I own an email 'demo#gmail.com'. Now, I create a new Microsoft account using my existing email. Thus I get another email 'demo#gmail.com', but this one is served by Microsoft.
So the situation is: one email and two providers.
If I send a hello email to 'demo#gmail.com' using my personal SMTP server, to which of the above will it send: will it send to the one hosted by Microsoft or the one hosted by Google?
How does it solve such an ambiguity? What are the factors that influence this?
This is a very common problem because many providers are giving us an option to create a new account using our existing email.
My observations:
I saw the emails inside the inboxes of both the services. I found that they had completely different emails.
There was no email which was common to both the inboxes. So there must be some mechanism to deal with it.
Let us look at the problem the other way round: If I had an email 'demo#outlook.com' initially and I created a new Google Account with this email address, then:
An email sent to this email address from another gmail account goes to the Google's server. An email sent to this email address from an Outlook also goes to the Google's servers.
There are two different ways of looking up an email. The 'normal' way:
You send an email to an server, in this example gmail.com.
Your mail delivery agent looks for mx record of gmail.comand send it to the ip-address of gmail.com.
If an email is delivered locally by the domain outlook.com it perhaps doesn't lookup the mx record, but lookups in a local database if the email-address exist there, and sends it to the ip-address of the outlook.com.
I think in the inbox of outlook.com are only microsoft emails.
More details can be found at https://www.socketlabs.com/blog/smtp-email-delivery/
since a few days our internal email info#ourdomain.com seems to go bananas and sends out emails to all sort of email addresses. Some of those emails bounce and we receive Mail Delivery Failed emails every minute.
Here is our setup:
Domain hosted at Germany's 1und1 provider
Nameserver configured on Amazon Route 53
MX server mx01.kundenserver.de and mx00.kundenserver.de
Rails application hosted on heroku
I called the support at 1und1 and they told me to set a SPF record which I did:
"v=spf1 a mx ~all"
after researching the topic via http://www.spf-record.de/
Unfortunately this did not resolve the problem.
Honestly I am cluesless now what to do to prevent this random email sending.
Our account could have been hacked but the password was already changed.
Any of your email account or script/code compromise can cause outgoing spam emails. If outgoing emails are originating from particular email account and you find large outgoing email account from particular email account, you should consider to reset the password of that email account immediately. Also, compromised email sending script/code can can cause outgoing spam.
If "from" email address on spam email is none of your existing account then "From" email address is getting authenticated from any of your existing email account for which you should inspect SMTP logs of mail server(you should have administrative access of mail server)
Mail server IP address should not be blacklisted,please check IP here :- http://mxtoolbox.com/blacklists.aspx
If IP address is blacklisted, you can request IP whitelist after you identify and fix the outgoing spam source as RBL keeps IP address blacklisted until they find the spamming activity relaxed.
SPF and PTR record should be correct so that email recipient server can trust the sender mail server.
Bounce back email and spam email header can help to identify the issue more preciously.
This happened to me before, I had a "refer a friend" feature on my website and someone use an automated script to send emails to a ton of people. My server wasn't comprised, it was just bad coding in the feature that I installed that allowed my mail server to send mail to different people on my behalf.
Since the email is coming from you, your SPF/DKIM will check out just fine.
So thing about all the points on your website that can send email and see if any of them can be compromised.
Also you'll want to do a blacklist scan, I use this service it does more then 200+ blacklist: https://www.unlocktheinbox.com/blacklist/bl/
Make sure you scan both your domain name and IP address. But before you take any action to remove yourself, you should wait 24 hours until after you fix the exploit on your system. Requesting removal and popping up again can get you permanently listed.
I am using Amazon SES and no matter what I do it overrides the Return-Path from the mail header.
I set the Return-Path with the from email address but instead I receive something like this: 0000013c68a254c5-b4c65e38-b391-43ea-93b7-658a6e977e49-000000#amazonses.com. I guess the reason is to catch the bounce emails.
However, my main issue is that I'm getting some auto-reply emails from the MAILER-DAEMON#amazonses.com instead of being answered to the Reply-To or the From email address.
So my question is:
Is it possible to override Return-Path email address?
How can I avoid the MAILER-DAMEON#amazonses.com emails?
I'm almost certain you cannot override the return path. As part of Amazon sending email on your behalf they also need to ensure that you're not sending spam, catch bounces (including auto responders), catch complaints and so forth. One of the key methods of doing this is be controlling the return address.
The email address that they use is a unique key related to your email. When the message is returned to that address they can then use it to track that for your account. Likewise the emails that you receive from AWS as the sender are sent programatically. These will always come to your account and as part of the terms you're supposed to respond to them appropriately.
You can now change the Return-Path / Mail-From header on Amazon AWS SES.
AWS document is here:
https://docs.aws.amazon.com/ses/latest/DeveloperGuide/mail-from.html
In case the link changes, here is the section of interest that you can google quotes from to find a current link:
Setting Up a MAIL FROM Domain for a Verified Domain
You can configure a MAIL FROM domain for an entire domain. When you do, all of the messages that you send from addresses on that domain use the same MAIL FROM domain.
To configure a verified domain to use a specified MAIL FROM domain
Open the Amazon SES console at https://console.aws.amazon.com/ses/
In the navigation pane, under Identity Management, choose Domains.
In the list of domains, confirm that the parent domain of the MAIL FROM domain is verified. If the domain isn't verified, complete the procedures at Verifying Domains in Amazon SES to verify the domain. Otherwise, choose the domain and proceed to the next step.
Under MAIL FROM Domain, choose Set MAIL FROM Domain.
On the Set MAIL FROM Domain window, do the following:
a. For MAIL FROM domain, enter the subdomain that you want to use as the MAIL FROM domain.
b. For Behavior if MX record not found, choose one of the following options:
- Use region.amazonses.com as MAIL FROM – If the custom MAIL FROM domain's MX record is not set up correctly, Amazon SES will use a subdomain of amazonses.com. The subdomain varies based on the AWS Region in which you use Amazon SES.
- Reject message – If the custom MAIL FROM domain's MX record is not set up correctly, Amazon SES will return a MailFromDomainNotVerified error. Emails that you attempt to send from this domain will be automatically rejected.
c. Choose Set MAIL FROM Domain. A window appears that contains the MX and SPF records that you have to add to your domain's DNS configuration. These records use the formats shown in the following table.
Name Type Value
subdomain.domain.com MX 10 feedback-smtp.region.amazonses.com
subdomain.domain.com TXT "v=spf1 include:amazonses.com ~all"
In the preceding records, replace subdomain.domain.com with your MAIL FROM subdomain, and replace region with the name of the AWS Region where you want to verify the MAIL FROM domain (such as us-west-2, us-east-1, or eu-west-1). Note that the value of the TXT record has to include the quotation marks.
Note these values, and then proceed to the next step.
Publish an MX record to the DNS server of the custom MAIL FROM domain.
Important
To successfully set up a custom MAIL FROM domain with Amazon SES, you must publish exactly one MX record to the DNS server of your MAIL FROM domain. If the MAIL FROM domain has multiple MX records, the custom MAIL FROM setup with Amazon SES will fail.
If Route 53 provides the DNS service for your MAIL FROM domain, and you are signed in to the AWS Management Console under the same account that you use for Route 53, then choose Publish Records Using Route 53. The DNS records are automatically applied to your domain's DNS configuration.
If you use a different DNS provider, you have to publish the DNS records to the MAIL FROM domain's DNS server manually. The procedure for adding DNS records to your domain's DNS server varies based on your web hosting service or DNS provider.
The procedures for publishing DNS records for your domain depend on which DNS provider you use. The following table includes links to the documentation for several common DNS providers. This list isn't a complete list of providers. If your provider isn't listed below, you can probably still set up a MAIL FROM domain. Inclusion on this list isn’t an endorsement or recommendation of any company’s products or services.
[...]
When Amazon SES detects that the records are in place, you receive an email informing you that your custom MAIL FROM domain was set up successfully. Depending on your DNS provider, there might be a delay of up to 72 hours before Amazon SES detects the MX record.
Here is the info Amazon supplies to your question:
If you used the SMTP interface to send the message, then notifications
go to the address specified in SMTP's required MAIL FROM command,
which overrides any Return-Path: header specified in the SMTP DATA.
If you used the SendEmail API action to send the message, then:
If you specified SendEmail's optional ReturnPath parameter, then
notifications go to the specified address.
Otherwise, notifications go to the address specified in SendEmail's
required Source parameter, which populates the From: header of the
message.
If you used the SendRawEmail API action to send the message, then:
If you specified SendRawEmail's optional Source parameter, then
notifications go to that address, overriding any Return-Path: header
specified in the raw message.
Otherwise, if the Return-Path: header was specified in the raw
message, then notifications go to that address.
Otherwise, notifications go to the address in the From: header of the
raw message.
found here: http://docs.aws.amazon.com/ses/latest/DeveloperGuide/notifications-via-email.html
At the bottom of that doc ( http://docs.aws.amazon.com/ses/latest/DeveloperGuide/notifications-via-email.html ) it says
When you specify a Return-Path address in an email, you receive
notifications at that address. However, the version of the message
that the recipient receives contains a Return-Path header that includes
an anonymized email address (such as
a0b1c2d3e4f5a6b7-c8d9e0f1-a2b3-c4d5-e6f7-a8b9c0d1e2f3-000000#amazonses.com
So you won't get rid of that strange return-path anyhow.
We have custom cms that currently sits on a vendor's subdomain, such as cms.vendor.com. It sends email out as coming from user#vendor.com and it seems to be working fine (using Email Queuing + SwiftMailer)
Our vendor asked us to put in the functionality for his users to be able to select from a dropdown, 3-4 other emails address associated with them from other domains he owns. Basically we need to be able to send out emails from our server labeled as being sent from #hisdomains.com, multiple domains.
I am a web programmer and have no clue when it comes to relaying messages. How would I go about being able to send out emails from his other domains? Does he need to setup permissions on his mail servers, or do I need to get into his SMTP servers to send out?
What are some things I should look out for when it comes to SPAM and gmail trusting us?
EDIT:
Not sure if my original question was clear enough. Vendor owns three domains: mysite.com, myothersite.com, mythirdsite.com. He wants a user from our crm to be able to send emails he has on those domains. So my dedicated server will be trying to send an email out as user#mysite.com, user#myothersite.com, and user#mythirdsite.com in the FROM: header.
As long as your server is allowed to send on behalf of a domain your vendor owns, you should not have a problem; just change the From: header to something else when you send out the e-mail.
Stuff like SPF, Sender ID and DKIM have to be properly configured to allow your server to send on behalf of any domain.
See also: http://en.wikipedia.org/wiki/E-mail_authentication
Any domain where the mx record resolves to the same server will work. so user#any.domain will email the same user on the mx contingent server.
To answer your question - just make sure that the mx records in the DNS zone file for each domain name points to the same server as the domain you want to share emails on.
also dependent on server configuration (like shared or whatever) I'm assuming it's dedicated with a simple email server installed. I'm not sure on cPanel/shared servers. but possibly the same.