cdavis82
asked on
Office 365 SPF Record Problem
Using Office 365 to send to recipients from our domain. It appears one recipient has changed their domain to reject non matching SPF records. Received this NDR:
recipientmailserver.com rejected your message to the following email addresses:
Recipient (recipient@recipientdomain
Your message wasn't delivered because the recipient's email provider rejected it.
recipientmailserver.com gave this error:
Invalid SPF Record; Contact your local email administrator to resolve the issue.
Diagnostic information for administrators:
Generating server: DM5PR1201MB0090.namprd12.p
recipient@recipientdomain2
recipientmailserver.com
Remote Server returned '550 5.7.0 Invalid SPF Record; Contact your local email administrator to resolve the issue.'
Original message headers:
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
b=LE2wpgPFaGJtKHo+NlrfwuJM
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector9901;
h=From:Date:Subject:Messag
bh=snYS1hA+T5IMnXx86tPEkzJ
b=WQgVwBLmy/LqmxwLBR2J4sJu
ARC-Authentication-Results
smtp.mailfrom=medteleco.co
header.from=medteleco.com;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=medtele.onmicrosoft.com;
h=From:Date:Subject:Messag
bh=snYS1hA+T5IMnXx86tPEkzJ
b=oCU+diINIoSwYcDX0ebJC1JM
Received: from DM5PR1201MB0091.namprd12.p
DM5PR1201MB0090.namprd12.p
SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_
15.20.2347.16; Wed, 16 Oct 2019 17:46:46 +0000
Received: from DM5PR1201MB0091.namprd12.p
([fe80::d868:482d:da9e:122
([fe80::d868:482d:da9e:122
2019 17:46:46 +0000
From: Sender <sender@medteleco.com>
To: Recipient <recipient@recipientdomain
Subject: RE: Call Logs
Thread-Topic: Call Logs
Thread-Index: AdWDqTN+xFr9Or2LQ9u9XSK/oT
Date: Wed, 16 Oct 2019 17:46:45 +0000
Message-ID: <DM5PR1201MB009108E8A3D38A
References: <MN2PR02MB6800053D80E98F2C
<DM5PR1201MB0091174C01079D
<CH2PR02MB67894FC54C6D2B8F
In-Reply-To: <CH2PR02MB67894FC54C6D2B8F
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is )
smtp.mailfrom=sender@medte
x-originating-ip: [75.145.112.133]
x-ms-publictraffictype: Email
x-ms-office365-filtering-c
x-ms-traffictypediagnostic
x-microsoft-antispam-prvs:
x-ms-oob-tlc-oobclassifier
x-forefront-prvs: 0192E812EC
x-forefront-antispam-repor
received-spf: None (protection.outlook.com: medteleco.com does not designate
permitted sender hosts)
x-ms-exchange-senderadchec
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-messa
x-ms-exchange-transport-fo
Content-Type: multipart/alternative;
boundary="_000_DM5PR1201MB
MIME-Version: 1.0
X-OriginatorOrg: medteleco.com
X-MS-Exchange-CrossTenant-
X-MS-Exchange-CrossTenant-
(UTC)
X-MS-Exchange-CrossTenant-
X-MS-Exchange-CrossTenant-
X-MS-Exchange-CrossTenant-
X-MS-Exchange-CrossTenant-
X-MS-Exchange-Transport-Cr
Our SPF records are this:
The TXT records found for your domain are:
ca3-fb4e0338df1341bda9d096
google-site-verification=3
v=spf1 include:spf.protection.out
MS=ms63752656
v=spf1 ip4:67.41.129.214 include:spf.protection.out
v=spf1 ip4:75.145.112.133 include:spf.protection.out
I'm not sure if we need to add our sending domain to the SPF records or if the recipient has something misconfigured on their end. We have been sending to them this way for well over a year with no problems.
Any advice would be appreciated.
Thanks,
cdavis82
recipientmailserver.com rejected your message to the following email addresses:
Recipient (recipient@recipientdomain
Your message wasn't delivered because the recipient's email provider rejected it.
recipientmailserver.com gave this error:
Invalid SPF Record; Contact your local email administrator to resolve the issue.
Diagnostic information for administrators:
Generating server: DM5PR1201MB0090.namprd12.p
recipient@recipientdomain2
recipientmailserver.com
Remote Server returned '550 5.7.0 Invalid SPF Record; Contact your local email administrator to resolve the issue.'
Original message headers:
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
b=LE2wpgPFaGJtKHo+NlrfwuJM
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector9901;
h=From:Date:Subject:Messag
bh=snYS1hA+T5IMnXx86tPEkzJ
b=WQgVwBLmy/LqmxwLBR2J4sJu
ARC-Authentication-Results
smtp.mailfrom=medteleco.co
header.from=medteleco.com;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=medtele.onmicrosoft.com;
h=From:Date:Subject:Messag
bh=snYS1hA+T5IMnXx86tPEkzJ
b=oCU+diINIoSwYcDX0ebJC1JM
Received: from DM5PR1201MB0091.namprd12.p
DM5PR1201MB0090.namprd12.p
SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_
15.20.2347.16; Wed, 16 Oct 2019 17:46:46 +0000
Received: from DM5PR1201MB0091.namprd12.p
([fe80::d868:482d:da9e:122
([fe80::d868:482d:da9e:122
2019 17:46:46 +0000
From: Sender <sender@medteleco.com>
To: Recipient <recipient@recipientdomain
Subject: RE: Call Logs
Thread-Topic: Call Logs
Thread-Index: AdWDqTN+xFr9Or2LQ9u9XSK/oT
Date: Wed, 16 Oct 2019 17:46:45 +0000
Message-ID: <DM5PR1201MB009108E8A3D38A
References: <MN2PR02MB6800053D80E98F2C
<DM5PR1201MB0091174C01079D
<CH2PR02MB67894FC54C6D2B8F
In-Reply-To: <CH2PR02MB67894FC54C6D2B8F
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is )
smtp.mailfrom=sender@medte
x-originating-ip: [75.145.112.133]
x-ms-publictraffictype: Email
x-ms-office365-filtering-c
x-ms-traffictypediagnostic
x-microsoft-antispam-prvs:
x-ms-oob-tlc-oobclassifier
x-forefront-prvs: 0192E812EC
x-forefront-antispam-repor
received-spf: None (protection.outlook.com: medteleco.com does not designate
permitted sender hosts)
x-ms-exchange-senderadchec
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-messa
x-ms-exchange-transport-fo
Content-Type: multipart/alternative;
boundary="_000_DM5PR1201MB
MIME-Version: 1.0
X-OriginatorOrg: medteleco.com
X-MS-Exchange-CrossTenant-
X-MS-Exchange-CrossTenant-
(UTC)
X-MS-Exchange-CrossTenant-
X-MS-Exchange-CrossTenant-
X-MS-Exchange-CrossTenant-
X-MS-Exchange-CrossTenant-
X-MS-Exchange-Transport-Cr
Our SPF records are this:
The TXT records found for your domain are:
ca3-fb4e0338df1341bda9d096
google-site-verification=3
v=spf1 include:spf.protection.out
MS=ms63752656
v=spf1 ip4:67.41.129.214 include:spf.protection.out
v=spf1 ip4:75.145.112.133 include:spf.protection.out
I'm not sure if we need to add our sending domain to the SPF records or if the recipient has something misconfigured on their end. We have been sending to them this way for well over a year with no problems.
Any advice would be appreciated.
Thanks,
cdavis82
Rajkumar Duraisamy
Look at your server IP and the spf record include your sending server ip...
ASKER
Not sure I understand. We're using Office 365. I don't know the IP. We setup the SPF records per their requirements. The IP's in the SPF record are our IP's that resolve to our domain.
You have multiple SPF records, that's NOT supported and results in invalidating the whole record. If you need to add multiple IPs/FQDNs, combine them in a single record.
ASKER
Would this be a better format?
v=spf1 ip4:67.41.129.214 ip4:75.145.112.133 include:spf.protection.out
v=spf1 ip4:67.41.129.214 ip4:75.145.112.133 include:spf.protection.out
"The IP's in the SPF record are our IP's that resolve to our domain."
In addition to the multiple SPF records mentioned above, the IP addresses you've used may be incorrect. They should point to the sending mail server (at outlook.com) not your domain.
I have a client in a similar situation. The SPF record we use (that hasn't given us any trouble) is:
v=spf1 include:spf.protection.out
In addition to the multiple SPF records mentioned above, the IP addresses you've used may be incorrect. They should point to the sending mail server (at outlook.com) not your domain.
I have a client in a similar situation. The SPF record we use (that hasn't given us any trouble) is:
v=spf1 include:spf.protection.out
You may want to make the record less restrictive, in case you send email from other IP addresses (perhaps transactional email for instance). To do that you change the "-" to a "~".
So your single SPF record would be:
v=spf1 ip4:67.41.129.214 ip4:75.145.112.133 include:spf.protection.out
So your single SPF record would be:
v=spf1 ip4:67.41.129.214 ip4:75.145.112.133 include:spf.protection.out
Yes.. that is right.. Only Exchange Online Protection and those 2 IP addresses can send emails to internet as your domain..
Yes, that format should work. Dont forget to remove all other SPF records.
@Graham:
I recently changed a different client's SPF record from "~all" to "-all" because of a significant issue. Someone was spoofing email from one of the valid accounts. Because it appeared to be coming from the correct domain (though a different IP address than I had specified), the "~" allowed it through. Changing it to "-" resolved that.
I recently changed a different client's SPF record from "~all" to "-all" because of a significant issue. Someone was spoofing email from one of the valid accounts. Because it appeared to be coming from the correct domain (though a different IP address than I had specified), the "~" allowed it through. Changing it to "-" resolved that.
@CompProbSolv
While "spoofing" can become an issue, as the opener of this question indicated that they were using other servers to send email (even although they have delegated their domain email to MS O365) there is a strong possibility that other servers/IPs are also sending email on their domain. Thus, to negate the problem, relaxing the SPF record seemed appropriate.
Having said that, most main stream MTAs will flag a message/connection from an unidentified sending IP as it is considered a "soft fail" on SPF - which is the purpose of the "~". Meaning it tells the receiving server to treat the message as suspect - a "relaxed" soft fail.
In the overall arsenal of Anti Spam measures, SPF plays a very small role, and is for the most part ignored. DKIM coupled with DMARC is a far more effective route.
While "spoofing" can become an issue, as the opener of this question indicated that they were using other servers to send email (even although they have delegated their domain email to MS O365) there is a strong possibility that other servers/IPs are also sending email on their domain. Thus, to negate the problem, relaxing the SPF record seemed appropriate.
Having said that, most main stream MTAs will flag a message/connection from an unidentified sending IP as it is considered a "soft fail" on SPF - which is the purpose of the "~". Meaning it tells the receiving server to treat the message as suspect - a "relaxed" soft fail.
In the overall arsenal of Anti Spam measures, SPF plays a very small role, and is for the most part ignored. DKIM coupled with DMARC is a far more effective route.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.