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.
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'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!)
I am developing the application that receives emails from the different users and processes them in some way.
For this purpose, I started to use Amazon SES service. According to the documentation, I verified my domain (set up MX record, added email-smtp.us-east-1.amazonaws.com and so on). Also, I set up the rule for processing received an email (it is lambda function). I didn't add any IP Address Filter so it has to receive emails from all sources.
Now, I trying to send the email to a random address on my domain (for example, admin#mydomain.com) from my Gmail account. But my message isn't delivered and response from the remote server is 530 Authentication required.
I googled my error and saw only issues related to sending emails.
What have I missed with receiving email on AWS SES?
EDIT:
This how my records look. Name fields are mostly empty because system skip my domain name (for example: change _AMAZONSES.mydomain.ext to _AMAZONSES).
I am creating a webservice with Mailgun to send out emails. It will BCC my own domain's email for every email sent out. Assuming my domain is "example.com". For every email sent out to a customer, say, customer1#gmail.com, I will BCC its content to sales#example.com.
Currently, the domain example.com and its email is hosted on a server with CPanel.
In Mailgun, I have added and verified the domain example.com. Using this domain, I've sent a mail to customer1#gmail.com and sales#example.com. The email is sent without issues to Gmail, however when sending to sales#example.com, I keep getting the error Server response: 550 550 Verification failed for <bounce+e0f051.e0179a-sales=example.com#example.com> No Such User Here.
What's baffling here is that if i send the email via Mailgun with another verified domain such as anotherexample.com, and then using this, I send my mail to sales#example.com. The email arrives perfectly fine without errors.
So far, the things I've tried:
Added Mailgun suggested SPF and DKIM
Modified SPF to include my CPanel server's IP (together with Mailgun SPF)
Deleted both the SPF and DKIM (one at a time and both at once)
Verified that the email sales#example.com exists. Using the CPanel webmail's interface, I can send and receive emails just fine.
Tried updating the CPanel MX entries Email routing from Local -> Automatic -> Remote. ("Local" works the best. If its set to "Remote", email sending and receiving doesnt work at all, even if mails are sent through Gmail/Hotmail).
My current MX settings are:
Priority 0: mail.example.com
My current Zone file records on CPanel:
example.com A <some ip>
mail.example.com A <same ip as above>
The code I am using to send mails via Mailgun (Ruby):
mg_client = Mailgun::Client.new 'xxxxxxxxxxx'
message_params = {:from => from_email,
:to => customer.email,
:bcc => bcc_email,
:subject => MessageTemplate.email_subject,
:text => message}
result = mg_client.send_message('example.com', message_params).to_h!
I currently do not have the SPF and DKIM records in the zone files. I've added and removed them and they had no effect on the error (still delivers fine to Gmail too).
I've spend the whole on this, scouring forums and whatnot but can't seem to find a solution.
If at all relevant, I have a 301 redirect of example.com to www.example.com(Which has a CNAME pointing to another server). But I've researched and found out that 301 redirect does not affect emails.
I don't think this is a send-side problem. You're sending to sales#example.com, but you're getting errors relating to bounce+e0f051.e0179a-sales=example.com#example.com, which is a typical VERP address. Now, VERP addresses are fine, so long as you're expecting them. Given that you are not apparently providing that explicit address to MailGun, I assume that they are generating that address automatically. I would check their documentation for how they generate return-path (envelope sender) addresses, and either override the sender address (with just sales#example.com), or configure handling of those VERP addresses on your own inbound mail server.
Here is a mailgun explanation
This error occurs due to what is termed Sender Address Verification (SAV). During SAV, an email server performs an MX lookup upon the domain (example.com) listed within the message envelope's Mail-From field. SAV typically rejects the message if,
the sender's (in this case, Mailgun's) MX records are not configured for that domain AND
the domain of the message envelope's Mail-From field does not match the domain of the message header's From field.
https://help.mailgun.com/hc/en-us/articles/360011804533-Sender-Verification-Error
I am using mailgun to send mail and am receiving this error message:
550 Requested action not taken: mailbox unavailable invalid DNS MX or A/AAAA resource record
when I send mail to certain domains. An example of a problematic domain is web.de
Sending to other domains via mailgun works just fine and in fact I am able to send mail to the problematic domain just fine from my own account (gmail).
In terms of DNS records, Mailgun indicates that my domain has been verified using TXT DNS records.My MX records point to another email provider that I am using to receive e-mail.
In case anyone was following this, it turns out the solution is to add MX records in your DNS to identify the Mailgun server. These are the records you'll want to associate with the subdomain mg.yourdomain.com:
mxa.mailgun.org 10
mxb.mailgun.org 10
The idea is that certain email servers do an MX lookup on the domain of the sender of the email (in this case mg.yourdomain.com). If those MX records do not exist, the server will reject the mail.
Note: in my case I already had separate MX records associated with my base domain (yourdomain.com) which were pointed to a different email client (not mailgun) that I was using to receive mail. So I was initially confused as to how/why I needed to add others, and whether it was valid. It turns out it is indeed valid (and this case, necessary) to have separate MX records for separate subdomains.