I am using route 53 for my domain and gmail for my email client. I am routing all emails to my domain to gmails nameservers. I want to intercept a few different email addresses so they can be recieved by SES. How would I go about defining a record set to do this? Or is there another way to do this? I would like to avoid redirecting emails from mail#mydomain.com or mail-(some-random-token)#mydomain.com
Related
I'm using PHP mail() to send an email from my server to two different accounts, one which is my Gmail account, which SPF passes with, and one to an account hosted by my domain provider, which is then forwarded to my Gmail account. That causes SPF to fail because the originating IP is different.
But, there's no way to tell if the email address you send emails to is the recipient, or forwards them elsewhere. So is there any way to allow SPF to pass through any (unknown) relay?
It's unclear exactly what you mean here. Are you using arbitrary From addresses?
Generally, SPF control over email sources is handled in a few different ways:
Authorise your domain provider's servers to send from your domain (i.e. add them to your SPF record)
Hope that your hosting provider's mail servers support SRS, the Sender Rewriting Scheme, which they should
Allow any IP to be a source of email for your domain by adding +all to your SPF record (clearly a bad idea!)
When registering a domain on mailgun there is this text above the input:
We recommend using a subdomain with Mailgun, like “mg.mydomain.com”. Using a subdomain you will still be able to send emails from your root domain e.g. “you#mydomain.com”.
I have registered mail.mydomain.com
I can catch all mails comming to *#mail.mydomain.com nicely through the routes. Now I want to catch all mails sent to *#mydomain.com
I interpreted the quoted text as if that was possible, is it?
You could obviously point mydomain.com to mailgun too, however, keep in mind that Mailgun does not provide POP3/IMAP mailboxes (https://documentation.mailgun.com/en/latest/faq-mailbox-eol.html#discontinuing-pop3-imap-mailboxes).
Assuming you need mailboxes, there are different scenarios, and it depends on your use case I guess:
You could point mydomain.com to another hoster, and for the relevant emails for mailgun set up a forwarder to mail.mydomain.com at mailgun.
You can point mydomain.com to mailgun, and for emails where you need to store data, set up routes respectively (https://documentation.mailgun.com/en/latest/quickstart-receiving.html#how-to-start-receiving-inbound-email)
the answer is simple: you can't
I've got a domain myawsdomain.com on AWS through Route 53.
I have an email server set up with a different service under a different domain myemaildomain.com.
I have an email account set up for fred#myemaildomain.com.
I'd like to have an address inquiry#myawsdomain.com forward directly to fred#myemaildomain.com. Is there a way to do that with just DNS, or am I going to need an email server running at myawsdomain.com to make this happen?
You can point the MX records at any provider willing (and configured) to handle email for your domain. Most paid email hosts will allow you to point multiple domains at their service.
MX records are separate from your other records, so you can point your A at AWS and your MX at, say, Google Apps. (Note: there are special oddities with CNAMEs - they can't coexist with a MX.)
I want to use Mailgun to send/receive messages programatically via API.
BUT I need to have also some mailboxes available using Thunderbird or other mail client.
For example I want to have user mailboxes at:
support#
sales#
admin#
And all other e-mails will be for API send/receive.
I can not forward my mail to GMail because I need to reply from the same address (sales#mydomain.com).
Please help.
There is a limitation to using the routing feature and that is that if you delegate a domain to be used by Mailgun you cannot use it with an email client.
That means that, for example, if you want to route emails to user#domain.com and then still use that email address with your favourite email client (be it Thunderbird, Outlook or Gmail) you can't do it. That is because of the way you've configured your MX records (email records in your DNS).
When you use Mailgun's routing functionality you delegate MX records to mailgun, which receives your emails, parses them and routes them according to your preferences.
So how do we solve your problem?
What you can do instead is set up your MX record on a subdomain.
Using subdomain.mydomain.com and pointing its MX records to mailgun will allow you to receive and parse emails through Mailgun.
This way you can have:
admin#subdomain.mydomain.com
sales#subdomain.mydomain.com
etc
will be handled by mailgun
while
admin#mydomain.com
sales#mydomain.com
will be handled normally with your email client.
Please do not hesitate in asking more details!
You need to configure your MX record settings for your subdomains in your DNS control panel.
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.