How Copier Scan-to-Email Blocks DMARC p=reject

Your DMARC aggregate reports look clean. SPF passes, DKIM passes, alignment looks good across the board. You publish p=reject and move on with your day. Then the service desk gets 40 tickets from the accounting department because nobody can receive scanned invoices.

The copier did it. Not maliciously. Not dramatically. It just kept sending scan-to-email through an ISP relay that SPF trusts but that DMARC alignment does not recognize.

This is one of the most common blockers to DMARC enforcement, and it has a well-defined technical cause.

Why Copier Scan-to-Email Fails DMARC Alignment

DMARC checks alignment in two ways. The first is SPF alignment, which compares the domain in the SMTP envelope (the MAIL FROM address) against the domain in the From header. The second is DKIM alignment, which checks whether the domain in the DKIM signature header matches the From header domain.

Most copier scan-to-email works like this: the device sends mail through an ISP SMTP relay. The ISP relay rewrites the envelope sender to its own domain. The From header, however, still shows your company domain. When your receiving partner's mail system checks DMARC, SPF alignment fails because the envelope MAIL FROM is the ISP's domain and the From header is your domain. DKIM alignment fails because the copier cannot sign with your DKIM key, even if your domain has one.

SPF technically passes at the ISP relay level. But DMARC does not care whether SPF passes at the relay. It cares whether the domains align. They do not.

The gap exists because most copier firmware does not support DKIM signing and most ISP SMTP relays do not preserve the original envelope sender. This is not a configuration error. It is how these systems were designed.

What Happens When You Publish p=reject Anyway

If you publish p=reject without addressing the copier problem, your receiving partners start rejecting scan-to-email from the copier fleet. The rejection is silent from the copier's perspective. The device shows sent. The recipient never receives the email.

In practice this means:

Invoices sent from the accounts payable scanner disappear
HR cannot receive scanned leave requests
Contracts routed through the front desk MFP never arrive

None of these failures generate bounce messages to the copier. The copier just keeps sending into a void.

This is the worst outcome of p=reject for many organizations: legitimate internal mail stops working and nobody gets an error message that points to the real cause.

The Four Options to Fix Copier Mail Under DMARC Enforcement

Option 1: Route through an authenticated relay with DKIM signing

Replace the ISP SMTP relay with a relay that authenticates the copier session and can sign DKIM on behalf of your domain. This requires a relay that supports SMTP AUTH and DKIM signing, either as a dedicated appliance or a cloud SMTP service configured to sign outbound mail.

The relay validates the copier session, then signs the outbound message with your DKIM key before sending it to the internet. From the receiving side, the DKIM signature validates against your domain and DMARC alignment passes.

This is the cleanest solution if your copier fleet is large and your organization has the infrastructure knowledge to manage a relay.

Option 2: Isolate scan-to-email on a subdomain with its own policy

Move scan-to-email to a dedicated subdomain, for example scan.yourdomain.com instead of yourdomain.com. Publish a DMARC record for yourdomain.com that goes to p=reject. Publish a separate DMARC record for scan.yourdomain.com that stays at p=none or p=quarantine.

This approach lets you enforce DMARC on your primary domain without disrupting the copier fleet. The tradeoff is that some receiving systems may still quarantine mail from the subdomain, and it requires DNS changes and copier firmware updates to change the From address.

Option 3: Configure copiers to send through M365 or Google Workspace SMTP

If your organization uses Microsoft 365 or Google Workspace, configure the copier to send through that provider's SMTP relay using the provider's credentials. Both platforms sign outbound mail with their own DKIM keys and pass DMARC alignment for the tenant domain.

This requires enabling SMTP authentication on the copier and setting up a dedicated send connector or app password in M365. It also means copier mail appears to come from your M365 or Google tenant, not from individual user addresses.

For organizations already in M365 or Google, this is often the fastest path because it uses existing infrastructure.

Option 4: Stop sending scan-to-email from your organizational domain

Treat scan-to-email as a legacy feature and migrate to a workflow that does not rely on email delivery. Options include:

Upload to a shared network drive or document management system instead of emailing directly
Use the copier's SMB or FTP output to a file server
Route scans through an internal web portal that delivers the file without email

This is the most secure option because it removes the copier mail problem entirely. It is also the most disruptive because it changes established workflows.

How to Audit Your Copier Fleet for Scan-to-Email Before Going to p=reject

Before you publish p=reject, you need to know three things about every device that sends scan-to-email:

What domain does it use in the From header?
What SMTP relay does it use?
Does the relay preserve the original envelope sender or rewrite it?

The fastest way to answer these questions is to look at your DMARC aggregate reports. Every DMARC aggregate report includes a source IP and the domains it claims to send for. If you see source IPs that are not your known mail infrastructure and they are sending as yourdomain.com, those are your copier relays.

DMARCFlow aggregate reports surface exactly which source IPs are sending as your domain and show the From header domain for each source, making the copier relay inventory fast to build without parsing raw XML.

Once you have the list, test each relay by sending a scan to a test address and checking whether it arrives or fails silently.

The Risk of Leaving Copier Mail Unresolved at p=none

p=none tells receiving mail systems to do nothing with mail that fails DMARC. It is a monitoring setting. Organizations treat it as a permanent policy and stay there for years.

The risk of indefinite p=none is that your domain is spoofable. Any third party that can send mail through an ISP relay can impersonate your domain in the From header and the mail will be accepted by most receiving systems. p=none gives you visibility into who is sending as your domain, but it does not stop anyone who wants to spoof you.

The copier problem is real but it is solvable. Treating it as an excuse to stay at p=none leaves your domain open to subdomain spoofing from every copier, scanner, and legacy device on your network.

FAQ

Why does copier scan-to-email fail DMARC even when SPF passes?

SPF checks whether the SMTP relay is authorized to send for the domain in the envelope. DMARC checks whether that same domain aligns with the From header domain. Most ISP relays rewrite the envelope sender to their own domain while leaving the From header as your domain. SPF passes because the relay is authorized. DMARC alignment fails because the two domains do not match.

Can I use a subdomain policy to isolate copier mail from main domain enforcement?

Yes. Publishing a separate DMARC record for a subdomain lets you apply a different policy to copier mail than to your primary domain. You can keep the subdomain at p=none while the main domain goes to p=reject. This requires adding a DNS record for the subdomain and updating copier firmware to use the subdomain in the From header.

What copier firmware supports DKIM signing?

Most enterprise MFP firmware from HP, Canon, Xerox, and Kyocera does not support DKIM signing as of 2026. This is a known gap. The practical solutions are routing through an authenticated relay or moving copier mail to a subdomain, rather than expecting the copier itself to sign.

How do I discover all devices sending scan-to-email before publishing p=reject?

Your DMARC aggregate reports list every source IP that sends mail as your domain. Cross-reference those IPs against your known mail infrastructure. Any IP that is not your M365 gateway, your SEG, or your known SMTP relay is likely a copier or other embedded device.

Should I let p=reject break scan-to-email as a forcing function for replacement?

That depends on how mission-critical scan-to-email is to your organization. If the copier fleet is small and replacement is planned, going to p=reject sooner can accelerate the replacement decision. If the copier fleet is large and replacement is not in the budget, solve the relay problem first and then go to p=reject. The goal is enforcement, not disruption.