Scan-to-Email Passes Test but Real Mails Fail — SPF/DKIM/DMARC & Size Limits

Joe B.

Expert ★★★★★ 27,853 satisfied customers

Specialities: MFP Scan-to-Email, Microsoft 365/Exchange Online, Google Workspace SMTP, SPF/DKIM/DMARC, Security Hardening

Scan-to-email test works but real jobs fail — SPF/DKIM/DMARC alignment, SMTP relay, size & policy limits

Technician

Let’s sort this out. Your scan-to-email button says the SMTP test is successful, but real scans never arrive or bounce later — classic sign of SPF/DKIM/DMARC or message size / policy limits blocking your MFP.
To target the fix fast: which mail system are you using (Microsoft 365 / Exchange Online, Google Workspace / Gmail SMTP, on-prem Exchange, other SMTP relay)? What From address is configured on the copier? And do failed jobs produce an NDR like 5.7.23, 5.7.1, 550, 552 or just silently disappear?

Customer

We’re on Microsoft 365. The copier’s SMTP test passes on port 587 with TLS. But actual scan-to-email jobs to external recipients never show up. Internal sometimes work. From address is just scanner@ourdomain.com. No idea about SPF or DKIM.

Technician

Got it — very common with scan-to-email on Microsoft 365.
The built-in SMTP test usually only checks “Can I log in and talk TLS on port 587/SMTP AUTH?”. Real messages must also pass:

• SPF — sending IP or relay must be authorized for yourdomain.com.
• DKIM — signed by Microsoft 365 or your gateway.
• DMARC — checks alignment between From domain, SPF, and DKIM.
• Antispam & malware filters — large PDFs, scans to many recipients, or generic senders like scanner@ can be quarantined.

If the MFP uses SMTP AUTH with a user, but the visible From is different, DMARC alignment fails and external servers drop or junk the mail. Let’s fix the account, SPF, and size limits so scans deliver reliably.

Customer

Some external recipients get a bounce with 550 5.7.23. Others say it’s in spam or never shows. Internal scans to our own mailboxes are mostly fine.

Technician

Step 1 — Fix SPF/DKIM/DMARC alignment for scan-to-email
Here’s the safe pattern for Exchange Online / M365 scan-to-email:

1. Create or use a dedicated mailbox like scanner@yourdomain.com in Microsoft 365.
2. On the MFP, configure SMTP AUTH with that account (username/password) on smtp.office365.com:587, STARTTLS.
3. Set the From address on the copier to exactly scanner@yourdomain.com. Do not spoof users’ addresses unless you fully understand DMARC alignment.
4. Check your SPF record includes Microsoft 365: v=spf1 include:spf.protection.outlook.com -all (or equivalent).
5. Ensure DKIM is enabled for your domain in M365, and DMARC is not set to reject while misaligned.

With this, real scan-to-email traffic is authenticated (SPF), signed (DKIM), and DMARC-compliant, so external servers stop rejecting those MFP emails.

Customer

We were using the copier to send as each user, like “From: alice@ourdomain.com” without their credentials. Could that be it?

Technician

Exactly. With DMARC enforcement, an MFP spoofing users without matching SPF/DKIM will fail:

• SPF fails because the sending IP / connector doesn’t match the visible From domain.
• DKIM fails because the message isn’t signed correctly for that user/domain.
• DMARC policy (quarantine/reject) kicks in — external mail is dropped.

Recommended approach:

• Use one authenticated scan account as From, e.g. scanner@yourdomain.com.
• Insert the user’s address in Reply-To or in the subject/body (“Scanned for alice@yourdomain.com”).
• If you must send as different addresses, configure a proper Exchange Online connector or authenticated SMTP relay that aligns with DMARC.

This “test success but real emails fail” pattern disappears once From and authentication are aligned.

Customer

Some smaller scans go through after that, but big multi-page color scans still fail randomly. Any idea?

Technician

Step 2 — Check message size & attachment limits
Your scan-to-email tests usually use tiny messages; real jobs hit:

• MFP attachment size limit (e.g. 10–20 MB per job).
• SMTP server max size (e.g. 25–35 MB in Microsoft 365, Google Workspace, or on-prem Exchange).
• Recipient limits (too many addresses → 552 / 4.5.3 errors).
• Content filters triggered by huge TIFF/PDF scans.

Fixes:

• On the copier/MFP, change file type to PDF (compact) or Mono and set reasonable DPI (200–300).
• Confirm SMTP max message size and increase if policy allows.
• Limit recipients or use a shared mailbox / distribution list instead of 20 direct addresses.

If big scans stop at the MFP with no bounce, check its logs; if they hit the server and get dropped, we review SMTP & transport logs.

Customer

One site uses an ISP SMTP relay on port 25 without auth. Scan-to-email test passes there too, but external partners don’t receive PDFs. Could that be blocked?

Technician

Step 3 — Validate SMTP relay, ports & reputation
For unauthenticated scan-to-email over port 25:

• Ensure your relay’s IP is in your domain’s SPF record.
• Check reverse DNS (rDNS) and HELO/EHLO match — some providers reject if they don’t.
• Avoid using consumer ISP relays that many destinations treat as suspicious.
• Use authenticated SMTP with TLS (587/465) whenever possible to improve deliverability and DMARC alignment.

The test script doesn’t see recipient-side reputation or DMARC; real scan-to-email jobs do — that’s why they fail while tests “succeed”.

Customer

We also noticed some scans are in Microsoft 365 quarantine. Others are missing entirely. How do we properly verify everything?

Technician

Step 4 — Confirm scan-to-email delivery & tune policies
To be sure your MFP scan-to-email configuration is solid:

1. Send a test scan to:
   • Internal mailbox
   • External Microsoft 365 / Gmail address
   • A third-party domain
2. Review message trace / email logs (M365, Google Workspace, or your SMTP gateway) for DMARC/SPF/DKIM results and size status.
3. Check quarantine — release and mark legitimate scans as safe.
4. Adjust anti-spam policies for your scan account: lower spam score sensitivity for that sender, but keep malware scanning enabled.

Once logs show SPF=pass, DKIM=pass, DMARC=pass and size is under limits, both internal and external scan-to-email jobs should deliver consistently.

Customer

That makes sense. Can you summarize the exact settings we should use so scans stop failing?

Technician

Summary: When scan-to-email passes the SMTP test but real messages fail, the fix is:

• Use a dedicated, authenticated scan account and match the visible From address.
• Update SPF to include your SMTP relay or Microsoft 365 / Google Workspace.
• Enable DKIM and configure DMARC with proper alignment.
• Respect attachment & message size limits, lower DPI, and use compact PDF.
• Verify via message trace/quarantine instead of trusting the built-in “Test” button.

Want an expert to quickly review your DNS, connectors, and MFP settings live? Open the chat and we’ll walk through it step-by-step.

Quick answer: the accepted fix

Accepted fix when scan-to-email test passes but real mails fail: use an authenticated scan account with matching From, ensure your SMTP relay IPs are in SPF, enable DKIM, align DMARC, and keep scan attachments under the configured message size limits. Always confirm using message trace and quarantine, not just the copier’s “Test” button.

FAQ

Step-by-step: stabilize scan-to-email delivery

1. Create a dedicated mailbox (e.g. scanner@yourdomain.com) in your mail system.
2. Configure the MFP to use SMTP AUTH with TLS (port 587 or provider-recommended) for that account.
3. Set the MFP’s From address to exactly that mailbox; use Reply-To for individual users if needed.
4. Update your SPF record to include the SMTP service or relay sending scans.
5. Enable DKIM for your domain and publish the keys.
6. Deploy a DMARC record and confirm alignment via reports and message trace.
7. Optimize scan settings (DPI, color, compression) to stay within message size limits.
8. Test to multiple external domains and verify results in logs/quarantine.

Note for mixed environments & cloud services

1. For Google Workspace, use authenticated SMTP on smtp.gmail.com:587 or an SMTP relay with your IPs in SPF.
2. For Exchange Online, prefer authenticated submission or a connector-based relay tied to trusted IPs.
3. Ensure any third-party cloud scanning or secure email gateway is also included in SPF/DKIM/DMARC design.

Sources

• Microsoft — Set up multifunction devices to send email with Microsoft 365
• Google — Send email from a printer, scanner, or app
• DMARC.org — DMARC overview

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.