10 Replies Latest reply on Jul 3, 2015 8:58 AM by 6b251803a89899b5bc8c7709db4c78261ad820a5

    Mailed By em-sj-77.mktomail.com - How to Fix?

      We are having issues with certain organizations when the Mailed By doesn't reference our organization. Especially with our customers. Therefore they are not getting our emails. They are also not able to white-list us due to certain organizational circumstances.


      Could you please provide me with information to as how to fix this without white-listing.


      Thank you!

        • Re: Mailed By em-sj-77.mktomail.com - How to Fix?

          Could you expand on why you can't be whitelisted? I have a sneaking suspicion that the two situations are related.

          • Re: Mailed By em-sj-77.mktomail.com - How to Fix?
            Courtney Grimes

            Hi Alexis,


            I'm a little surprised that any mailed-by discrepancies would be blocked; more and more businesses are using services like Google Apps for Work, so there's less incentive than ever for IT teams to block based solely on that. What may be more likely, however, is how the rest of your identifying information is sent in the envelope of the email—is your domain being shown as signed-by on your outgoing emails from Marketo?


            Also, if you could provide the domain you're using for your mailings, it would be appreciated.

            • Re: Mailed By em-sj-77.mktomail.com - How to Fix?
              Edward Unthank (ETU)

              I assume this is what you're talking about (screenshot)?


              Before DKIM/SPF setup:


              After DKIM/SPF setup:


              This is from not having DKIM/SPF set up for Marketo. Once you get DKIM/SPF set up, this goes away! Here's the instructions page, and it takes some back-and-forth to get this configured: Set up SPF and DKIM for your Email Deliverability - Marketo Docs - Product Docs



              Edward Unthank | Founder, Etumos

              1 of 1 people found this helpful
                • Re: Mailed By em-sj-77.mktomail.com - How to Fix?

                  So, these have been set up for a while that isn't the problem. The problem is this part of the email:

                  Mailed By em-sj-77.mktomail.com

                  How can this get fixed.

                    • Re: Mailed By em-sj-77.mktomail.com - How to Fix?
                      Josh Hill



                      These should disappear in most email viewers if DKIM is properly setup. It sounds like it is not recognized or it is no longer working.


                      AFAIK this has some impact on deliverability, but has nothing to do with whitelisting, which is an action the target server or user makes.


                      If you send us your domain, we can look it up. or you can test this at mxtoolbox.com and look for TXT or SPF records.


                      Also visit Admin > Email > DKIM to see if this is setup. Older instances may not show an existing DKIM if you set that up.

                      • Re: Mailed By em-sj-77.mktomail.com - How to Fix?
                        Sanford Whiteman

                        Let me clarify some technical details because there's likely some misunderstanding here (not that such misunderstanding is causing the problem, but it complicates the discussion!).


                        1. Mailed By is not a standard SMTP header, nor standard SMTP terminology.  However, you will see it used in two fairly well-known places:
                          • Some mail senders (such as the PHP-Mailer SMTP library) will add the header Mailed-By to indicate the hostname of the sending server, for example webhost1.dreamhost.com.  This is actually an extremely broken approach, since (a) non-standard headers must be prefaced by X-, so it actually should be X-Mailed-By, but more important (b) it represents a security issue as the internal hostname should not be leaked to the outside world.  Enabling this header is highly discouraged.  NOTE: this header has nothing to do with your issue, but I wanted to add it for completeness because it will come up when Googling around and has confused others.
                          • Some mail clients (such as GMail) will add the annotation mailed-by (lower case) to indicate the domain that passed an SPF check for a message.  The annotation is generated within GMail based on the message's envelope sender, not copied from a header field (though we can usually derive the value from the headers, that's not where GMail gets the value).  For Marketo-generated emails, this domain is always <some-server-name>.mktomail.com.  That's because messages sent via Marketo have the envelope sender <unique-verp-id>@<some-server-name>.mktomail.com.  The envelope sender is independent of the From: and Reply-To:, which you would customize to match your customer domain.  SPF operates on envelope senders, not message headers: it's for this reason that, despite a lot of mythmaking, the SPF record for your domain is actually irrelevant for Marketo emails.  If you send from alexis@crawford.com via Mkto, the recipient's server looks up the SPF record for em-sj-77.mktomail.com, not the record for crawford.com.
                        2. As above, if you see the annotation mailed-by in a webmail client, that is almost always a good thing because it means the message passed SPF.
                        3. You can't change the envelope sender for Marketo emails.  Since they are going to come from ...@<some-server-name>.mktomail.com it is important that they pass SPF for that domain -- and they do.
                        4. Having the envelope sender domain be a Marketo-controlled domain is critical for Marketo to process second-hop bounces (bounces that occur after the recipient's server accepts a message, but before the message reaches an inbox) and other automated replies. Were Marketo to use your customer domain as the envelope sender domain, you would receive hundreds or even thousands of such messages when you send.  And this is more than just a nuisance: since they are not processed by Marketo, bounces could never update the lead's status or activity log.
                        5. There is nothing wrong with an envelope sender domain (ESD) not matching domain(s) in the message header (MHD). Nothing at all.  In the real world, they vary all the time.  Think about the volume of mail sent by marketing automation and and mass-mailing companies every day.  Now realize that the vast majority of that mail has non-matching ESD and MHD yet is totally legit.
                        6. To be frank for a moment: the profession of "mail admin" is chosen by some of the most boneheaded, self-parodically irrational and cranky IT personnel out there. I think I'm allowed to say this, having been that guy for a good 5-year stretch! (Working on GroupWise, Exchange, Notes, Sendmail, Postfix, and more.)  It's perhaps no wonder that mail admins seem out of touch, since they're working on a system that is at once highly contemporary (email is still going strong, for personal and business use, and even for teenagers -- despite the reports of its death last decade) and completely archaic (the same underlying tech from 30+ years ago).  Maybe they lose their place in the world, I dunno.  Certainly dealing with spammers, who are a much worse evil, can make you think you're always in the right.
                        7. Whatever the contributing factors, it's clear there are some mail admins (#notalladmins?) who set up anti-spam/anti-abuse policies that are downright detrimental to their own employer/client's ability to do business.  I know of admins who still don't permfail outbound messages for up to 48 hours (because I think there's a standards doc from the 80s that says you should wait that long for network conditions to clear up).  Never mind that since almost every other server will send a bounce after 2-4 hours of retries, the sender -- that is, the people working at their own company -- assumes the message has gone through.  Confusion and rage ensue.  Yet the policy stays in place unless the sender has high enough status to get it changed. And the same draconian approach goes for inbound policies, needless to say.
                        8. On the flipside, some mail admins don't know how mail (as in SMTP) actually works, so they can't tell right from also-right from wrong.  The reason they can still be "mail admins" without knowing SMTP is that messaging/collaboration/calendaring systems like Microsoft Exchange are so huge and complex that running them well is a serious technical specialty in itself.  If the company also outsources their anti-spam to a hosted service, you have the worst of both worlds: the hosted service isn't providing any personal hand-holding, the service's knobs and switches are probably too scary to play with, and so they have an "It just works" fantasy when the reality is it just doesn't work.
                        9. I mention 6-8 because, seconding Courtney, any admin who who is truly blocking all email with non-matching ESD and MHD either (a) doesn't understand the tech, (b) doesn't have their company's best interests in mind, which makes them a dangerous employee IMO, or (c) on the contrary, does have their company's interests in mind, and someone at the top has explicitly said, "We don't care about people marketing to our employees."  We've run into the (c) case when dealing with our company's partners (and our own mail admins are cool BTW!).  Despite having ongoing, multi-million-dollar relationships with these other companies, they just will not whitelist us. We've gone as far up their hierarchy as we're permitted to and it's pretty clear: the people on the ground want our emails, their IT people would be fine with it, but someone further up has said they have no interest in their employees being able to get marketing emails, not just from us, and they don't want to spend a second or a cent of the company's resources to make it happen.
                        10. OK,  to try to end on an optimistic note: are you absolutely sure that your customers are balking at the ESD (which, as noted, does pass SPF, which is all it should have to do) not being the same as the MHD?  Can you get that in writing?  As Josh suggested, can you confirm that DKIM is also passing?  It would make me a lot more sympathetic to your customer's admins if you're actually not passing DKIM (as in no signature at all) or, better yet, if you are failing DKIM (in which case your message must be considered a forgery and an admin would be remiss if they didn't block it).
                        7 of 7 people found this helpful