none
Destination Domain Not Existed when sending mails to domains with MX record mail.global.frontbridge.com RRS feed

  • Question

  • Hello! I am a Technical Support from a hosting company in Malaysia.

    Recently, my clients have reported that they were unable to send emails to their recipients from various domains, and they will receive the following reply:

     

     

    Your message has encountered delivery problems to the following recipient(s):

    xxx@datalogic.com

    (Was addressed to xxx@datalogic.com) Delivery failed after 1 attempts within 0 minutes

    Destination domain does not exist.

     

    I have done some checking, and found that the various domains are having the same MX record: mail.global.frontbridge.com or mail.global.sprint.com, which I later knew it is related to the Exchange Online. I have also tried ping and telnet to the hostname mail.global.frontbridge.com (port SMTP 25, 587, IMAP 143, POP3 110) however there was no ping or telnet response.

    Can anyone kindly assist me on this if there is anything going on, as my clients are able to send/receive mails from hosted Exchange domains recently.

    FYI, the following domains are the ones my clients are unable to send, and their MX records are pointing to the hostname mail.global.frontbridge.com:

    • altera.com
    • fluke.com
    • dancon.com
    • danaher.com
    • qualitrolcorp.com
    • ap.sony.com
    • gems-sensors.co.uk
    • gilbarco.com

    Really appreciate some help here. Please let us know if there is any other information require so I may help to provide.


    Wednesday, March 30, 2011 9:07 AM

Answers

  • mail.global.frontbridge.com is the FOPE front end and MX location for all BPOS users. As part of the BPOS suite all users get their mail scanned by FOPE (forefront online protection for exchange). Can you post the full header message so we can see what server is kicking back that message saying the domain doesn't exist? If it is a FOPE issue the client you are trying to send to would have to contact BPOS to troubleshoot.

    Jorge R. Diaz, PMP, CCNA, MCSA, MCSE, MCTS


    Senior Microsoft Consultant

    Planet Technologies, Inc.

    Check out My Blog!

    Thursday, March 31, 2011 2:44 PM
  • Optalink, I would highly recommend contacting the owner of those domains as they are not necessarily BPOS customers.  They may be FOPE customers, and, if you are unable to send to them, they can have FOPE investigate why. 

    A couple things that will help the investigation:
    1.  Full NDR headers, including which server the NDR originated from (there's a reason the NDR indicates to provide ALL the information it to an Admin
    2.  Server-side connection logs for those messages to confirm if there was any issue with your clients' server sending the messages.


    If it wasn't difficult, it wouldn't be fun, but why's it got to be this much fun.
    Thursday, April 14, 2011 7:17 PM

All replies

  • mail.global.frontbridge.com is the FOPE front end and MX location for all BPOS users. As part of the BPOS suite all users get their mail scanned by FOPE (forefront online protection for exchange). Can you post the full header message so we can see what server is kicking back that message saying the domain doesn't exist? If it is a FOPE issue the client you are trying to send to would have to contact BPOS to troubleshoot.

    Jorge R. Diaz, PMP, CCNA, MCSA, MCSE, MCTS


    Senior Microsoft Consultant

    Planet Technologies, Inc.

    Check out My Blog!

    Thursday, March 31, 2011 2:44 PM
  • Hi Jorge,

    This is the header obtain from the bounce back message saying the domain doesn't exist, but I'm not sure will it be helpful as it did not mention any servers kicking back.

    Return-Path: <>
    Received: from MODUS-INT [192.168.10.37] by smail.optalink.com.my with SMTP;
       Fri, 1 Apr 2011 10:58:35 +0800
    Received: from relay.optalink.com.my (unverified [192.168.10.7]) by modus-int.optalink.com.my
      (Vircom SMTPRS 5.0.916.3) with ESMTP id <B0000154146@modus-int.optalink.com.my> for <wjpoh@optalink.com.my>;
      Fri, 1 Apr 2011 10:58:32 +0800
    X-Modus-BlackList: 192.168.10.7=OK;=OK
    X-Modus-Trusted: 192.168.10.7=NO
    X-Modus-Audit: TRUE;30;-1;129487211126410000
    To: wjpoh@optalink.com.my
    Subject: Delivery failure (rmilstead@dancon.com)
    From: postmaster@optalink.com.my
    Message-Id: <B0022276315@relay.optalink.com.my>
    Date: Fri, 1 Apr 2011 10:58:34 +0800
    X-Modus-Audit: TRUE;5;-1;129465611149310000
    MIME-Version: 1.0
    Content-Type: multipart/report; report-type=delivery-status; boundary="270/3392/1301626714/modusGate/relay.optalink.com.my"
    X-SmarterMail-TotalSpamWeight: 0 (Authenticated)

     

    This message was also found attached on the bounce back message:

    From: "Wei Jian" <wjpoh@optalink.com.my>
    To: <rmilstead@dancon.com>
    Subject: Test Mail 10.16
    Date: Fri, 1 Apr 2011 10:16:27 +0800
    Message-ID: <005d01cbf012$ceae7b50$6c0b71f0$@com.my>
    MIME-Version: 1.0
    Content-Type: multipart/alternative;
        boundary="----=_NextPart_000_005E_01CBF055.DCD1BB50"
    X-Mailer: Microsoft Office Outlook 12.0
    thread-index: AcvwEs45Ef+W8MFoQ4eAk/J75+ytVA==
    Content-Language: en-us

    Friday, April 1, 2011 3:30 AM
  • Sorry, I am looking for the detail in the bounceback specifically, which may be in the returned message, you should have something in the message saying it was rejected by server xxx.xxx.xxx at IP xxx.xxx.xxx.xxx.

    Jorge R. Diaz, PMP, CCNA, MCSA, MCSE, MCTS


    Senior Microsoft Consultant

    Planet Technologies, Inc.

    Check out My Blog!

    Friday, April 1, 2011 2:33 PM
  • Optalink, I would highly recommend contacting the owner of those domains as they are not necessarily BPOS customers.  They may be FOPE customers, and, if you are unable to send to them, they can have FOPE investigate why. 

    A couple things that will help the investigation:
    1.  Full NDR headers, including which server the NDR originated from (there's a reason the NDR indicates to provide ALL the information it to an Admin
    2.  Server-side connection logs for those messages to confirm if there was any issue with your clients' server sending the messages.


    If it wasn't difficult, it wouldn't be fun, but why's it got to be this much fun.
    Thursday, April 14, 2011 7:17 PM