Office365 and Scan To Email

[Stephen Caustick]

Kia ora Koutou

We have moved our email to Office365 went smoothly expect we have lost scan to email. Most of our printers are Ricoh and we have a combination of n4l.relay and smtp2go. Why we have this combination from our supplier is another question. Using smtp.office365.com is also not working.

Has anyone come across this? Is an Office 365 SMTP Relay the answer?

Nga mihi

Stephen Caustick

IT Technician

Hastings Boys' High School

(06) 8730365 ex 847

step...@hastingsboys.school.nz

 

[Dave Diprose]

Hello.

We use N4L relay when using scan to email and we are also Office365. We have no problems.

I would suggest making sure your external DNS is setup, specifically the spf record. 

I was given this link by N4L which has some info about this.

https://support.n4l.co.nz/s/article/N4L-Mail-Relay-Service-Technical-Settings

Cheers

[Matt Strickland]

Us as well, use N4L's relay with no issues with O365. We just have the SPF record setup which you likely already have?

Didn't go the Office 365 Connector route with our devices just to remove the complexity with certificates for authentication, or when we changed IP.

Just was easier to stick with N4L's service.

Matt

[Pete Mundy]

Heya Stephen

% dig txt hastingsboys.school.nz +short

"v=spf1" "include:spf.protection.outlook.com" "include:_netblocks.mimecast.com" "include:_spf.n4l.co.nz" "include:_spf.google.com" "-all."
"adobe-idp-site-verification=66b902d01d75d000b427e962306c4fa5bf9f288e621d946192fd2199d275322d"

I doubt it's the root cause of your problem, but you may want to remove the trailing period after the "-all" (pretty sure the trailing period there is invalid syntax).

Also, Gemini seems to think there should be spaces embedded within the quoted strings, ie it asserts that the resolver will simply concatenate the strings without adding spaces, therefore resulting in an effective record of:

"include:spf.protection.outlook.cominclude:_netblocks.mimecast.cominclude:_spf.n4l.co.nzinclude:_spf.google.com-all.".

(which is invalid)

The recommended string, assuming you really do need all those includes, is:

"v=spf1" " include:spf.protection.outlook.com" " include:_netblocks.mimecast.com" " include:_spf.n4l.co.nz" " include:_spf.google.com" " -all"

Hope this helps & good luck with the new MUA :)

Pete

On Wed, 19 Nov 2025 at 13:33, 'Matt Strickland' via Techies for schools <techies-f...@googlegroups.com> wrote:

<snip> We just have the SPF record setup which you likely already have?

[Dion McGovern-Allen]

Hi Stephen,

Here at Feilding High School, we still (like others) have access to relaying via the N4L relay.

I see that your record has it set to fail if it doesn't come from any of your allowed IP ranges.
We have ours set to softfail (~) which means emails not listed from our IPs should be accepted but marked as not originating from us.

It also means that you can troubleshoot emails that get marked for the reason why.
A hard reject can make things harder!

Our record is like this in Cloudflare - "v=spf1 a ip4:122.56.185.161 mx ip4:101.98.57.74 ip4:202.90.44.217 ip4:202.90.44.219 include:_spf.n4l.co.nz include:spf.protection.outlook.com ~all"

Its all on one line, with spaces between the pairs of information and quotations only around the whole line.

When running a text record query with NSLookup, the formatting on your record looks weird.

With each entry on a new line and quotes around each portion.

Mimecast is a new addition, since I believe we're using N4L's Proofpoint for email filtering.

The N4L include:_spf.n4l.co.nz should cover their relay systems.

This is the output from MXToolbox.com (handy site to bookmark if you haven't)

Thanks,

Dion McGovern-Allen.

On Wednesday, 19 November 2025 at 10:28:02 UTC+13 step...@hastingsboys.school.nz wrote:

[Stephen Caustick]

Thank you for all your feedback. I have the scan to email working now, but I am going to look into our SPF record

Nga mihi

Stephen Caustick

IT Technician

Hastings Boys' High School

(06) 8730365 ex 847

step...@hastingsboys.school.nz

 

---

From: techies-f...@googlegroups.com <techies-f...@googlegroups.com> on behalf of Dion McGovern-Allen <bossdoo...@gmail.com>
Sent: Thursday, November 20, 2025 11:29 AM
To: Techies for schools <techies-f...@googlegroups.com>
Subject: [techies-for-schools] Re: Office365 and Scan To Email

 

--
You received this message because you are subscribed to the Google Groups "Techies for schools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to techies-for-sch...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/techies-for-schools/5c915588-f1e1-4752-bd48-fead7eb34eb1n%40googlegroups.com.

[Pete Mundy]

FWIW, after the txt record was amended yesterday to include the spaces and remove the trailing dot I think it is now valid (other than that it has >10 includes, ie 12). The broken-up state of the strings is actually defined in RFC 1035, but there's no real need for them to be broken up given that they total <255 bytes combined.

Or for the supergeeks, the longer version in an AI summary! ->

The ability to split a long string in a DNS TXT record is defined in RFC 1035, Section 3.3.14, which specifies the format of the TXT resource record (RR) data.

The Relevant Text from RFC 1035:

RFC 1035 defines the RDATA (Resource Record Data) for a TXT record as:

TXT-DATA One or more <character-string>s.

Furthermore, the general definition of a <character-string> is described in RFC 1035, Section 3.3 (Standard RRs):

<character-string> is a single length octet followed by that number of characters. <character-string> is treated as binary information, and can be up to 256 characters in length (including the length octet).

 
This means the usable text within a single string is limited to 255 bytes (or characters), because one byte is used to store the length itself.

How this enables splitting:

The key is that the definition in Section 3.3.14 explicitly allows for "One or more" character strings within a single TXT record. When a DNS resolver or an application (like one performing an SPF or DKIM check) retrieves this record, it automatically concatenates all the individual strings together, without adding any spaces between them, to form one continuous value.

 
This mechanism allows you to bypass the 255-character per-string limit by dividing the total content into multiple chunks, each under 255 characters. The total length of all concatenated strings in a single TXT record can technically be much longer, up to the maximum size of the RDATA field (approximately 65,535 octets). 

But in the end.. it was DNS :)

Pete

On Thu, 20 Nov 2025 at 11:29, Dion McGovern-Allen <bossdoo...@gmail.com> wrote:

<snip>

When running a text record query with NSLookup, the formatting on your record looks weird.

With each entry on a new line and quotes around each portion.

<snip>