Office 365 relay not allowing scan — TLS/SPOOF fix

Joe B.

Reviewed for technical accuracy

Specialities: Office 365 / Exchange Online, Printers & MFPs, SMTP relay, TLS 1.2, SPF/DKIM/DMARC

Fix scan-to-email with Office 365 — SMTP relay connector, TLS 1.2, anti-spoof (SPF/DKIM/DMARC), NDR 5.7.708 / 5.7.64

Technician

Hi! We’ll get your scan-to-email working through Office 365 (Exchange Online).
Quick triage to choose the right path: Is the MFP using SMTP AUTH client submission (smtp.office365.com:587 + STARTTLS), Direct send to your tenant MX for internal mail, or a connector-based SMTP relay from your static public IP on port 25? Any NDR codes like 550 5.7.708, 5.7.64, or 5.7.57? Brand/model (HP, Ricoh, Canon, Xerox, Kyocera) helps too.

Customer

We switched ISPs last month. Our Ricoh MFP sends via port 25 to Office 365 with a connector. It now fails to external addresses with 550 5.7.708 and sometimes 5.7.64 TLS required. The device can’t log in with a mailbox; it only supports unauthenticated relay.

Technician

Got it. Two things are likely at play:
1) Your public IP changed, so the Exchange Online connector no longer matches and Exchange Online Protection (EOP) blocks the relay with 5.7.708 (sender not authorized).
2) Some datacenters now expect TLS 1.2 for SMTP relay; older firmware only offers TLS 1.0/1.1 and triggers 5.7.64.
We’ll fix by updating the connector with the new static IP, setting TLS correctly, and aligning SPF/DKIM/DMARC so anti-spoof doesn’t stop messages to Gmail/Outlook recipients.

Customer

We do have a new static IP. From address is noreply@ourfirm.com. SPF was set years ago. What should we change in Exchange Admin Center?

Technician

Step 1 — Fix/Build the SMTP relay connector
• Go to Exchange admin center → Mail flow → Connectors → inbound connector type “From your organization’s email server” (a.k.a. SMTP relay).
• Choose validation By verifying the sender IP addresses and add your new public static IP (and any backup IPs/NATs).
• Set TLS: if the MFP supports TLS 1.2, select “Opportunistic TLS (recommended)” or require TLS and specify the device’s cert subject if available. If it can’t do TLS 1.2, leave TLS optional and plan firmware update or a local relay.
• Scope to All accepted domains in your tenant so you can relay to outside recipients using your verified domain in the From header.

Customer

The device is on older firmware. Ricoh says TLS 1.2 is supported after an update. We also saw an NDR that mentions spoofing. Do we still need SPF/DKIM changes if we use the connector?

Technician

Step 2 — Update TLS and align anti-spoof
• Upgrade firmware so the MFP negotiates TLS 1.2 + STARTTLS reliably.
• Publish/verify SPF on your domain: include v=spf1 include:spf.protection.outlook.com -all (plus any other legitimate senders).
• Enable DKIM in Microsoft 365 Defender → Email & collaboration; publish the two CNAMEs, then switch DKIM to On.
• Start with DMARC p=none to observe, then move to quarantine/reject once alignment looks good.
These reduce anti-spoof hits and help deliver to external mailboxes (Gmail, Yahoo, Outlook.com).

Customer

What if we decide to use a mailbox instead of IP relay? Some of our Canon copiers support authentication.

Technician

Step 3 — Alternative: SMTP AUTH client submission
• Create or use a mailbox like scanner@yourdomain.com. In the user’s settings, ensure Authenticated SMTP is On.
• In the MFP: Server smtp.office365.com, Port 587, Encryption STARTTLS, Username full mailbox, Password app password (if MFA) or standard password (if allowed).
• Set the From address to match the mailbox. This works well with HP, Canon, Xerox, Kyocera, Brother, and many Ricoh models.
• Advantage: delivers externally without an IP-scoped connector. Requirement: device must support TLS 1.2 and auth.

Customer

We prefer the no-login connector route. After adding the new IP, emails to staff work, but Gmail still bounces. Any other checks?

Technician

Step 4 — Finalize relay hygiene
• Ensure your MFP uses a verified domain in the From header (noreply@yourdomain.com). Avoid third-party From domains when relaying through your tenant.
• Add a dedicated mail contact or shared mailbox for replies if needed; many firms route scans to scans@ or records@.
• Check Exchange Admin Center → Mail flow → Message trace for EOP verdicts (spoof, policy, malware). Adjust Anti-phishing policy so your scanner’s From address (or domain) isn’t flagged as user impersonation.
• If your firewall NATs through multiple IPs, lock SMTP egress to the one listed in the connector.

Customer

That explains it — the firewall sometimes uses a backup IP. Also, we saw 5.7.23 once. Is that related?

Technician

Common Office 365 SMTP relay errors:
• 550 5.7.708 — IP not authorized by connector; add correct public IP(s).
• 550 5.7.64 — TLS required or TLS negotiation failure; update firmware to TLS 1.2 or set connector TLS appropriately.
• 550 5.7.23 — Sender blocked/spoof; align SPF/DKIM, use your domain in From, and review anti-phishing policy.
• 550 5.7.57 — Client not authenticated on 587; switch to connector IP relay or configure SMTP AUTH.

Customer

After locking egress to the primary static IP and updating SPF/DKIM, external sends work. Any best practices to keep it stable?

Technician

Final checks:
• Keep the MFP on static IP and latest firmware (TLS 1.2).
• Document your connector with all legitimate egress IPs; restrict firewall so SMTP out uses only those IPs.
• Use a dedicated noreply/scans mailbox or From address and monitor Message trace weekly for EOP hits.
• Review DMARC reports and gradually move from p=none to quarantine/reject to harden anti-spoof without breaking scans.

Customer

Perfect — scan-to-email now sends to internal and external addresses. Thanks for the help!

Technician

Summary: When Office 365 relay won’t allow scan-to-email, update the inbound SMTP relay connector with your correct static IP(s), ensure TLS 1.2 support or set TLS appropriately, and align SPF/DKIM/DMARC. Alternatively use SMTP AUTH on port 587 with a mailbox. Need hands-on help? Open the chat.

Quick answer: the accepted fix

Accepted fix when Office 365 SMTP relay blocks scan-to-email: update or create an inbound connector that authorizes your public static IP, ensure the MFP supports TLS 1.2 (or set TLS to opportunistic), use a verified From address, and align SPF/DKIM/DMARC. If the device supports auth, use smtp.office365.com:587 + STARTTLS with a dedicated mailbox.

FAQ

Step-by-step (Office 365)

1. Create or update an inbound connector “From your organization’s email server”; authorize your public static IP.
2. Upgrade MFP firmware and confirm TLS 1.2 + STARTTLS; set connector TLS to opportunistic or required.
3. Align SPF/DKIM/DMARC; use a verified domain in From.
4. Alternative: configure SMTP AUTH on smtp.office365.com:587 with a dedicated mailbox.

Note for mixed MFP fleets

1. Many HP, Canon, Ricoh, Xerox, Kyocera models need a firmware update for TLS 1.2 before SMTP AUTH/relay works.
2. If a legacy device can’t do TLS 1.2, route it through a local Windows SMTP relay/IIS server that supports TLS 1.2.

Sources

• Microsoft — Set up MFP/app to send email with Microsoft 365 (SMTP AUTH, Direct send, SMTP relay)
• Microsoft — Exchange Online NDR codes (5.7.708, 5.7.64, 5.7.57)
• Microsoft — Configure DKIM for Microsoft 365
• Microsoft — Use DMARC to validate email
• Microsoft — Set up SPF in Microsoft 365

Matt ● replies in < 1 min

Technician Expert

⭐⭐⭐⭐⭐ Trusted by 27,000+ customers

Alex · Expert's Assistant

Start Chat

5 Tech Support Specialists are online right now.