0

We seem to be having issues with the delivery of our outbound emails to some of our clients. On one of our sites, we allow our recruiting agents to send notification emails "from" their user email address. We believe the issue however, is that it originates from our domain and as a result, the return-path and authentication results may be causing us issues. When I test sending email notifications to my personal gmail account, everything works fine but sending to a corporate email server faults.

Example Scenario:

Agent A logs into their administrative portal at www.aabbenefits.com. Agent A wants to send prospective Agent B an recruiting email directly from their portal. The email sent to Agent B appears to have come from Agent A (but is of course delivered from our primary domain).

Email Header Info

I have listed the header response below we currently get in a test message.

Delivered-To: [email protected]
Received: by 10.216.139.151 with SMTP id c23cs429993wej;
        Thu, 5 Aug 2010 08:31:31 -0700 (PDT)
Received: by 10.142.171.9 with SMTP id t9mr9154707wfe.321.1281022287144;
        Thu, 05 Aug 2010 08:31:27 -0700 (PDT)
Return-Path: <[email protected]>
Received: from 2associationconcepts.net ([70.32.82.104])
        by mx.google.com with ESMTP id o5si530238vcr.71.2010.08.05.08.31.26;
        Thu, 05 Aug 2010 08:31:26 -0700 (PDT)
Received-SPF: neutral (google.com: 70.32.82.104 is neither permitted nor denied by best guess record for domain of [email protected]) client-ip=70.32.82.104;
Authentication-Results: mx.google.com; spf=neutral (google.com: 70.32.82.104 is neither permitted nor denied by best guess record for domain of [email protected]) [email protected]
Received: (qmail 22483 invoked by uid 48); 5 Aug 2010 10:31:26 -0500
Date: 5 Aug 2010 10:31:26 -0500
Message-ID: <[email protected]>
To: JAY MARSTON <[email protected]>
Subject: AAB New Agent Recruiting Information
From: ASSOCIATION CONCEPTS LLC <[email protected]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="d94d4ba462f3db34d24b86cf5afb45b9"

Content-Transfer-Encoding: 7bit
This is a MIME encoded message.

--d94d4ba462f3db34d24b86cf5afb45b9
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

Any ideas how to resolve this issue?

Improve this question
4
  • 1
    Do you have a bounce message?
    – David Mackintosh
    Aug 5, 2010 at 15:48
  • 1
    The bounce message/headers from a failed mail would be much more useful in troubleshooting than those from a successfully sent message.
    – Zypher
    Aug 5, 2010 at 15:52
  • The thing is - we dont get any bounce messages at all. From our perspective, the emails are delivered successfully but they never show up in random circumstances (almost always when sending to a corporate email domain)
    – JM4
    Aug 5, 2010 at 15:53
  • mail delivery logs would also be useful.
    – Mike B
    Aug 6, 2010 at 22:50

1 Answer 1

Reset to default
0

Based on your description and comments I believe you are right in thinking that it's because of differing domains. This is a common spam indicator so it's likely that spam filters are catching your messages and dropping them without a bounce.

To confirm this you can try to contact an admin at one of the companies that is affected, or have the user try and get in touch with them internally to say they're not receiving mail. They'd be able to confirm that their filter is catching your messages.

Improve this answer
2
  • I agree, unfortunately, the people we work with are completely incompetent and most don't even know their tech providers (let alone how to even check their spam inbox) so we aren't getting much feedback from them other than "it doesn't work" - any way to test on our side? We do not get emails returned but perhaps it sits in a log on our server?
    – JM4
    Aug 5, 2010 at 16:01
  • @JM4 No, not really. If you're not getting a bounce or any kind of NDR then the remote MTA's are most likely happily accepting the mail and your own internal tests won't show anything different. Typically what happens at that point is the remote MTU sends the message on to the filter and the filter does its thing, whether that's just flagging it as spam and forwarding to the client to figure out what they want to do, or just dropping it altogether. Unfortunately you can't see that part from the outside. If there's no response from the remote MTA then you won't have it in your log either.
    – squillman
    Aug 5, 2010 at 16:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .