Link to home
Start Free TrialLog in
Avatar of Ryan Mignosa
Ryan MignosaFlag for United States of America

asked on

Issue forwarding email [Exchange 2010]

Recently my company changed it's hosted spam filtering solution from McAfee to Proofpoint due to the McAfee end of life.  Since the cutover some email has been refused outbound with error:  554 5.7.1 Relay Access Denied.

Mailflow example:

1. A customer fills out a webform on an external website in another domain
2. The customer's request is emailed to a mailbox on my exchange server
3. A server side mailbox rule delivers the email to the mailbox and forwards a copy to Salesforce using a mail contact
4. A record is created at Salesforce for inventory management and case creation

Problem--Proofpoint spam filter is recognizing that the email is from an external domain and immediately forwarding to another external domain which is common spam behavior so Proofpoint is refusing to send the email outbound.

Attempted fixes:
1. created an outbound filter for the sending domain in Proofpoint
2. added IP of sending server to domains list in Proofpoint
3. added IP of sending server to safe senders list in Proofpoint

Proofpoint is currently telling me this relaying of email isn't possible with their product.  They've advised that I create a new send connector and route the outbound forwarded messages to an IP that sends email to the internet and not through the spam filter.

Questions:

1.  Has anyone experienced this behavior with their spam filter solution and how did you get around the problem?
2.  Has anyone created multiple send connectors and routed email differently outbound?
3.  How would I leverage the new send connector for these specific 'Relayed' email?
ASKER CERTIFIED SOLUTION
Avatar of Tom Cieslik
Tom Cieslik
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of Ryan Mignosa

ASKER

Thank you for your input Tom.  I successfully convinced the business that their mailflow was wrong.  They've changed their process to where the webform still sends to our internal address, but with a bcc to salesfore.  Now the internal forwarding which was generating the error is no longer necessary.

Thanks again