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
Related
I'm setting mailgun route to xx#me.com to forward an email to a server at http://xxx:7000/reply.
I tested already the email route and it's fine as well as the server is up both in browser and using curl. However sending an email to xx#me.com still nothing happens.
There is already a similar question but nobody answered:
Can't recieve incoming mail with Mailgun
There are a few requirements for handling incoming emails with Mailgun.
Your account must be verified (email/SMS message)
The domain or subdomain must be added to the account.
SPF & DKIM must be verified and have MX records configured with Mailgun's values. Details for DNS record information
Route filters configured with the recipient domain or subdomain matching. (Example: Domain "bar.com" is added to the account. The expression can match_recipient("foo#bar.com"). If a subdomain is added, then it will need to match the subdomain, e.g. match_recipient("foo#mg.bar.com"))
The error from the linked question would be due to one of the above requirements wasn't fulfilled. A rejection of "550 5.7.1 Relaying denied" from Mailgun's incoming mail servers indicates a domain or subdomain has MX records pointed toward Mailgun's but the domain does not exist within an account.
**Disclaimer I work at Mailgun
I know this is 6 months old, but since I spent 4 hours trying to figure this out, I will share my solution:
There is another cause of the 5.7.1 Relaying denied message: My mailgun account wasn't verified. I saw someone suggest this but I figured they just meant that I had to verify the address I was forwarding to. Nope, when I logged in today I saw a banner at the top saying click here to resend your verification email. I did that, it went through a text message verification process, and all immediately started working!
I know this is quite a stale thread, but I also wanted to chime in here in hopes of saving folks a few hours of their life trying to solve the "550 5.7.1 Relaying denied" caper.
For me? It was what has plagued me on several occasions. I was able to verify via Gmail > 'Settings' > 'Accounts and Import' > 'Add another email address' only after I disconnected from my software-based VPN (Private Internet Access).
[Your sigh or wince here]
Now, go get it... make it happen. ;-)
If you're using MailGun with cPanel (for example, after following this tutorial) and you're getting the 550 5.7.1 Relaying denied error, make sure you're using the MailGun SMTP credentials given after adding your domain (as opposed to your MailGun username and password as the documentation suggests). That was the origin of my own problem.
Another reason for this error code may well be that you are trying to send stuff over SMTP whereas you've indicated on the sending properties of mailgun settings for your domain that you want to use the API...
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 6 years ago.
Improve this question
I have a domain mydomain.com
I need to use this domain on multiple servers.
I have greengeeks shared hosting as well as AWS with few EC2 machines for my web applications.
mydomain.com is hosting a marketing site via greengeeks hosting and it also provides my email server.
I want one sub domain app.mydomain.com that will point to one of my ec2 instance, another subdomain appadmin.mydomain.com point to another ec2 instance, What is the best way to setup domains and sub-domains like this. (currently i am using different domain (mydomain.org) for my aws instance, which isn't elegant)
As my mail server is on greengeeks, and I programatically send email from my ec2 app server using an email id app#mydomain.com, some email clients shows warning as "cannot verify email origin" and some pushes it in spam folder, is there a solution to it, I read about MX and SPF record but I am confused how to create them and where to put them.
Thanks,
K
I want one sub domain app.mydomain.com that will point to one of my ec2 instance, another subdomain appadmin.mydomain.com point to another ec2 instance, What is the best way to setup domains and sub-domains like this. (currently i am using different domain (mydomain.org) for my aws instance, which isn't elegant)
I'm not sure what the question is about. You should be able to make an a-record for each site. One for app.mydomain.com and another appadmin.mydomain.com.
As my mail server is on greengeeks, and I programatically send email from my ec2 app server using an email id app#mydomain.com, some email clients shows warning as "cannot verify email origin" and some pushes it in spam folder, is there a solution to it, I read about MX and SPF record but I am confused how to create them and where to put them.
SPF records are made typically made in either TXT-records, or SPF-records if your DNS provider, has a specific section for this. Both should work.
TXT records are nothing more than a record, with some text in it, but it can be interpeted as a SPF record, if specified as one (see part 1).
SPF entries are a collection of trusted IPs/hosts, that a spamfilter or mailserver can use to validate a the IP adress of the sender.
In the email message header, it will always say where the email was sent from(cant be spoofed to my knowledge). A spamfilter will compare the sender to the SPF entries of the specific domain and decide weather to reject the message or accept it.
Lets look at one example.
v=spf1 include:1.mailserver.com include:2.mailserver.com ip4:99.99.99.99 include:relay.anothermailserver.com ?all
Part 1
Specifies the version of SPF that you're using. SPFv1 should be able to do the trick for you.
v=spf1
Part 2
You specify the mailservers/IP subnets that should be allowed to send from your domain.
include:1.mailserver.com
include:2.mailserver.com
ip4:99.99.99.99
include:relay.anothermailserver.com
Part 3
Specifies weather to mark message as (~)SoftFail, (-)HardFail, (+)Pass or (?)Neutral, when the sender is not specified in your entries.
The receiving mailserver decides, weather to reject or accept a message based on their own policy. Meaning that some spamproviders/mailservers will reject a softfail, and some still may accept it.
Generally a hardfail should get rejected.
?all
If you need some material on this subject, id sugest www.openspf.org/SPF_Record_Syntax for the syntax.
Also you can use mxtoolbox.com which has a great tool, that specifies the different parts of a record.
As for the MX records. The MX specifies the receiving mailserver and in which order it should try to send the messages to them.
Example
Sending a mail to administrator#mydomain.com
MX record for mydomain.com
Priority = 10 / 99.99.99.99
Priority = 20 / server1.mymailserver.com
Priority = 30 / server2.mymailserver.com
Priority = 5 / myloadbalancer.mymailserver.com
Here it will look up the MX-records for mydomain.com, find the MX with the lowest priority and send the message to that IP/Host. If it doesnt get an answear from the server, it will proceed to try and send to the next MX-entry. If the message is accepted by receiving mailserver, then the mail goes through. If no answer is given by any of the MX-entries, it will notify the sender address, that the message could not be sent.
Please let me know if i missed something.
/AG
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 4 years ago.
Improve this question
Someone is sending spam emails and is making it look like it was sent from my domain. How can i stop this email spoofing via cpanel. I read about SPF somehwhere.
Here is what my SPF in cpanel says
Your current raw SPF record is : v=spf1 +a +mx +ip4:ipaddress -all
What can i do to prevent this?
There is nothing you can do to stop them from sending email that is spoofed. You can send an email and have it look like it's coming from anywhere, and your outgoing email server (if configured to accept it, which spammers obviously would) and it will accept it. Adding an SPF record might reduce the number of those emails received by people.
You need to add (or append) to a TXT record in DNS.
v=spf1 include:your.email.domain.here -all
You can include more domains by adding another include: like:
v=spf1 include:blah1.blach1.com include:blah.blah.com -all
Hope that helps! Email is basically the most insecure protocol in existence.
You absolutely CAN stop spoofing. Have been doing it for 30+ years (before cpanel, etc.).
Regarding spoofing-- require all your users to authenticate before sending, this is the easiest way to stop spoofing on sendmail (see below for difference between spoofing and forgeries). If you are trying to block forgeries there are tools in the CPANEL (WHM) interface for require FQDN, EHLO, DKIM, etc. and other settings that will help you with this.
Also, check this thread out: https://www.webhostingtalk.com/showthread.php?t=669800
For more info on how to stop it on non-cpanel systems, continue reading. The concepts will help you understand what to change on cpanel systems as well.
The key rule to fight spoofing is that no email going through your MTA that is not on a "trusted" (e.g., internal) network should be allowed to have the sending and receiving domains be the same. Alone this will stop all spoofing. Once this rule is in placed, you add 2 more rules. The first says that internal "trusted" networks are exempted from this rule (thereby making external networks affected). The second rule is that any external connection that authenticates (username/password, etc.) is exempted from this rule. That allows your traveling sales team to send/receive email through your corporate server.
With sendmail you must require all connections to send a FQDN and that all FROM/TO address be fully qualified (so you can check the domain part).
In sendmmail.cf:
PrivacyOptions=needmailhelo,needexpnhelo,needvrfyhelo,restrictqrun,restrictexpand,nobodyreturn,authwarnings
By default in Sendmail 8.9 and later relaying from any network that is not considered "localIp" is denied via the checkrcpt() routine. So external email should only be "inbound" (unless being authenticated) and it should not have a sending domain matching your domain (unless authenticated).
Forging vs. Spoofing
There is a lot of confusion about "forging" and "spoofing". Forging is when someone sends an email claiming to be from one domain but they actually are not (such as someone pretending to be paypal). Spoofing is when an email outside of a network (e.g., outside of a business firewall) is sent to someone inside the network and both the sender and recipient have the same domain. This should never happen without the outsider being required to use authentication to bypass rejection. The reason is, that if you control an email network nobody outside your network should be originating email on your behalf without you knowing about it. If you know about it then there are various ways to adjust settings to allow it. But adjusting MX, SPF records etc. to stop spoofing is wrong. That is for identifying and stopping forgery.
Before we talk about solving spoofing in more detail, the best way to block forgeries is:
require EHLO with fqdn verify sender PTR record matches and
if not verify SPF It would be nice to use Domainkeys/DKIM, but the RFC
states that if Domainkey/DKIM can't be valided you are supposed to
treat it as thought it isn't there (so invalid DKIM should be
ignored)... frustrating. If you do decide to block emails with
bad/missing DKIM you will block almost everybody using ON365 as it's
almost universally misconfigured.
Use your access map to block foreign countries, etc., from which you
never expect to get email
Update your firewall to block networks you know are a problem.
I have learned a lot over the years with some hard lessons as I have administered email for some of the largest clusters/networks/providers in the world and some of the most well known dot-coms. Email is not an island unto itself. It is requires a tight integration with your DNS and firewall team and basics such as split-horizon DNS, DMARC, DKIM, SPF and good clean A/PTR records are critical to help manage the flow and authentication of valid email. Do not allow anybody from the outside to connect to port 25 to relay email (unless authenticated). Only internal users should be able to send OUT and external users be able to send IN. If someone inside is sending to someone inside, then they are connecting on the internal mail-servers port 25 and it is "trusted".
The best configuration works like this (does not matter what your MTA):
mailserver is inside a physical firewall.
barracuda or other anti-spam server is also inside firewall or dmz.
port 25 into your mailserver is blocked from the outside, but
allowed to your anti-spam/spamfirewall device
your MX tree is set up so that your mailserver is the primary, but
because it is not reachable from the outside, everybody will fall
back to your secondary (which is your anti-spam device).
Only your anti-spam device or internal-trusted systems should be
allowed to connect to your mailserver directly.
Use your firewall to prevent any internal system from sending email
outside directly (unless you have a very good reason) and force them
all to go through your internal mailserver to get outside (this is
the number one way to prevent spam on the Internet and every ISP
should do it)
Also, if you are using exchange, this will break inbound email because exchange needs more MX detail SOOOO (and it's a good idea anyway), you need to create a domain-level MX to your mailserver at the highest priority, but you ALSO need to create host-level MX, as follows (exch01 is your primary mail server):
# IN MX 10 exch01.mydomain.com.
# IN MX 20 barracuda.mydomain.com.
# IN MX 30 tertiary.externalmxprovider.xyz
exch01 IN MX 10 exch01.mydomain.com.
exch01 IN MX 20 barracuda.mydomain.com.
exch01 IN MX 30 tertiary.externalmxprovider.xyz
barracuda IN MX 10 barracuda.mydomain.com.
Make sure this information is advertised both internally and externally in your DNS.
I also recommend using your spam firewall as an outbound relay for your corporate email so that you can prevent from sending spam going out (in case an employee's computer get's compromised). Just configure your internal mailserver to use the anti-spam device as your "smart relay" for outbound mail.
If you need help doing this please let me know. Happy to help. I'm happy to help with any email, dns, or firewall configuration issue (dmarc, dkim, spf, etcx.)
David
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 9 years ago.
Improve this question
We have a domain name(for instance example.com, register at GoDaddy ), and now we'd like to use our own custom email address (for instance contact#example.com), but we are not intend to manage the Email server related stuff, we just want to forward the inbox mail to Gmail or Outlook .etc account.
So someone write a email to contact#example, then we can check it within Gmail or Outlook.
How to configure all above stuff? Any complete tutorial can offer help?
With whom did you register your domain name? The ease/difficulty depends on this. The steps that follow assume your DNS registrar offers email forwarding. If they do not, the steps would be too involved to discuss here.
Incoming mail:
STEP 1. Arrange for your DNS registrar to forward your emails to Gmail
Even if you want Gmail to handle this domain's mail, the emails still need one of your DNS registrar's mail servers to reroute them. All this mail server will be doing is rerouting gerald#example.com to jerry#gmail.com, but without it, you'd be blindly sending emails to gerald#example.com to Google, and Google would not know to which of its users the mail is intended.
The short story is: log on to your DNS registrar's website and look for an "email" or "email forwarding" section where you can specify that you want forwarding enabled, and to which Gmail address(es).
STEP 2. Change the DNS registrar's MX Record to point to your DNS registrar's mail server
You might then also need to set the "MX record" for "example.com" to point to your DNS registrar's mail servers. It is likely your registrar will set this up for you, or at least provide instructions, when you configure your email. See, people who send you email will send it first to your DNS registrar, who will forward the emails to Google.
GoDaddy.com Help pages re: setting up Incoming mail Forwarding:
I gather you registered your domain with godaddy.com - they have a tutorial on how to set up mail-forwarding on this webpage. The tutorial seems fairly good. I do notice one confusing step: you should literally use 'smtp.secureserver.net' as the mx record, they make it seem like it's just an example. 'smtp.secureserver.net' is actually GoDaddy's server, and the article doesn't make that very clear.
If you want to see a walk-through, some fellow even made a video tutorial last year.
Outgoing mail:
STEP 3. (Optional) Log in to Gmail and change your reply-to address
You hardly need to worry about outgoing mail. This is because the email protocols let you choose any old "reply-to" address you wish. In other words, I can send you an email from "sjobs#apple.com" or any other email address, and all normal email clients will show that as the sender's address when they receive emails from me.
So, once you have your incoming mail set up, you may wish to tell your Gmail account that your outgoing emails should appear to be sent from 'gerald#example.com'. You can do so by visiting this section of your Gmail account settings:
"Settings" > "Accounts" > "Send mail as:"
Hope this helps!
I am helping a friend set up a website at Drupal Gardens. The domain is www.fromtheheartyoga.com. Previously the site was hosted at Modwest. While at Modwest I set them up with gmail/Google Apps for business (free version), so they could use the #fromtheheartyoga.com emails with gmail.
A few days ago I moved hosting from Modwest to Drupal Gardens. In order to get the domain working correctly I had to set up a CNAME record at DirectNIC (the domain provider) to point the domain "www.fromtheheartyoga.com" at the Drupal Garden site "fthy.drupalgardens.com". In order to do this I had to upgrade the DirectNIC account to a hosted account.
When I created the CNAME record, email stopped working. I later went in and updated the MX records at DirectNIC with all of the relevant Google Mail MX information. Email still didn't work. DirectNIC sait it could take as long as 48 hour for these changes to propagate. Thing is, when I updated the CNAME record, the domain began pointing to the new hosting environment almost immediately. Not so with the email.
That was Friday. As of today, none of the email addresses using the #fromtheheartyoga.com (gmail) have received any email. Every email I send from another account disappears into the internet. For the emails I send from my personal gmail account, I occasionally get a transfer update which includes, among other things the note that "The recipient server did not accept our requests to connect".
I can still send from the #fromtheheartyoga gmail account. Replies to emails sent from there also disappear.
I have had no luck with Google searches, unless the answer is right in front of me and I simply don't know enough about the issue to recognize it. Likewise here at StackOverflow. Any insights would be greatly appreciated
-John Winkelman
For compatibility reasons, you can't put a CNAME in the root domain; doing so will break email.
Use an A record instead.
Just make an A record for fromtheheartofyoga.com. The old BIND4 CNAME for a domain directive really wasn't right even back then. It's just more records to edit should you move again, who cares.
Edit to add: I don't know whether you get a definite IP address with your hosting service, you would have to know that for this to work.
Regards,
Brian in CA