In my Mailchimp account I successfully verified my domain and I also authenticated it with valid DKIM and SPF records (the domain is only an example):
When sending campaings I set the From address to be info#mywebsite.com.
But headers of received email (Gmail) show:
from: info#mywebsite.com
reply-to: info#mywebsite.com
mailed-by: mail70.atl91.mcsv.net
signed by: mywebsite.com
Is it possible to show mywebsite.com also for the mailed by header?
mail70.atl91.mcsv.net is maybe the hostname of mailchimp this is why it goes in the header of the email and gmail automatically identifies that this email is coming form this from domain and there is no way to chnage that.
In simpler words this is not possible to remove mail70.atl91.mcsv.net.
If you wish to remove it you will have to steup your own mail server which is normally not very difficult
Related
I keep getting these bounce backs, works on any other domain gmail, yahoo but not outlook/hotmail. is it me or them? I am using Smartermail with all possible settings setup ie DKIM SPF ii basically get a perfect score on https://www.mail-tester.com/web-zorml
Could not deliver message to the following recipient(s):
Failed Recipient: xxxxxxxxxxxxxxxxxxxxxx
Reason: Remote host said: 501 5.5.4 Invalid domain name [DB5EUR03FT018.eop-
EUR03.prod.protection.outlook.com]
prod.protection.outlook.com is Outlook/Microsoft's anti-snooping service. In case you didn't know, by viewing an email header, you can see the sender's IP. In order to circumvent this, Microsoft/Outlook sends your emails to prod.protection.outlook.com and then to the recipient, so if someone views the header, they get prod.protection.outlook.com's IP instead of yours. My guess is that your email provider doesn't recognise prod.protection.outlook.com as a valid domain name and thus can't send the email.
I'm trying to figure out how to send mails using the MailGun Golang API without having it sent 'on behalf of'.
This is how the From address currently looks (where foo.com is the sender's email domain and bar.com is my domain):
john=foo.com#mail.bar.com on behalf of John Smith <john#foo.com>
What do I need to do so that it looks like this instead:
John Smith <john#foo.com>
I've set up SPF and DKIM according to the MailGun instructions and everything passes as being correct. I've also used SetDKIM(true) when I'm sending out the mail. Is there some setting I'm missing or additional validation I need to do?
You need to set the sender property in the email header to the from address as well most likely.
I had this same problem using NodeMailer for a node.js project. Gmail and Thunderbird would show the from address fine but Outlook would show the from address as
emailname=example.com#mail.example.com on behalf of emailname#example.com
When I looked into the full email message header I saw that the sender: in the header was emailname=example.com#mail.example.com and the from: was emailname#example.com
we looked into the spf and dkim records at first thinking it was an issue there but they were fine and in the email header it even said spf and dkim both were passing so then i noticed the sender header was different than the from and Outlook pays attention to that where gmail and thunderbird don't care as much.
Try setting the sender header to the from value.
Here is a sample of part of one of the wrong email headers edited to match example above
Received-SPF: pass (google.com....
Authentication-Results: mx.google.com;
dkim=pass header.i=#mail.example.com;
spf=pass (google.com.....
Sender: emailname=example.com#mail.example.com
From: Persons Name <emailname#example.com>
make Sender equal to Sender: Persons Name <emailname#example.com>
To add to Dhodgin's answer:
The on behalf of message comes up if you're using a subdomain in MailGun such as mail.bar.com and the from email address is using a different domain such as john#foo.com
To fix this issue add a custom MIME header "sender" and set it to be the same as the from email address.
To add a custom header using the MailGun api make sure to add a h: prefix such as:
request.AddParameter("h:sender", "John Smith <john#foo.com> ");
Have you added an mg sub domain?
If you have added a sub-domain such as #mg.domain.com then make sure you send your emails from name#mg.domain.com
I had the same problem, as I didn't realize that I wanted to have the sender address name#domain.com but I had added - as recommended - a subdomain to mailgun: mg.domain.com.
So when I tried to send an email from name#domain.com I got "on behalf of" / "sent by" but as soon as I've used the subdomain name#mg.domain.com - the "on behalf" message is gone... stupid me...
Are you trying to send from a different domain than the one you setup SPF/DKIM on?
You can only send white-labelled emails from the domain you're authorized with Mailgun.
For those using SMTP in mailgun subdomain. Set the "From" and "Sender" parameter. eg
message["From"] = 'John Smith <john#foo.com>'
message["Sender"] = 'john#foo.com'
I'm having a problem getting emails to bounce to a specific email address, different to the From address.
A particular client requires that we send emails from a specific email address (call it contact#clientcompany.com). Our Exchange admins have created an account on the Exchange box so that we can log in and send from that address. Our Exchange server is spoofing that address / domain. This works fine.
Unfortunately the emails sent from contact#clientcompany.com are not bouncing back to us. They are presumably bouncing back to the contact account at clientcompany.com (which may or may not exist).
I've inserted a header Return-Path=kirk.broadhurst#mycompany.com with the assumption that this field determines where bouncebacks are sent. Other documents indicate that this field should never be populated by the originating SMTP system. Other websites again talk about a field called Errors-To which is apparently non-standard.
So - which field is the correct one, and what does it depend on?
Any ideas why my Return-Path is not working?
I'd really like to get Exchange to correctly bounce a message addressed to an invalid server!
update:
Continuing to dig, and my Return-Path work was only adding an extended property at the end of the header block, but Exchange appears to be still adding its own Return-Path value at the top.
Delivered-To: test#test.com
Received: by 1.1.1.1 with SMTP ...
Return-Path: <contact#clientcomapny.com>
Received: from ... ...
...
Subject: Test
Message-ID: ...
Return-Path: kirk.broadhurst#mycompany.com
According to the Microsoft.com, I cannot set the Return-Path as it is determined by the MAIL FROM - which seems consistent with what I've previously read. But now I'm stuck - how do I change this MAIL FROM value programmatically within Exchange 2007?
You might want to check if the header is correctly set. Check the headers of your email and look for:
Return-Path: kirk.broadhurst#mycompany.com
Return-Path is the correct field according to RFC (IIRC) but not all Mail Servers implement that correctly.
Out of luck ;) The sender is where bounces end up. The client should create the mailbox and forward it to your internal bounce mailbox. Only clear solution.
If a human is replying to the e-mail, and not an automated response, you may want to try using the header "Reply-To:" instead of "Return-Path:". (For example: "Reply-To: kirk.broadhurst#mycompany.com")
On our mailing application we are sending emails with the following header:
FROM: marketing#customer.com
TO: subscriber1#domain1.example
Return-PATH: bouncemgmt#ourcompany.example
The problem that we are facing is that some email servers will bounce back a message immediately and use the from or reverse path (marketing#customer.example) instead to our bounce mgmt server. We want to know if we modify in the header the reply-to to be the same as the return-path if we will be able to catch all bounces.
Any other ideas are welcome?
We are using the following documents as references:
VERP
RFC
Bounce Messages
SMTP Log Parsing to get Bounces
EDIT 1: A few more bits of information to see if we can get this resolve.
We want to know at what point the email server relaying the message will choose to use the reply-to versus the return-path. We have notice that when the first SMTP server relaying the message gets rejected it sends it to the reply-to, but when it happens after one hop it sends it to the return-path.
Let's start with a simple example. Let's say you have an email list, that is going to send out the following RFC2822 content.
From: <coolstuff#mymailinglist.example>
To: <you#example.com>
Subject: Super simple email
Reply-To: <coolstuff-threadId=123#mymailinglist.example>
This is a very simple body.
Now, let's say you are going to send it from a mailing list, that implements VERP (or some other bounce tracking mechanism that uses a different return-path). Lets say it will have a return-path of coolstuff-you=yourcompany.com#mymailinglist.example. The SMTP session might look like:
{S}220 workstation1 Microsoft ESMTP MAIL Service
{C}HELO workstation1
{S}250 workstation1 Hello [127.0.0.1]
{C}MAIL FROM:<coolstuff-you=yourcompany.com#mymailinglist.example>
{S}250 2.1.0 me#mycompany.com....Sender OK
{C}RCPT TO:<you#example.com>
{S}250 2.1.5 you#example.com
{C}DATA
{S}354 Start mail input; end with <CRLF>.<CRLF>
{C}From: <coolstuff#mymailinglist.example>
To: <you#example.com>
Subject: Super simple email
Reply-To: <coolstuff-threadId=123#mymailinglist.example>
This is a very simple body.
.
{S}250 Queued mail for delivery
{C}QUIT
{S}221 Service closing transmission channel
Where {C} and {S} represent Client and Server commands, respectively.
The recipient's mail would look like:
Return-Path: coolstuff-you=yourcompany.com#mymailinglist.example
From: <coolstuff#mymailinglist.example>
To: <you#example.com>
Subject: Super simple email
Reply-To: <coolstuff-threadId=123#mymailinglist.example>
This is a very simple body.
Now, let's describe the different "FROM"s.
The return path (sometimes called the reverse path, envelope sender, or envelope from — all of these terms can be used interchangeably) is the value used in the SMTP session in the MAIL FROM command. As you can see, this does not need to be the same value that is found in the message headers. Only the recipient's mail server is supposed to add a Return-Path header to the top of the email. This records the actual Return-Path sender during the SMTP session. If a Return-Path header already exists in the message, then that header is removed and replaced by the recipient's mail server.
All bounces that occur during the SMTP session should go back to the Return-Path address. Some servers may accept all email, and then queue it locally, until it has a free thread to deliver it to the recipient's mailbox. If the recipient doesn't exist, it should bounce it back to the recorded Return-Path value.
Note, not all mail servers obey this rule; Some mail servers will bounce it back to the FROM address.
The FROM address is the value found in the FROM header. This is supposed to be who the message is FROM. This is what you see as the "FROM" in most mail clients. If an email does not have a Reply-To header, then all human (mail client) replies should go back to the FROM address.
The Reply-To header is added by the sender (or the sender's software). It is where all human replies should be addressed too. Basically, when the user clicks "reply", the Reply-To value should be the value used as the recipient of the newly composed email. The Reply-To value should not be used by any server. It is meant for client-side (MUA) use only.
However, as you can tell, not all mail servers obey the RFC standards or recommendations.
Hopefully this should help clear things up. However, if I missed anything, let me know, and I'll try to answer.
Another way to think about Return-Path vs Reply-To is to compare it to snail mail.
When you send an envelope in the mail, you specify a return address. If the recipient does not exist or refuses your mail, the postmaster returns the envelope back to the return address. For email, the return address is the Return-Path.
Inside of the envelope might be a letter and inside of the letter it may direct the recipient to "Send correspondence to example address". For email, the example address is the Reply-To.
In essence, a Postage Return Address is comparable to SMTP's Return-Path header and SMTP's Reply-To header is similar to the replying instructions contained in a letter.
for those who got here because the title of the question:
I use Reply-To: address with webforms. when someone fills out the form, the webpage sends an automatic email to the page's owner. the From: is the automatic mail sender's address, so the owner knows it is from the webform. but the Reply-To: address is the one filled in in the form by the user, so the owner can just hit reply to contact them.
I had to add a Return-Path header in emails send by a Redmine instance.
I agree with greatwolf only the sender can determine a correct (non default) Return-Path.
The case is the following:
E-mails are send with the default email address: admin#example.com
But we want that the real user initiating the action receives the bounce emails, because he will be the one knowing how to fix wrong recipients emails (and not the application adminstrators that have other cats to whip :-) ).
We use this and it works perfectly well with exim on the application server and zimbra as the final company mail server.
I'm working on a web application. A user will create an email message that will be sent to another person.
I would like the e-mail that gets sent to appear from the user's name and e-mail address of the user on my system. And if they reply to the e-mail then it should go directly to the sender's email address.
However I am worried about the email message looking like spam to email filters along the way.
Is there a proper way to do this?
I noticed on a "contact" page on a WordPress blog that something very similar is done. The e-mail headers look like:
To: email#domain.com
Subject: [Test Blog] =?UTF-8?B?aGVsbA==?=
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
From:=?UTF-8?B?aGVsbA==?=<sender#senderdomain.com>
Message-Id: <20090207234737.39C9522802F3#web7.sat.wordpress.com>
Date: Sat, 7 Feb 2009 23:47:37 +0000 (UTC)
Return-Path: donotreply#wordpress.com
What is interesting is that the display name in the "from" tag and the name that shows up in the subject line is encoded. I do not know if this helps with the spam filters or not, but thought it was at least worth mentioning.
Also, who would receive an undeliverable notification in this example? Would it go to sender#senderdomain.com or would it go to donotreply#wordpress.com?
Basically all you need to do is set the From header to the email address of the user sending the email. The value of From is what is displayed in a recipient's email client. Most spam detection systems in place today look only at the message content, not the email headers, so you currently wouldn't have that much of a problem based on what you set the From header to.
However, there are some systems which are gaining popularity which could prevent you from sending email with somebody else's email address - most notably SPF, the Sender Policy Framework Basically, a mail server that implements SPF will check the domain of the From address of each email it receives and check with that domain directly to see if it authorizes the email. For example, if your server is mydomain.com, the email address of the user is abcdef#gmail.com, and the recipient is blah#example.com,
mydomain.com contacts example.com via SMTP to try to send the email
example.com looks up the SPF records for gmail.com
example.com checks whether mydomain.com is on the list of domains allowed to send email with the domain gmail.com
If it's not, the email is blocked
Also, I found a forum post suggesting that Return-Path is the intended destination for undeliverable notifications. Apparently that header is set based on the value of the SMTP MAIL FROM command.
Setting email fields is generally trivial, but the exact method of doing so depends on the language and framework you are using, which you don't mention. Usually it is a matter of creating a new email object, and just doing something along the lines of:
email.from = "From Name <fromemailaddress#example.com>";
You can set the specific from address to your user's, if you like, it is not at all uncommon though I personally am not a fan. You could also set the from field to something like: "Sender Name (via Your Site Name) <yourresponseaddress#example.com>".
Don't do this.
It really depends on how your mail relay is set up, but actually just don't do it. From header should contain the email address that sent the email, in your case webmaster#whatever.com. If you want people to reply to a different address, you can always use the Reply-To header. Here are some notes.
If I understand the standard (RFC 822) correctly, this is exactly what the Sender header is for (see §4.4.2. SENDER / RESENT-SENDER). Still, I'd go with a different approach and use your sites official contact address in the From header and put the user's address in the Reply-To header. Maybe add some boilerplate text that clearly states where the mail is coming from.
One further advice besides the technical stuff: don't let anonymous users use this facility, you'd become a perfect platform for spamming. Also, out of kindness, you probably want to make sure that your (registered) users know that their email addresses are exposed to the recipients.
Be aware that doing this will make spam filters more suspicious of your email. Combined with suspicious looking content your email may get filtered.
Whoever is in the "From" header will receive the undeliverable notification.
For the filtering - it really depends more on the subject and body of your message than the From address. So with that said, a couple ideas....
Use HTML encoding rather than Plain Text with simple formatting (I know there's probably an argument going the other way but in my personal experience HTML gets through more often)
Always include a footer with ("This e-mail was sent to you from ... blah blah") to identify it; if you don't want people to know it's coming from your system (i.e. really impersonated from the "From" user) then you need to find a more legit way to take care of the requirement.
If at all possible, use a real address from your system as the "From" address with the address of the user as the "Reply-To".