none
Allow Third Party Spoofing RRS feed

  • Question

  •     Anyone know why Sender ID rejects messages from an outside company that has permission to use our domain?

    Currently our SPF record looks like this-

    v=spf1 ip4:(Public IP) mx:mail.mycompany.com a:mycompany.com mx:allowedcompany.com include:allowedcompany.com -all 

    From what I understand, this should:

    -Allow my domain's mail exchanging server as a permitted sender.

    -Check IP of sender matches our A record.

    -Allows allowedcompany.com 's mail exchanging server as a permitted sender.

    -Does a pass fail check of allowedcompany.com 's spf record. 

        Allowedcompany.com does have an spf record that is correct, so it would seem that the inlcude here is redundant if it checks the mx record of allowedcompany.com.

    Either way, when allowedcompany.com sends mail using our domain name in the sender field of the header and not the envelope, a test email to gmail passes spf check as permitted sender. However, when the same kind of email is sent to our exchange using our domain name in the header (not envelope), Sender ID rejects it. In this case I added allowedcompany.com to the Sender ID config domains to bypass Sender ID, but this did not allow the message through either. All cases gave "RejectMessage,550 5.7.1 Sender ID (PRA) Not Permitted,Fail_NotPermitted." We also tried a rule to bypass anti spam when the domain of the sender is allowedcompany.com in the envelope, but this did not work either.

    Any help is appreciated.

    Tuesday, June 25, 2019 2:56 PM

Answers

  • You would need that if you're sending mail from Exchange Online from your domain. 


    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
    Celebrating 20 years of providing Exchange peer support!

    Sadly, this was not the solution either. It does not seem that the other company uses outlook.com services to send to us. There is another IP in the chain of the SMTP headers from the other companies, main domain. Would this need to be included?

    Ex:

    Received: from MyInternalDomain (MyInternalIP) by MyInternalDomain
     (MyInternalIP) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Mailbox
     Transport; Thu, 27 Jun 2019 12:14:48 -0400
    Received: from MyInternalDomain (MyInternalIP) by MyInternalDomain
     (192.168.100.3) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 27 Jun
     2019 12:14:48 -0400
    Received: from mail.mycompany.com (Google IP) by
     mail.mycompany.com (MyInternalIP) with Microsoft SMTP Server (TLS) id
     15.0.1347.2 via Frontend Transport; Thu, 27 Jun 2019 12:14:47 -0400
    Received: by mail-qt1-f169.google.com with SMTP id y57so3058987qtk.4
            for <Me@mydomain.com>; Thu, 27 Jun 2019 09:14:47 -0700 (PDT)
    Received: from SW3PACVDW033 ([MainDomain IP of Allowed Company])
            by smtp.gmail.com with ESMTPSA id f132sm1097738qke.88.2019.06.27.09.14.45
            for <Me@mydomain.com>
            (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
            Thu, 27 Jun 2019 09:14:45 -0700 (PDT)
    Message-ID: <b388db4dbc325b55747ef15f4f97c37b2ac4a3cd@localhost>
    Date: Thu, 27 Jun 2019 09:14:45 -0700
    MIME-Version: 1.0
    From: <SpoofedAddress@mydomain.com>
    To: <Me@mydomain.com>

    This is the header from a test email from the spoofed email account that was sent to my email by the allowed company using google's services as a middleman.

    If the spoofing is legitimate, I think using DKIM in combination with SPF is a good choice.

    How DKIM works better than SPF alone to prevent malicious spoofing in Office 365

    Regards,

    Manu Meng


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    • Marked as answer by IinIT Friday, July 5, 2019 1:10 PM
    Friday, July 5, 2019 9:56 AM
    Moderator

All replies

  • Perhaps allowedcompany doesn't send from a host that is resolved via their MX record.  It's not unusual for entities to have different inbound and outbound IP addresses.  You might want to check with them or do your own testing.

    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
    Celebrating 20 years of providing Exchange peer support!

    Wednesday, June 26, 2019 4:02 AM
    Moderator
  • Perhaps allowedcompany doesn't send from a host that is resolved via their MX record.  It's not unusual for entities to have different inbound and outbound IP addresses.  You might want to check with them or do your own testing.

    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
    Celebrating 20 years of providing Exchange peer support!

    I would suggest you double check the SPF record, if possible, try adding A record for the allowed company in your SPF record. 

    For example: v=spf1 ip4:(Public IP) mx:mail.mycompany.com a:mycompany.com mx:allowedcompany.com include:mail.allowedcompany.com -all 

    You may also check and validate your SPF record in some third party websites.

    Regards,

    Manu Meng


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    Wednesday, June 26, 2019 7:58 AM
    Moderator
  • allowedcompany is using G services to host their mail services. Since they use google, the IP address varies, preventing me from setting a receive connector with a specific IP :(, would be a lot easier. The mx record resolves to Google's SPF and does a check against Google's allowed IP's and passes, or at least MX toolbox and other sites pass it.
    Wednesday, June 26, 2019 5:14 PM
  • Thanks, Manu, for the suggestion. In the time between the post and now I tried all kinds of variations for the record with no success. 

    In the end I found a fix, but I am not sure totally why I have to do this. I had to add a bypass sender ID for our own domains. Meaning, since we have a split domain with company.local internally for our systems, but also maintain mycompany.com internally to resolve site names that are external and to cut down on confusion when we host sites internally that are not exposed to the internet. I think this is what people refer to as split DNS?

    Either way, to fix the issue I put in a bypass for company.local, and mycompany.com. When I internally tried to do a nslookup of our internal mail record it forwards to the local domain and seems bypasses the .com domain. I tried putting in a local spf record for the .com, but it does not show in the nslookup for the mx of mycompany.com. If I take that record and put it into the .local domain, then an nslookup for mycompany.com shows the spf. 

    I have seen that an internal spf should not matter, but I think that is what I needed for the split name, but I need it to stop skipping over the .com domain when the lookup takes place.

    To stop spoofing, my filewall can set up rules to block header and envelope spoofing, but can be set to allow specific domains and verifies them.

    Wednesday, June 26, 2019 5:26 PM
  • All that is fine, but what I said has to be true.  Perhaps you should check the G services documentation to be sure the SPF record is properly configured for them or contact their technical support.

    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
    Celebrating 20 years of providing Exchange peer support!

    Wednesday, June 26, 2019 5:36 PM
    Moderator
  • You could be right, I just have been seeing so much info about SPF records that contradict each other, making the whole situation confusing.

    The other company spoke with Google services about the issue, and Google support told them their spf was configured incorrectly. All it had was "v=spf1 include:_spf.protection.outlook.com include:_spf.google.com ~all" (should not be an issue posting, cause that is pretty general, right?)

    They are missing the actual mx part or an "a" record, or even ipv4 record. I'm confused because from looking around, the include should check if the originating ip passes againt the included spf record and that should pass it. We also added the _spf.google.com include to our spf a while ago to allow them to use our domain name with google services. Without it, the authentication would not go through when they tried to add one of our domain accounts to their email account.

    Wednesday, June 26, 2019 6:26 PM
  • If you're sending mail using Google but from your e-mail domain as the sender, then if the same IP addresses are being used by the sending service as you posted for the SPF record, then it looks like you need to add "include:_spf.protection.outlook.com include:_spf.google.com" to your SPF record.

    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
    Celebrating 20 years of providing Exchange peer support!

    Thursday, June 27, 2019 1:38 AM
    Moderator
  • We only send mail from our domain using our on premise exchange 2013 server. We do not use any third parties when it comes to sending out email from our company. Also, this is the first time we have had a partner that was not using some type of application on our onsite servers to use our mail domain. Side note though, I do have _spf.google.com on our spf for the domain authentication to work so they can use our domain through G services, but not the outlook.com include because we do not use any office 365 or exchange cloud services.
    Thursday, June 27, 2019 1:04 PM
  • That is in conflict with your original post.  You said "allowedcompany" is doing just that.

    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
    Celebrating 20 years of providing Exchange peer support!

    Thursday, June 27, 2019 3:59 PM
    Moderator
  • Sorry, I meant that we do not use g services from inside our site. I also just wanted to point out that we do not use any external cloud protection. Looking at the IP's that are being sent from, they all resolve to google, just not the IP addresses listed on their mx record for mail senders. I think they are all the default ones that google specifies in their help info for G services. Do you still think I need to add the "include:_spf.protection.outlook.com"?
    Thursday, June 27, 2019 4:18 PM
  • You would need that if you're sending mail from Exchange Online from your domain. 

    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
    Celebrating 20 years of providing Exchange peer support!

    Thursday, June 27, 2019 5:24 PM
    Moderator
  • Gotcha, I will do some testing during the weekend and see if this is the missing piece. I would do this now, but to test it, I would have to remove the allow for the sender ID filter, and that is what got it working. Thanks again for the help.
    Thursday, June 27, 2019 6:55 PM
  • You're welcome.  Please feel free to mark responses as the answer and/or vote them helpful as appropriate.

    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
    Celebrating 20 years of providing Exchange peer support!

    Friday, June 28, 2019 4:53 PM
    Moderator
  • Gotcha, I will do some testing during the weekend and see if this is the missing piece. I would do this now, but to test it, I would have to remove the allow for the sender ID filter, and that is what got it working. Thanks again for the help.

    Any update so far?

    Regards,

    Manu Meng


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    Monday, July 1, 2019 9:19 AM
    Moderator
  • You would need that if you're sending mail from Exchange Online from your domain. 

    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
    Celebrating 20 years of providing Exchange peer support!

    Sadly, this was not the solution either. It does not seem that the other company uses outlook.com services to send to us. There is another IP in the chain of the SMTP headers from the other companies, main domain. Would this need to be included?

    Ex:

    Received: from MyInternalDomain (MyInternalIP) by MyInternalDomain
     (MyInternalIP) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Mailbox
     Transport; Thu, 27 Jun 2019 12:14:48 -0400
    Received: from MyInternalDomain (MyInternalIP) by MyInternalDomain
     (192.168.100.3) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 27 Jun
     2019 12:14:48 -0400
    Received: from mail.mycompany.com (Google IP) by
     mail.mycompany.com (MyInternalIP) with Microsoft SMTP Server (TLS) id
     15.0.1347.2 via Frontend Transport; Thu, 27 Jun 2019 12:14:47 -0400
    Received: by mail-qt1-f169.google.com with SMTP id y57so3058987qtk.4
            for <Me@mydomain.com>; Thu, 27 Jun 2019 09:14:47 -0700 (PDT)
    Received: from SW3PACVDW033 ([MainDomain IP of Allowed Company])
            by smtp.gmail.com with ESMTPSA id f132sm1097738qke.88.2019.06.27.09.14.45
            for <Me@mydomain.com>
            (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
            Thu, 27 Jun 2019 09:14:45 -0700 (PDT)
    Message-ID: <b388db4dbc325b55747ef15f4f97c37b2ac4a3cd@localhost>
    Date: Thu, 27 Jun 2019 09:14:45 -0700
    MIME-Version: 1.0
    From: <SpoofedAddress@mydomain.com>
    To: <Me@mydomain.com>

    This is the header from a test email from the spoofed email account that was sent to my email by the allowed company using google's services as a middleman.

    Tuesday, July 2, 2019 2:03 PM
  • I wanted to quote Crowley's post since I was answering that originally. Sorry, if this makes the layout confusing.
    Tuesday, July 2, 2019 2:04 PM
  • You would need that if you're sending mail from Exchange Online from your domain. 


    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
    Celebrating 20 years of providing Exchange peer support!

    Sadly, this was not the solution either. It does not seem that the other company uses outlook.com services to send to us. There is another IP in the chain of the SMTP headers from the other companies, main domain. Would this need to be included?

    Ex:

    Received: from MyInternalDomain (MyInternalIP) by MyInternalDomain
     (MyInternalIP) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Mailbox
     Transport; Thu, 27 Jun 2019 12:14:48 -0400
    Received: from MyInternalDomain (MyInternalIP) by MyInternalDomain
     (192.168.100.3) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 27 Jun
     2019 12:14:48 -0400
    Received: from mail.mycompany.com (Google IP) by
     mail.mycompany.com (MyInternalIP) with Microsoft SMTP Server (TLS) id
     15.0.1347.2 via Frontend Transport; Thu, 27 Jun 2019 12:14:47 -0400
    Received: by mail-qt1-f169.google.com with SMTP id y57so3058987qtk.4
            for <Me@mydomain.com>; Thu, 27 Jun 2019 09:14:47 -0700 (PDT)
    Received: from SW3PACVDW033 ([MainDomain IP of Allowed Company])
            by smtp.gmail.com with ESMTPSA id f132sm1097738qke.88.2019.06.27.09.14.45
            for <Me@mydomain.com>
            (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
            Thu, 27 Jun 2019 09:14:45 -0700 (PDT)
    Message-ID: <b388db4dbc325b55747ef15f4f97c37b2ac4a3cd@localhost>
    Date: Thu, 27 Jun 2019 09:14:45 -0700
    MIME-Version: 1.0
    From: <SpoofedAddress@mydomain.com>
    To: <Me@mydomain.com>

    This is the header from a test email from the spoofed email account that was sent to my email by the allowed company using google's services as a middleman.

    If the spoofing is legitimate, I think using DKIM in combination with SPF is a good choice.

    How DKIM works better than SPF alone to prevent malicious spoofing in Office 365

    Regards,

    Manu Meng


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    • Marked as answer by IinIT Friday, July 5, 2019 1:10 PM
    Friday, July 5, 2019 9:56 AM
    Moderator