Home › Canon › Canon Printer › Canon Scan-to-Email & Send Error Codes (#751–#899): Fixes

Canon Scan-to-Email & Send Error Codes (#751–#899): Fixes

Canon Printer display showing GUIDE — FixCode Guide error code graphic

When an imageRUNNER or imageCLASS machine fails to send a scan, it reports a three-digit code beginning with # — shown in the job details on the Status Monitor/Cancel screen and printed in the Results column of the Communication Management Report. Canon publishes the master list in its online manuals ('List of Error Codes without Messages' for imageRUNNER ADVANCE, and 'Countermeasures for Each Error Code' for imageCLASS), and this guide covers the eight codes verified word-for-word from those Canon lists: #751, #752, #753, #801, #802, #806, #839 and #899. They divide cleanly — network-down codes, name-and-address codes, credential codes, and one code (#899) that is not an error at all — and that division, below, is the fastest route from a failed scan to the setting that caused it.

Safety first. Work unplugged. Canon's procedures consistently put 'turn off and unplug' ahead of any internal inspection, and covers should only be opened as far as the model's consumer documentation describes (carriage and tank access); everything deeper is service work, on machines connected to mains electricity. Inside a PIXMA, observe Canon MX922's labelled warning: do not touch the clear encoder film, the white carriage belt or the ink tubes during jam clearing and cleaning — the film is both fragile and a diagnostic component. Treat ink as a chemical consumable: wash skin contact, keep cartridges and MegaTank ink away from eyes, and never defeat the ink-out protection (holding Stop for 5 seconds to disable remaining-ink detection) as a routine — Canon warns that printing under ink-out conditions may damage the machine and accepts no liability for that damage. On imageRUNNER machines add heat and scale: the fixing unit runs at fuser temperatures (the E001 thresholds in Canon's manuals are in the hundreds of degrees), internal parts are service-only, and a copier that has tripped a fixing protection code should be left to a technician rather than repeatedly reset and retried.

Where # codes live: the job log and the Communication Management Report

A # code is never shown as a headline error the way a jam is; it is recorded against the job. Canon's imageRUNNER ADVANCE manual explains the two places it surfaces: the details screen of the job, reached through Status Monitor/Cancel, and the Results column of the Communication Management Report — the printed or emailed log the machine keeps of its transmissions. That placement shapes how these codes should be worked. The user who scanned sees only 'sending failed'; the code, with the job's destination, time and page count, is in the log, and the first diagnostic act is always to retrieve it from there rather than to guess from the symptom. The second consequence is archival: because the report persists, a pattern of codes over weeks is available to whoever administers the machine — #802 appearing every Monday morning is a different problem from #802 appearing once, and the log is what proves it. The Canon lists this guide is built from are written for that administrator: each code gets a cause statement and a countermeasure, in the terse style of Canon's manuals, and the sections below expand them only with what the lists themselves say. Nothing in these codes concerns the scanner's optics or the paper path: the # family is entirely about the machine's conversation with servers, which is why its fixes live in settings screens — Communication Settings, TCP/IP Settings — rather than in the machine's covers.

#751: the server or the network is not there (file sending)

#751 is the send family's foundation code. Canon's imageRUNNER ADVANCE list defines it as: the server is not functioning, or the network is not connected — with two platform-specific additions for sending to a file server: check whether the machine's IP address is set (in TCP/IP Settings), and, for SMB destinations, whether the destination can be browsed to at all. The imageCLASS countermeasures list carries the same code with the same centre of gravity. So #751 is the machine reporting that the conversation never started: the destination server is down, the network path is broken, or the machine's own network identity is incomplete (no IP address set is a real configuration state on a freshly installed or reset machine, and Canon names it explicitly). Its remedy list follows that reading: confirm the destination server is up and reachable, confirm the network connection, check the TCP/IP Settings, and — Canon's own suggestion where SMB browsing to the destination fails — use a different protocol to the same destination (FTP or WebDAV) if the server offers one. Diagnose #751 from the outside in: other devices reaching the same server clears the server; the machine printing fine over the network clears most of its network path, leaving its send-side settings; nothing reaching anything points at the network itself. What #751 never means is a credentials problem — Canon gives wrong passwords their own codes (#806, #839), and chasing logins under a #751 is the family's classic wasted hour.

#752: scan-to-email's server code — SMTP down, or the name is wrong

#752 is #751's counterpart for e-mail sending, and Canon's list gives it a two-part definition: the SMTP server is not functioning or the network is not connected — or the SMTP server name setting is incorrect, or the domain name or e-mail address is not set. That second half is what separates #752 from pure network failure: even with the server up and the network perfect, an imageRUNNER whose e-mail identity is incomplete (no domain name, no machine e-mail address configured) or whose SMTP server name is mistyped reports #752, because from the machine's side the send cannot be begun. The countermeasures follow in order: check the SMTP server and the network connection; then check the SMTP server name in Communication Settings; then confirm the domain name and the machine's e-mail address are set. The practical split an administrator should run is timing: a #752 on a machine that has never sent e-mail is a configuration story (the settings half of the definition) until proven otherwise; a #752 arriving on a machine that sent happily yesterday is a server/network story first. Note also #752's boundary with #802: Canon assigns 'SMTP server name incorrect' to both codes' neighbourhoods — #752 carries it as a possible cause alongside server-down, while #802 is specifically the name-resolution failure (next sections). The lists are the authority; where they overlap, work the checks in order — server, network, names, identity — and the machine will usually stop arguing at the step that was actually broken.

#753: a TCP/IP error mid-send — check the physical layer first

#753 is the family's transport failure: Canon's countermeasures list defines it as a TCP/IP error (a socket or select error) occurring while sending an e-mail or a Remote Fax. Where #751 and #752 describe a conversation that could not start, #753 describes one that broke in the middle — the connection opened, data moved, and the socket failed underneath it. Canon's remedy is strikingly physical for a settings family: check that the network cables and connectors are properly connected; if the error persists, turn the main power off and back on. That order encodes real diagnostic experience — intermittent socket failures on a wired office machine are cabling and connector faults (a lead half-seated in a wall port, a cable damaged by a chair leg or a cleaning crew, a switch port failing) far more often than they are configuration faults, and the power cycle clears the machine's network stack for a clean second attempt. The pattern-reading matters here too: a single #753 in a year is an event; #753 recurring on the same machine is a cable, a port or a switch path asking to be replaced, and recurring across several machines at once is network infrastructure, not copiers. Do not let #753 pull you into the mail settings — Canon's lists give it no settings cause at all, and the administrators who fix it fastest are the ones who start by reseating a cable, exactly as the countermeasure says.

#802: the name does not resolve — SMTP and DNS settings

#802 is the directory failure: Canon's list defines it as the SMTP server name specified in Communication Settings being incorrect, or the DNS server name being incorrect, or the connection to the DNS server having failed. The machine knows what it wants to reach but cannot turn the name it was given into an address — because the name is wrong (a typo, a decommissioned mail host, an internal name used from the wrong network), or because the resolver it asks is wrong or unreachable. This is the code that mail migrations leave behind: the organisation moves to a new mail platform, every desktop is reconfigured by policy, and the copier — configured once, years ago, by hand — keeps asking DNS for a server that no longer exists, reporting #802 against every scan-to-email job until someone updates its Communication Settings. The countermeasure is the definition restated: correct the SMTP server name in Communication Settings, and check the DNS server setting and its connection. Distinguish #802 from #752 at the outset because their fixes diverge in emphasis: #752 leads with the server and network (is anything there?), #802 leads with the names (is the machine asking for the right thing, of the right resolver?). A useful field test falls out of that split: if the machine sends successfully to a destination specified in a way that avoids the failing name, you have confirmed the resolution story without opening a single settings screen.

#806: the destination's credentials are wrong

#806 is the authentication failure at the destination, and Canon's list splits it by send type with care: when sending to a file server, the user name or password for that server is incorrect; when sending an e-mail or I-fax, the destination is incorrect. The file-server half is the common case in offices: scans to a shared folder authenticate with a stored account, and that account's password changes (or the account is renamed, locked or deleted) on the server's schedule, not the copier's — the copier keeps presenting the old credentials and the server keeps refusing them, job after job, each logged #806. The fix is to check and re-enter the user name and password stored for that destination, and to verify the destination itself (path, share, permissions) has not moved. Note Canon's discipline in separating #806 from #839: #806 is the destination's credentials — the file server's account, the address book entry's login — while #839 is the machine's own SMTP authentication (next section). They feel identical from the user's chair ('it says wrong password') and are completely different settings owned by different systems, which is why Canon bothers to keep them apart and why an administrator should too: changing the SMTP AUTH password will not cure a #806, and re-entering the file server's password will not cure a #839.

#839: SMTP authentication — the machine's own mail login is wrong

#839 is defined in Canon's imageCLASS countermeasures list in one precise sentence: the user name or password set in Communication Settings is incorrect — check the user name and password settings for SMTP authentication (SMTP AUTH) in Communication Settings. This is the copier's own identity at the mail server: when the mail server requires authenticated submission (as virtually all now do), the machine logs in as a mail user to send, and #839 says that login is being refused. The usual biographies are administrative: the mail account's password was rotated by IT policy and the copier was not updated; the dedicated 'scanner@' account was disabled or its licence changed in a mail-platform migration; the password was typed once, wrong, at installation and the machine has never sent. The fix is confined to the one place Canon names: Communication Settings, SMTP AUTH, correct current credentials — obtained from whoever owns the mail account, because the copier cannot tell you what the password should be, only that what it has is refused. One neighbour-code caution completes the picture: a machine whose SMTP AUTH was never enabled, on a server that requires it, can present in the #752/#801 neighbourhood instead; the lists are the authority, and the working method is to check the code you actually have, in Canon's words, before widening the search.

#801: timeouts, server refusals — and file-server permissions

#801 is the family's broadest code, and Canon's list defines it in layers that an administrator should peel in order. For e-mail: a timeout error occurred while communicating with the SMTP server; or the SMTP server returned an error; or the destination is incorrect. For file sending, Canon adds the destination-side causes: you do not have permission to write to the destination; a file with the same name exists that cannot be overwritten; or the folder name or password is incorrect. So #801 is the 'the conversation happened and failed' code — the server was reached (this is not #751) but the transaction did not complete: the server hung up or timed out, rejected the message (size, policy, a malformed destination), or, on the file side, refused the write for permission or naming reasons. The countermeasures are the causes re-read as checks: the destination's correctness, the SMTP server's state and its error (the server's own logs, which the administrator of the mail system can read, often say exactly why), and for folders, your write permission, the folder name and password, and the same-name file sitting in the way. #801's breadth is a diagnostic instruction in itself: because Canon packs several distinct failures under it, the job's details around the code (which destination, file or e-mail, how large the scan was) are what narrow it — the code alone opens the door, the log walks you through it.

#899: the code that is not an error

#899 deserves its own section precisely because it frightens people out of proportion to its meaning: Canon's lists define it as the e-mail or I-fax transmission having completed normally — sent successfully — with the caveat that reception may not have completed, because the transmission was relayed via multiple servers. In other words, your scan was sent; what the machine cannot do is prove the final hop, because the message passed through relaying servers beyond its session. Canon's countermeasures are confirmations, not repairs: check whether the I-fax was received (via POP RX / Check I-Fax RX), check whether an error notification was printed, or simply contact the other party to confirm receipt. Operationally, #899 in the log should be read as 'delivered as far as this machine can know' — the correct response to a user reporting it is reassurance plus, where the document matters, a delivery confirmation by another channel. Its presence in an error-code list is a filing quirk — the list is of codes that appear in the Results column, and #899 appears there — and learning to recognise it saves the most pointless service calls in this whole family: there is nothing to fix, nothing to reset, and nothing in Communication Settings that will make the machine more certain about a relay it does not control.

Scan-to-folder vs scan-to-email: the same codes, two different worlds

Canon's lists write several codes (#751, #801, #806) with split definitions — one branch for e-mail/I-fax, another for file servers — because the send function is one engine driving two very different destinations, and the split is the fastest diagnostic cut an administrator can make. If scan-to-email works and scan-to-folder fails, the machine's network, DNS and identity are proven by the working half, and suspicion concentrates on the file branch's own variables: the destination's credentials (#806), write permission and overwrite/folder details (#801), SMB browsability (#751's file branch). If folder works and e-mail fails, the inverse holds: the mail chain — SMTP server name (#802, #752), the machine's mail identity and domain (#752), its SMTP AUTH login (#839), server acceptance (#801) — is where the fault lives, and the file settings are innocent. If both fail together with the same code, read the code's shared branch first: #751 (server/network not there) and #753 (transport broke) are the two whose causes genuinely span both worlds. Canon's split definitions reward this discipline because each branch's countermeasures are different settings on different screens — the administrator who works 'the send problem' as one blob will open all of them; the one who splits by destination opens two.

The administrator's checklist: which Canon screen owns which code

Consolidating the countermeasures into the settings map they imply: TCP/IP Settings own the machine's network identity — the missing-IP-address branch of #751 lives there, and it is the first screen to check on a machine that has never sent or has just been reset. Communication Settings own the mail conversation — the SMTP server name (#802, and #752's settings half), the machine's e-mail address and domain name (#752), and the SMTP AUTH user name and password (#839) all live there, which is why three of this family's eight codes are cured on that one screen. The address book / destination entries own the per-destination facts — the file server's user name and password (#806), the folder path and its write permission and overwrite behaviour (#801) — entered per destination and forgotten there, which is why destination-specific failures (one folder fails, others work) are #806/#801 stories rather than machine stories. And the physical layer owns #753: cables, connectors, switch ports, then a main-power cycle. Keep that map and the family's logic is visible at a glance: codes cluster by the screen that cures them, and the code on the report is effectively Canon telling you which screen to open. The remaining skill is change-awareness — most # code outbreaks in real offices are caused by a change somewhere else (mail migration, password policy, new file server), and the checklist question 'what changed?' asked before any screen is opened solves the family faster than any single countermeasure.

Codes in the # range we could not verify

This guide covers the eight # codes whose definitions were verified word-for-word against two Canon manual sources (Canon's imageRUNNER ADVANCE 'List of Error Codes without Messages' and Canon's imageCLASS 'Countermeasures for Each Error Code', both on oip.manual.canon). Canon's complete # list is much longer — it runs across the whole #7xx and #8xx space and beyond, covering department ID and PIN problems, memory-full states, document-feeder and paper events during sending, fax-specific failures and more — and under this site's two-source rule, the codes between and around the verified eight (the unverified spans of #754-#800, #803-#805, #807-#838 and #840-#898, and every # code outside #751-#899) are named here by range only, with no meanings attached. That restraint is deliberate and worth understanding: the # codes are densely packed, adjacent numbers routinely belong to entirely different subsystems, and a meaning guessed from a neighbouring code is worse than useless on a machine whose settings screens are unforgiving. If your report shows a # code this page does not define, Canon's own manual for your exact model and function (the lists above, on oip.manual.canon, are searchable by code) is the authority — the code's Canon text is short, exact, and worth the two minutes it takes to read before changing any setting.

Key takeaways

Get the code from the log before touching settings: # codes appear in the job details (Status Monitor/Cancel) and in the Results column of the Communication Management Report — symptom-guessing wastes hours in this family.
Split every send failure by destination first: folder-only failures point at #806/#801 (credentials, permissions), email-only failures at #802/#839/#752 (names, SMTP AUTH, mail identity), both-together at #751/#753 (network, cabling).
#899 means your scan was sent — it is a delivery-confirmation caveat about multi-server relays, not a failure, and there is nothing to fix.

Resetting the Canon printer

Canon documents one general power reset for its printers, in the form given in Canon USA's B203 article and repeated across its support-code procedures: turn the printer off, unplug the power cord, wait at least two minutes, plug the cord back in, and turn the printer on. The LED-display manuals give the same motion in shorter form for undocumented errors (turn off, unplug, plug back in, turn on; if the error remains, contact the service centre). This reset clears transient internal states only — Canon's guidance is explicit for code families like B200-B207 that a code which reappears after the reset has given its verdict (there, likely print head hardware failure and service). Two standing cautions attach to the unplug step on Canon machines: on fax models (the MX line), unplugging deletes faxes stored in the printer's memory, so retrieve them first; and for imageRUNNER copiers, user power cycling is not an error clear at all — iR errors are cleared in service mode (COPIER > FUNCTION > CLEAR > ERR) by a technician after the fault is repaired, and repeated clearing of protection codes like E001 without repair defeats a safety function.