Every network-connected multifunction printer (MFP) — HP, Canon, Xerox, Brother, Ricoh, Konica Minolta, Epson, Kyocera — ships with a minimal embedded SMTP client baked into its firmware, used for scan-to-email, fax-to-email, and job/status notifications. Unlike a real mail server, that client is rarely updated after the device ships. It's common to find devices still running TLS 1.0, offering only the oldest SMTP AUTH mechanisms, and validating certificates with logic that hasn't changed since the device was manufactured.
Meanwhile, mail servers have moved the other direction — dropping legacy TLS versions, requiring authenticated submission, and enforcing stricter sender validation. The result is a predictable set of failures every time a printer is pointed at a modern SMTP relay. This guide walks through them in the order you'll actually hit them: connection, authentication, encryption, relay/sender policy, and message size.
| Category | Typical symptom on the printer panel | Root cause |
|---|---|---|
| Connection | "Cannot connect to server" / timeout | Wrong port, firewall block, or server unreachable |
| Authentication | "SMTP authentication error" / 535 | Wrong credentials, or unsupported AUTH mechanism |
| Encryption | "Could not establish secure connection" | Outdated TLS version or STARTTLS mismatch |
| Relay / Sender | "Relaying denied" / 550 / 553 | Unauthorized relay attempt or unverified From: address |
| Message size | Scan job silently fails or times out | Attachment exceeds server or printer's size ceiling |
Printer error messages on the LCD panel are almost always paraphrased and vague. Whenever possible, pull the device's SMTP send log from its web admin console (usually under Network → Protocol Logs or similar) to see the actual server response code instead of the on-panel summary.
Connection & Port Errors
The printer can't reach the server at all
Before authentication or encryption ever comes into play, the printer has to open a TCP connection to the mail server. This is where most first-time setups fail.
Timeout Connection
"Cannot connect to SMTP server" / connection times out
The printer never completes a TCP handshake with the server. This is almost always a network path problem rather than an SMTP protocol problem: a firewall or the printer's own subnet is blocking outbound traffic on the configured port, the hostname is misspelled or unresolvable, or the printer is configured to use the wrong port for the connection type it's attempting.
Common port configuration
Port 25
Unauthenticated relay (legacy) — frequently blocked outbound by ISPs and corporate firewalls
Port 587
Authenticated submission with STARTTLS — the correct choice for almost all modern setups
Port 465
Implicit TLS ("SMTPS") — connection is encrypted from the first byte, no STARTTLS negotiation
Fix it
- Confirm the printer is set to port 587 (or 465 if it explicitly supports implicit TLS) rather than the legacy port 25, which most networks and providers now block or restrict for outbound traffic.
- Check outbound firewall rules on the printer's VLAN/subnet — many office networks segment printers onto a restricted VLAN that blocks everything except printing traffic by default.
- Verify the hostname resolves from the printer's own network context — test DNS resolution from another device on the same VLAN, since printer subnets sometimes use different DNS servers than the rest of the network.
- If the printer only supports IP literals reliably, confirm the mail server's IP hasn't changed — some older firmware caches DNS results indefinitely until a manual reboot.
421 Connection
Connection accepted then immediately dropped
The TCP handshake succeeds but the server closes the session right away, usually because the printer's IP has no reverse DNS, is on a dynamic/residential-style IP range the server treats as suspicious, or the server is rate-limiting connections from that IP due to a misconfigured retry loop on the printer (a stuck scan job retrying every few seconds looks identical to a low-grade attack from the server's perspective).
Fix it
- Check the printer's send log for repeated rapid connection attempts — a stuck job in the print/scan queue can hammer the server and trigger rate limiting; clear the job queue and retry once.
- If the printer sends directly to the internet instead of through an internal relay, route it through your organization's SMTP relay (like mySMTP) instead — this avoids reputation issues tied to office/ISP IP ranges entirely.
- Confirm the printer isn't configured to retry indefinitely on failure — set a sane retry limit in its network settings to avoid it re-triggering the same block.
Authentication Errors
The connection opens, but login fails
Once TCP connects, the printer negotiates SMTP AUTH. This is the single most common failure point for older MFP firmware.
535 Auth
5.7.8 Authentication credentials invalid
The server rejected the username/password pair — but on printers this is frequently not a typo. Many mail providers now require an app-specific password or API-style credential rather than the account's normal login password, especially once two-factor authentication is enabled on the mailbox the printer authenticates as. Printers can't complete a 2FA/MFA challenge, so any account using it will reject standard password auth outright.
AUTH LOGIN
334 VXNlcm5hbWU6
[base64 username]
334 UGFzc3dvcmQ6
[base64 password]
535 5.7.8 Authentication credentials invalid
Fix it
- Generate a dedicated app-specific password or SMTP credential for the printer rather than reusing the mailbox owner's normal password — most providers, mySMTP included, support scoped credentials for exactly this use case.
- Confirm the username field expects the full email address, not just the local part before the @ — a surprisingly common source of silent rejection on older firmware that truncates the field.
- Check for trailing whitespace or line-break characters introduced when copy-pasting credentials into the printer's tiny web-admin text fields.
- If the account has 2FA enabled, use an app password or dedicated relay credential — printers cannot complete an interactive MFA challenge.
504 Auth
5.7.4 Unrecognized authentication mechanism
The printer is offering an AUTH mechanism the server no longer accepts. Legacy firmware often defaults to
AUTH LOGIN or, on very old devices, AUTH PLAIN over an unencrypted channel — and increasingly, providers disable weaker mechanisms or require them to run only inside a TLS session. If the printer's firmware predates common modern mechanisms, there may be no compatible option at all without a firmware update.Fix it
- Check the printer's network settings for an explicit "authentication method" dropdown — many devices let you force LOGIN vs PLAIN independently of the AUTO-negotiated default.
- Update printer firmware if an update is available — manufacturers occasionally patch SMTP client behavior, including supported AUTH mechanisms, in firmware releases separate from feature updates.
- Confirm AUTH is being attempted only after STARTTLS completes, not before — some firmware incorrectly tries to authenticate on the plaintext connection first.
- As a last resort for genuinely unsupported firmware, route through an SMTP relay configured to accept the specific legacy mechanism the device supports, isolated behind your own infrastructure rather than exposed on the public mail server.
TLS & Certificate Errors
Encryption negotiation fails
This is where embedded firmware shows its age most visibly — printer TLS stacks are rarely maintained after release.
454 TLS
4.7.0 TLS not available / STARTTLS negotiation failed
The printer requested STARTTLS but the negotiation failed to complete, most often because the device only supports TLS 1.0 or 1.1 and the modern mail server has disabled those protocol versions entirely for security compliance. Cipher suite mismatches produce the same symptom — the device offers only outdated cipher suites the server refuses to negotiate with.
Fix it
- Check the printer's supported TLS versions in its network/security settings — if it caps out at TLS 1.1, a firmware update is the only real fix; many manufacturers have released updates specifically to add TLS 1.2 support to older models.
- If no firmware update exists, route the device through an internal relay that accepts the printer's legacy TLS version on your private network, then forwards outbound over modern TLS — keeping the weak connection off the public internet entirely.
- Verify the printer isn't hardcoded to a specific cipher suite list that's since been deprecated server-side; some enterprise MFPs expose a cipher preference list worth reviewing.
Cert error TLS
"Server certificate could not be verified"
The printer's certificate trust store is outdated or incomplete — embedded devices ship with a fixed set of root CA certificates baked in at manufacture time, and that list isn't updated the way a browser or OS trust store is. If your mail server's certificate chains through a CA added after the printer's manufacture date, or an intermediate certificate rotated, the device will reject an otherwise perfectly valid certificate.
Fix it
- Check whether the printer's admin console allows manually importing a trusted root/intermediate CA certificate — many enterprise-grade MFPs support this even without a full firmware update.
- Confirm your mail server is presenting the complete certificate chain (leaf + intermediates), not just the leaf certificate — some servers omit intermediates, which browsers tolerate via chain-building but embedded TLS stacks often don't.
- As a last resort, some devices offer a "skip certificate validation" toggle — only use this on a trusted internal relay connection, never for a connection that traverses the public internet.
Relay & Sender Policy Errors
Authenticated, encrypted — and still rejected
The printer successfully logs in over TLS, but the message itself gets bounced by policy rather than by connection or credential problems.
550 Relay
5.7.1 Relaying denied
The printer authenticated successfully but is trying to send as a From: address the credentials aren't authorized to use. This is common when someone configures a shared department mailbox as the login but leaves the From: field on the printer set to a different, unrelated address — the server accepts the login but refuses to let that account relay mail claiming to be from a domain or address it doesn't own.
Fix it
- Set the printer's From: address to exactly match the authenticated account, or to an address your SMTP provider has explicitly allow-listed for that account to send as.
- If multiple departments need to scan-to-email under different From: addresses, configure each printer or scan profile with its own dedicated relay credential rather than sharing one login across mismatched From: addresses.
- Check your SMTP provider's sender-verification settings — most require the From: domain to be a verified sending domain on the account, separate from the login credential itself.
553 Relay
5.1.8 Sender address rejected — domain not verified
The From: domain hasn't completed SPF/DKIM setup or domain verification with the SMTP provider, so the server refuses to accept mail claiming to originate from it — a protection against spoofing that applies to your own devices just as much as to outside senders.
Fix it
- Verify the sending domain is fully set up with the provider — SPF record published, DKIM selector configured and DNS propagated, before pointing devices at it.
- Double-check the exact From: domain configured on the printer matches the verified domain character-for-character, including subdomain — a printer sending as
scans.example.comneeds that exact subdomain verified, not just the root domain. - Use the Domain Intelligence scan to confirm SPF, DKIM and DMARC are all correctly published and aligned before troubleshooting further on the device side.
Message Size & Scan Job Errors
The connection works, but the job never arrives
The most frustrating failure mode: no error at all, just a scan job that silently vanishes.
552 Size
5.3.4 Message size exceeds fixed limit
High-resolution multi-page scans, especially color scans saved as uncompressed TIFF or high-DPI PDF, routinely exceed the 25–50MB limits most mail servers enforce on inbound message size. Because attachments are base64-encoded for SMTP transport, the effective size on the wire is roughly 33% larger than the raw file — a 20MB scan becomes a ~27MB attachment payload.
Fix it
- Lower the default scan resolution and switch the output format to compressed PDF or JPEG rather than TIFF/BMP for routine scan-to-email jobs — 200–300 DPI is sufficient for most document scanning and dramatically reduces file size.
- Enable the printer's built-in "split large jobs" or multi-page batching feature if available, so oversized multi-page scans send as several smaller messages instead of one large one.
- Confirm what size limit your SMTP provider actually enforces, and raise it if your plan allows — don't assume the default is the maximum available.
- For very large or frequent scan batches, consider a scan-to-cloud-storage workflow with an emailed link instead of attaching the file directly.
Diagnostic Workflow
A repeatable process for any printer SMTP failure
Work top to bottom in the order the protocol actually happens — there's no point debugging authentication if the TCP connection never opens.
1
Pull the real server response from the device's admin log
The LCD panel message is a paraphrase. The web admin console's protocol/network log usually shows the actual SMTP reply code and text — start there instead of guessing from the panel wording.
2
Confirm the port and connection type match
Port 587 with STARTTLS, or port 465 with implicit TLS — verify the printer's port setting and encryption mode are a matching pair, not mismatched (e.g. port 465 with STARTTLS enabled).
3
Test the credentials outside the printer first
Use a desktop mail client or command-line SMTP test with the same username/password to confirm the credentials work at all before assuming the printer's firmware is the problem.
4
Check firmware version against the manufacturer's release notes
Search for "TLS," "SMTP," or "scan to email" in the changelog of any firmware updates released after your device's purchase date — these fixes are often bundled quietly into unrelated feature updates.
5
If firmware can't be fixed, put a relay in front of it
For devices with permanently outdated TLS or auth support, route them through an internal SMTP relay that accepts the printer's legacy connection on your private network and forwards outbound using modern TLS and authentication — isolating the weak link instead of trying to eliminate it.
Stop guessing at printer SMTP settings
mySMTP's free toolbox checks SPF, DKIM, DMARC, MTA-STS and TLS configuration for your sending domain — and our managed relay gives every device on your network a modern, authenticated path out, no firmware update required.