SMTP Relay for Scan to Email: Setup, Security, and Troubleshooting

SMTP relay for scan to email is the practical bridge between a copier or multifunction printer (MFP) and your users’ inboxes. The reliable approach is to choose the right relay model, authenticate or allow-list the device safely, configure encryption correctly, and test the complete route—not merely whether the printer says “sent.”

A scanner does not deliver email by itself. After creating a PDF, JPEG, or TIFF, it acts as an SMTP client: it connects to a mail server, identifies itself, submits a message, and expects that server to route the message onward. Modern email security makes that less simple than entering an SMTP host and a password. Old devices may not support modern authentication or current TLS versions; public providers restrict anonymous relay; and a configuration that works internally may fail for external recipients.

This guide explains the viable designs, shows concrete settings, and provides a worked configuration you can adapt for a Microsoft 365, Google Workspace, or dedicated SMTP-relay environment.

What an SMTP relay for scan to email does

An SMTP relay accepts mail from a trusted system and takes responsibility for delivery. In this case, the trusted system is usually a networked MFP from Canon, HP, Ricoh, Xerox, Konica Minolta, Kyocera, Brother, Epson, or a similar vendor.

The workflow is straightforward:

1. A user scans a paper document at the device.
2. The device creates an attachment and an email envelope.
3. The device connects to an SMTP submission or relay endpoint.
4. The SMTP service authenticates the device, checks its source IP address, or both.
5. The service relays the message to internal or external recipients and records delivery activity in its logs.

The distinction between SMTP submission and SMTP relay matters. SMTP submission generally means a client authenticates as a mailbox or service account and sends through its provider. SMTP relay usually means the service trusts a known source IP address, connector, certificate, or private network and can send as an approved domain. Printer menus often label both options as “SMTP server.”

For a single small-office printer, authenticated submission can be acceptable. For several printers, appliances that cannot use modern authentication, or scans that must reach external addresses, an IP-restricted relay or an on-premises relay host is usually more maintainable.

Decide which scan-to-email design fits your environment

Start with the routing requirement, not the printer’s settings page. The right configuration depends chiefly on where scans go, which email platform you use, and how capable the device is.

Option 1: Authenticated SMTP submission

The printer logs in to an SMTP endpoint with a username and password, app password, or provider-supported token. Typical settings are port 587 with STARTTLS, although the actual combination depends on the provider.

This is easiest when the device supports TLS and the provider permits the chosen authentication method. It has real drawbacks: a shared mailbox credential stored in every printer becomes an operational and security dependency, and many older MFPs do not support OAuth 2.0 or required TLS cipher suites.

Use it when:

• You have one or a few current-generation devices.
• The email provider explicitly supports the device’s authentication method.
• The sender can be a dedicated account such as scanner@yourdomain.com.
• You can restrict who may use that account and monitor its activity.

Do not use a staff member’s personal mailbox password. It creates avoidable access, ownership, and continuity problems.

Option 2: IP-based SMTP relay

The SMTP provider accepts messages because they originate from a public IP address you have explicitly authorized. The printer normally does not need a mailbox password. A relay policy still restricts accepted senders, recipients, or both.

This is often the best choice for scan-to-email fleets. It works with devices that lack OAuth support, centralizes trust at the internet gateway, and avoids retaining a user credential on each printer. It does require a stable outbound public IP address. If your office IP changes, relay may fail until the allow-list is updated.

Use it when:

• Multiple printers use one or more fixed business internet connections.
• Devices need to send outside the organization.
• Your provider offers a connector, SMTP relay service, or IP allow-list.
• You can control outbound SMTP traffic so unapproved devices cannot abuse the relay.

Option 3: Internal SMTP relay host or gateway

The printers submit to a server on the local network, commonly on port 25 or 587. That server enforces local rules and then sends through Microsoft 365, Google Workspace, Amazon SES, a transactional-email provider, or a secure email gateway.

An internal relay is useful where printers cannot negotiate modern TLS, the building has multiple internet connections, or detailed local audit controls are required. Products and platforms used for this include Postfix on Linux, Microsoft IIS SMTP Service in older Windows deployments, hMailServer in supported environments, and commercial email-security gateways. The operational burden is higher: an incorrectly configured host can become an open relay.

Use it when:

• Legacy printers require a compatibility layer.
• You need to accept SMTP only from private subnets and apply rules centrally.
• Direct cloud relay is unavailable or fails due to networking constraints.
• You have an administrator who can patch, monitor, and secure the host.

Option 4: Vendor cloud scan service

Some MFP vendors provide cloud connectors for Microsoft 365, Google Drive, OneDrive, SharePoint, or email. These can be useful if they support your identity and retention requirements. They are not automatically preferable: assess subscription cost, where document content is processed, supported authentication, exportability of logs, and what happens if the vendor service is unavailable.

Prerequisites to gather before changing the printer

Gather the facts first. Most failed implementations are not printer problems; they are missing DNS, identity, firewall, or policy details.

You need:

• The MFP’s make, model, firmware version, and administrator access.
• Its fixed internal IP address, such as 192.168.40.25.
• The office’s outbound public IP address or addresses if using IP allow-listing. Do not confuse this with the printer’s private RFC 1918 address.
• Your email platform and its supported relay method.
• A dedicated visible sender, for example scanner@contoso.example.
• The intended recipient scope: internal addresses only, any external address, or a limited external list.
• The maximum attachment size supported by both the printer and the email route.
• The required SMTP hostname, port, TLS mode, and authentication choice.
• Permission to create DNS records or mail-flow connectors if your platform requires them.

Assign the MFP a DHCP reservation or static address. A reservation is commonly preferable because it maintains centralized IP management while giving the device a predictable address. Also set valid DNS servers, a default gateway, and NTP/time settings on the MFP. TLS certificate validation can fail if the device clock is substantially wrong.

Create a dedicated sender identity rather than making the device impersonate arbitrary employees. The sender should be recognizable in inboxes and log searches: scanner@contoso.example or mfp-east@contoso.example is clearer than office365@contoso.example.

SMTP settings: ports, TLS, names, and authentication

A reliable setup uses the provider’s fully qualified domain name (FQDN), not an IP address. TLS certificates are issued to names, and a printer configured with a raw IP may reject the certificate or lose routing resilience.

Understand the common ports

Port 587 is the standard message-submission port. In many services, the client connects in plaintext and then upgrades the connection using the SMTP STARTTLS command. A device menu may call this “STARTTLS,” “TLS,” or “Explicit TLS.”

Port 465 is commonly used for SMTP submission with TLS active from the moment the TCP connection opens. A menu may call this “SSL/TLS,” “SSL,” “Implicit TLS,” or “SMTP over SSL.” Do not select port 465 with STARTTLS unless the provider and device documentation explicitly describe that pairing.

Port 25 is traditionally SMTP server-to-server transport and remains common for IP-based relay from trusted networks. Many consumer ISPs block outbound port 25 to reduce spam. Business connections may permit it, but you must test from the actual printer network. A provider may offer 587 as an alternative for relay.

Port selection alone is not security. A port-25 relay with strict source-IP restrictions can be safer than a password-based printer configuration; a port-587 endpoint with an overly privileged mailbox credential can be risky. The controls around the connection matter.

TLS and certificate validation

Enable TLS whenever the device and service support it. Choose the provider’s stated TLS mode. If the MFP has a certificate-validation toggle, keep validation enabled and install the relevant trusted CA certificate chain only when the device requires manual CA installation.

Never solve a certificate error by permanently selecting “ignore certificate errors” or “accept all certificates.” First check:

• The configured SMTP host exactly matches the provider’s documented name.
• DNS on the printer resolves that name.
• The printer has correct date, time, time zone, gateway, and DNS settings.
• Its firmware supports the required TLS version and certificate chain.
• SSL/TLS inspection on a firewall is not substituting a certificate the MFP does not trust.

If an old device cannot support the provider’s required TLS, use a controlled internal relay that accepts the printer only on a segmented local network and makes the modern encrypted outbound connection. Replacing unsupported hardware is the cleaner long-term choice.

Authentication methods

The safest practical authentication method depends on the platform:

• IP allow-list / connector: trust a fixed public IP and restrict acceptable sender domains. This is common for organization-wide scanner relay.
• SMTP username and password: use only a dedicated, least-privileged service identity when your provider still supports it.
• App password: some providers offer these when multifactor authentication is enabled, but availability and policy vary. Treat an app password as a high-value secret.
• OAuth 2.0: avoids a reusable mailbox password but requires explicit support by both the printer and provider. Many older MFPs lack it.
• Client certificate: some enterprise relay designs use mutual TLS. It is strong but more complex to deploy and renew.

Provider policies change. Verify the current documentation for your exact tenant and device model before committing to a password-based SMTP AUTH design. In particular, do not assume a legacy authentication method remains enabled merely because an old setup guide mentions it.

Microsoft 365 scan-to-email relay options

Microsoft 365 documentation distinguishes three patterns: authenticated client SMTP submission, direct send, and SMTP relay through a connector. They have very different results.

Authenticated client SMTP submission

For Exchange Online client SMTP submission, Microsoft documents smtp.office365.com with port 587 and STARTTLS. The device authenticates with a licensed or otherwise valid mailbox/service identity, and SMTP AUTH must be permitted for that mailbox and tenant under your organization’s policies.

This route can send to internal and external recipients, subject to Microsoft 365 policy and anti-abuse controls. It is appropriate only if the printer supports the authentication requirements your tenant enforces. Configure a dedicated account, restrict sign-in and mailbox permissions appropriately, and review Microsoft’s current SMTP AUTH and OAuth guidance rather than relying on old Basic Authentication tutorials.

Direct send: usually internal recipients only

Microsoft 365 direct send submits to your organization’s MX endpoint, often in a form such as contoso-com.mail.protection.outlook.com, on port 25. It does not require a mailbox login, but it is intended for delivery to recipients in your accepted Microsoft 365 domains.

Direct send is tempting because it looks easy, but it is not a general-purpose external relay. It also requires careful protection against spoofing and abuse. Do not select direct send if users expect to scan documents to personal, supplier, customer, or other external addresses.

Connector-based SMTP relay

For scanners that must send externally and cannot authenticate as a mailbox, configure an Exchange Online inbound connector that identifies mail from your organization by a static public IP address or a certificate. Configure the MFP to send to your Microsoft 365 MX endpoint on port 25, using a sender address in a domain you own and have verified in Microsoft 365.

The connector must be narrow: allow only your actual egress IP addresses, not an entire broad range. Microsoft’s setup guidance also describes SPF/DNS considerations for your domain. Connector relay is generally the stronger fit for a fixed-location printer fleet because no mailbox password is stored on the devices.

Google Workspace SMTP relay service

Google Workspace provides an SMTP relay service aimed at devices and applications. Google’s documented relay host is smtp-relay.gmail.com. In the Google Admin console, the SMTP relay service setting lets an administrator specify allowed senders, allowed IP addresses, required TLS, and whether unauthenticated messages are allowed from approved IPs.

A typical IP-based setup is:

1. In the Admin console, locate the Gmail SMTP relay service settings.
2. Add the office’s static outbound public IP address to the allowed IP range.
3. Restrict sending addresses to your domains where possible.
4. Require TLS when the MFP supports it.
5. Configure the MFP with host smtp-relay.gmail.com, the port and encryption mode specified by Google’s current documentation and your relay policy, and no SMTP username/password when using IP authentication.
6. Send an internal and external test message.

Google Workspace configuration choices are policy-dependent. The Admin console wording and available controls can differ by edition and account configuration, so treat screenshots from generic tutorials as illustrative rather than authoritative. Use Google’s official SMTP relay documentation for the current port, TLS, and authentication combinations.

Worked example: an IP-restricted relay for a small office

Assume Contoso has a Ricoh MFP at 192.168.40.25, a reserved internet address of 198.51.100.42 (an example-only documentation IP), Microsoft 365 for mail, and a verified domain contoso.example. Staff must scan to internal users and external suppliers. The device cannot use OAuth 2.0 reliably, so Contoso chooses connector-based SMTP relay.

Step 1: define the sender and network path

Contoso chooses scanner@contoso.example as the From address. Its network team confirms that all mail from the printer exits through the firewall at 198.51.100.42, and that the firewall permits the route required to reach Microsoft 365’s MX endpoint on TCP port 25.

The team creates a DHCP reservation for 192.168.40.25. The device receives internal DNS servers, gateway 192.168.40.1, and NTP from the organization’s approved time source.

Step 2: create the Microsoft 365 connector

In the Exchange admin center, an administrator creates an inbound connector for mail coming from the organization’s email server or partner organization. The connector identifies the sender by IP address and lists only 198.51.100.42.

The administrator does not use 0.0.0.0/0, a large ISP range, or a dynamic IP. They also verify the accepted domain contoso.example and follow Microsoft’s documented domain authentication and connector requirements. The goal is that Exchange Online accepts mail only from Contoso’s known egress path, not from arbitrary internet sources claiming to be the scanner.

Step 3: find the correct MX target

The team retrieves the Microsoft 365 MX record for contoso.example from the Microsoft 365 domain setup page or DNS. In this worked example, suppose it is contoso-example.mail.protection.outlook.com; use your own tenant’s actual record, not this illustrative name.

This is the printer’s SMTP server name. It is not smtp.office365.com, because that hostname is for authenticated client submission rather than the connector-based relay pattern.

Step 4: enter the MFP settings

In the Ricoh web administration interface, Contoso enters settings equivalent to these labels:

The precise field labels differ by manufacturer. Some devices have a separate “SMTP authentication” checkbox and “Use SSL” or “Use STARTTLS” dropdown. Do not guess: select the combination Microsoft documents for the relay connector and that the MFP firmware supports.

Step 5: test in a useful order

First, scan a one-page black-and-white PDF to it-admin@contoso.example. Then scan to an external test mailbox controlled by Contoso. Finally, test a realistic multi-page color scan that approaches—but does not exceed—the configured size limit.

Contoso records the date, recipient, sender, approximate attachment size, MFP job ID, and result. In Exchange message trace, the team confirms the message entered through the expected connector and was delivered or received an actionable failure reason. This establishes a baseline that makes later troubleshooting far faster.

Secure the relay so it cannot become a spam route

A scanner relay handles documents that may contain invoices, IDs, contracts, medical information, or HR records. Its security design should cover both unauthorized sending and unintended disclosure.

Restrict who can submit mail

For an IP-based relay, allow only the exact static egress IP or small documented range. On your firewall, limit outbound SMTP from the printer VLAN to the approved relay destinations. This prevents another compromised workstation from using the scanner relay simply because it shares an office network.

For an internal relay, permit inbound SMTP only from the printer subnet. Configure explicit recipient and sender restrictions. In Postfix terms, the critical principle is that mynetworks must include only trusted networks, while relay access must not be granted to the public internet. Test from an unauthorized network to confirm rejection.

Limit sender identities and recipient scope

Where the service supports it, allow only scanner@yourdomain.com or a defined scanner-address range as envelope and header senders. If the business only needs internal scan delivery, enforce internal recipients only. If external scanning is necessary, consider a controlled allow-list for supplier or customer domains where that fits the workflow.

This matters because broad external relay is attractive to attackers. It also reduces damage from a typo: a sensitive scan intended for ap@yourdomain.com should not silently go to an unrelated external address.

Protect device administration and documents

Change the MFP’s default administrator password, disable obsolete management protocols, use HTTPS for its web interface, and keep firmware supported by the manufacturer. Place MFPs on a segmented VLAN with only the services they need: DNS, NTP, approved relay access, management from administrator networks, and approved scan destinations.

Set a sensible local job-retention policy. Some devices retain scanned documents, address books, job history, or credentials on internal storage. Review secure erase, encryption-at-rest, address-book access, and vendor service-access settings. Decommissioned printers deserve the same data-erasure process as laptops.

Use domain authentication correctly

SPF, DKIM, and DMARC are domain-level email controls, not printer settings. If your relay sends mail as yourdomain.com, ensure your mail platform’s documented configuration supports that sending route and that your SPF record includes the appropriate authorized senders. DKIM signing is commonly performed by the outbound mail platform, not by the MFP.

Do not add random SPF mechanisms copied from forums. An incorrect SPF record can disrupt legitimate mail. Validate DNS changes with your email administrator and use DMARC aggregate reports to understand alignment results.

Troubleshooting scan-to-email failures systematically

A printer display usually reports vague errors such as “SMTP error,” “connection failed,” or “authentication error.” Work from network connectivity upward to policy and message content. Changing several settings at once makes diagnosis harder.

Connection and DNS failures

If the MFP cannot connect, verify its IP address, subnet mask, gateway, and DNS. Check that the SMTP host resolves from the printer’s network and that the firewall permits the required outbound TCP port. A workstation test is useful only if it follows the same DNS, firewall, and public egress path as the printer.

Common clues include 421 temporary service errors, timeouts, and connection-refused messages. A timeout commonly indicates routing or firewall filtering; a TLS error after connection suggests encryption or certificate compatibility; an immediate relay refusal suggests the server was reached but policy rejected the message.

Authentication failures

Errors such as 535 generally indicate authentication failure. Confirm the exact username format required by the provider, whether SMTP AUTH is enabled for the account, whether an app password is required or permitted, and whether the device supports the provider’s authentication method.

Do not repeatedly retry a known-bad password. Providers can rate-limit or flag repeated attempts. If you rotate a service credential, update it in every device that uses it and document the ownership and rotation process.

Relay-denied and sender-policy errors

Messages like 550 5.7.1 Unable to relay mean the SMTP service accepted the connection but will not route the recipient or sender. Check the connector’s source IP, whether the printer’s public IP changed, the From address, the accepted domain, and recipient restrictions.

A frequent Microsoft 365 error is configuring direct send while trying to reach an external recipient. The connection can appear valid but external delivery is not the supported use case. Move to authenticated submission or connector-based relay instead.

Attachment-size and format errors

Email attachments are encoded for transport, which increases their transmitted size. A PDF that appears close to a service’s maximum may exceed the effective message limit after encoding and headers. Configure the MFP’s scan size below the tightest limit in the printer, relay service, mailbox policy, and recipient system.

Reduce resolution, choose black-and-white for text documents, use PDF compression, or split large jobs. Avoid setting a very high default resolution merely because it is available: it increases transfer time, mailbox consumption, and failures without improving ordinary text readability.

Delivery succeeds but the email is missing

“Transmission completed” means only that the printer handed the message to the next SMTP hop. It does not prove inbox delivery. Check the sending platform’s trace or message logs, then check recipient junk/quarantine systems and any secure-email gateway.

Use a unique subject such as SCAN-TEST-2026-001 during testing. That makes it easy to locate the exact message in logs. Record SMTP response codes and enhanced status codes; they are more useful than a generic MFP screen message.

How to verify that the setup really worked

A successful installation is repeatable, observable, and constrained. Do not stop after one internal email arrives.

Run this acceptance checklist:

• Scan a one-page PDF to an internal recipient.
• Scan to an approved external recipient if external delivery is part of the requirement.
• Test a realistic larger document below the configured limit.
• Confirm the From address is the approved scanner identity.
• Confirm messages appear in the email platform’s trace or relay logs.
• Verify TLS and authentication or IP connector use in available logs.
• Attempt a submission from an unauthorized network and confirm it is rejected.
• Confirm that a changed From address or unauthorized sender is rejected when policy is meant to restrict it.
• Check that the user receives a usable attachment and that the file is not corrupt.
• Document the owner, public IP, SMTP endpoint, device location, and credential/connector renewal tasks.

Monitor the relay after deployment. A sudden increase in volume, delivery failures, new recipient countries, or use outside normal office hours can indicate misconfiguration or compromise. Mail platform logs, firewall logs, and MFP audit logs each reveal different parts of the path.

Alternatives when SMTP relay is not the best answer

Email is convenient, but it is not always the best document-delivery workflow. Large or sensitive scans often fit better in a controlled repository.

Scan-to-folder via SMB can work inside a well-managed network, although SMB permissions and service accounts need the same care as SMTP credentials. Scan-to-SFTP provides encrypted file transfer where the MFP supports it. Scan-to-SharePoint, OneDrive, Google Drive, or a document-management system can provide access control, retention, versioning, and audit trails that ordinary email attachments lack.

For regulated or confidential material, a workflow that stores the document in a controlled repository and sends a link may reduce accidental forwarding and mailbox sprawl. However, evaluate the device’s cloud integration carefully: confirm its identity model, data residency, logging, supported file types, and service lifecycle.

A dedicated transactional SMTP provider can also be appropriate when Microsoft 365 or Google Workspace relay does not fit. Look for mandatory TLS, IP allow-listing, domain verification, granular API or SMTP credentials, message logs, suppression handling, and clear sending limits. Avoid consumer email accounts as a production scanner relay; they are designed for interactive use and their policies can change without accommodating appliance workflows.

FAQ

What SMTP port should I use for scan to email?

Use the port required by your relay provider. Port 587 with STARTTLS is common for authenticated client submission; port 25 is common for IP-restricted server-to-server relay; port 465 is used by providers that require implicit TLS. Match the port to the documented encryption mode rather than choosing by habit.

Can a scanner send email through Microsoft 365 without a mailbox password?

Yes. Microsoft 365 connector-based SMTP relay can trust a static public IP address instead of a mailbox credential. It requires appropriate Exchange Online connector configuration, an accepted sender domain, and a network path that meets Microsoft’s documented requirements. Direct send is a separate option and is generally intended for internal Microsoft 365 recipients.

Why does scan to email work internally but not externally?

The usual cause is using an internal-only route such as Microsoft 365 direct send, or a relay policy that restricts external recipients. Check the relay model, connector settings, allowed recipient domains, sender domain, and email-platform message trace.

Is it safe to put a Gmail or Microsoft 365 password in a printer?

It is less desirable than an IP-restricted relay or OAuth-based device integration because the secret is stored on an appliance and may be difficult to rotate across a fleet. If password-based SMTP is unavoidable, use a dedicated least-privileged service account, require TLS, restrict its use, protect MFP administration, and rotate the credential under a documented process.

How do I know whether my SMTP relay is an open relay?

Test from a network and source IP that are not authorized and verify the server rejects an attempt to send to an external address. Also review firewall and relay logs. A public system that accepts unauthenticated mail from arbitrary sources and forwards it to arbitrary external recipients is an open relay and must be corrected immediately.