Printers, scanners, alarms, and SaaS appliances sending as your domain: relay patterns that actually pass DMARC

When a printer, scanner, badge system, alarm panel, ERP, PSA, or random "notification appliance" sends mail as example.com, the problem is almost never the visible From: header by itself. The problem is what happens underneath it.

DMARC only passes when the From: domain aligns with either:

• the SPF-authenticated MAIL FROM domain
• the DKIM signing d= domain

That alignment model is the heart of DMARC in RFC 7489.

This is why so many device-generated messages fail after a DMARC rollout. The device can put alerts@example.com in From:, but it usually cannot:

• DKIM-sign mail with your domain
• manage a custom aligned bounce domain
• submit mail over modern authenticated SMTP the way a mailbox platform expects
• survive internet delivery if it sends directly from an office IP with weak reputation

So the practical question becomes: which relay pattern makes the final message look like legitimate mail from your domain to outside receivers?

Short answer

The relay patterns that pass DMARC reliably are usually these:

1. device or app submits to a mail system you control, and that system adds an aligned DKIM signature
2. device or app relays through Microsoft 365 or Google Workspace using the provider's supported submission or relay path
3. SaaS sender sends directly only if it supports custom DKIM and ideally a custom aligned return-path or bounce domain
4. very old devices relay to a local SMTP server first, and that server becomes the real outbound sender

The patterns that fail most often are also predictable:

• device sends directly to the internet from an arbitrary office IP
• SaaS platform uses your domain in From: but keeps an unrelated DKIM or bounce domain
• legacy appliance points at a cloud relay it cannot authenticate to correctly

If the device cannot produce aligned authentication itself, the fix is to make something after the device do that work.

Why these senders break DMARC so often

Devices and SaaS tools are awkward DMARC citizens for different reasons.

Devices and appliances

Printers, scanners, alarms, PBXs, NAS boxes, building systems, and old line-of-business apps often have only a few mail settings:

• SMTP server
• port
• maybe username and password
• maybe a From: address

That is not enough to guarantee DMARC alignment.

The device might authenticate to a relay, but the relay still decides the real envelope sender and whether DKIM gets added later. Or the device may not support TLS 1.2+, OAuth, or even authenticated submission at all.

Microsoft's guidance for multifunction devices reflects this reality. Exchange Online supports multiple sending methods, but they have very different boundaries: authenticated client submission, SMTP relay via connector, and Direct Send are not interchangeable, and Direct Send is not for internet delivery to arbitrary external recipients. Google's admin guidance makes the same point in a different way: if systems send through Google, the sending path still needs to fit Google's relay model and your SPF record needs to account for the real senders.

SaaS platforms

SaaS senders are usually better at mail transport, but they fail DMARC for a different reason: branding is easy, alignment is not.

A platform may happily let you set:

• From: billing@example.com
• display name
• reply-to

while still sending with:

• DKIM d=vendor-mail.example
• MAIL FROM=bounces.vendor.example

That can look fine to a human and still fail DMARC.

If you want the protocol background for that distinction, Return-Path vs From: why SPF can pass while DMARC fails is the right refresher.

The relay patterns that actually work

Pattern 1: submit to a mail system that will DKIM-sign for your domain

This is the cleanest default for devices and internal applications.

The idea is simple:

1. the device hands the message to a relay you trust
2. that relay becomes the real outbound sending system
3. the relay sends using an aligned SPF identity, an aligned DKIM signature, or both

In practice, the most durable version is aligned DKIM added by the relay or mailbox platform, because devices almost never generate DKIM correctly on their own.

A healthy flow looks like this:

scanner -> local relay or mailbox platform -> internet recipient

From: scans@example.com
MAIL FROM: bounce.example.com
DKIM d=example.com

That message can pass DMARC because the visible From: domain aligns with DKIM d=example.com, and it may also align on SPF depending on how the relay is configured.

This pattern works well when:

• the device can submit mail but cannot sign DKIM
• you need one consistent outbound control point
• you want central logs, queueing, retry behavior, and rate limits
• many devices share the same sending policy

It is also the pattern that creates the fewest surprises in DMARC aggregate reports, because the source you see becomes your relay tier rather than fifty incompatible appliances.

Pattern 2: authenticated submission through Microsoft 365

For devices or apps that can authenticate properly, Microsoft 365 client SMTP submission is often the simplest supported cloud path.

Microsoft documents that client SMTP submission sends authenticated mail through a cloud mailbox, requires authentication, and uses smtp.office365.com over port 587 or 25 with modern TLS support. Microsoft also notes an important operational constraint: if the device sends as an address different from the authenticated mailbox, the authenticated account needs Send As permission.

Why this pattern tends to pass DMARC:

• Exchange Online can send the message as part of your normal Microsoft 365 mail flow
• your domain can already have Microsoft 365 SPF coverage via include:spf.protection.outlook.com
• Exchange Online can apply aligned DKIM for your accepted domain when DKIM is enabled

This is usually a good fit for:

• modern scanners and apps that support authenticated SMTP submission
• lower-volume operational mail
• cases where you want the message associated with a real mailbox identity

This is a bad fit for:

• old firmware with weak TLS support
• appliances that cannot authenticate safely
• third-party hosted apps that are not supposed to log in as one of your mailboxes

Pattern 3: SMTP relay through Microsoft 365 connector-based mail flow

If the sender cannot use mailbox submission but your organization still wants Microsoft 365 to be the egress path, Microsoft's SMTP relay pattern is the more appropriate design.

Microsoft's documented model is explicit:

• the connector authenticates your source with a certificate or static public IP
• the sender uses your Microsoft 365 MX endpoint as smart host
• the sending address can be in an accepted domain even without a mailbox

That makes this pattern useful for:

• printers and scanners without mailbox semantics
• internal application servers
• devices that need to send as alerts@example.com or do-not-reply@example.com

But there is one detail people miss: this is still not "magic DMARC mode".

You still need the post-relay message to authenticate as your domain. Microsoft explicitly recommends updating SPF for the domain so the relay path is recognized, and aligned DKIM is still preferable when available.

Use this pattern when:

• the source has a stable public IP or certificate identity
• you need a supported relay instead of mailbox credentials
• the sender is inside infrastructure you control

Avoid it when:

• the sender is a third-party hosted SaaS app without your own fixed IP or cert path
• the source is too unstable to identify cleanly on a connector

Pattern 4: Google Workspace relay or submission paths

Google's guidance for sending from a printer, scanner, or app leads to the same operational lesson: choose a supported Google path, then make sure your domain authentication matches the real path.

For Google-managed sending, the safe patterns are generally:

1. authenticated submission for a device or app that can log in correctly
2. Google SMTP relay service for approved senders and IPs
3. outbound mail that is already covered by the sender inventory in your SPF record and, ideally, DKIM signing in Workspace

Google's SPF documentation is especially clear on the inventory point: your SPF record needs to include all mail senders for the domain, including third-party services and outbound gateways. That matters because admins often add a copier, app server, or relay and forget to update the domain's actual authorization model.

This pattern is usually solid when:

• the device can use the Google submission or relay settings you support
• Workspace is already signing mail with aligned DKIM
• your SPF record reflects Google's path and any additional approved senders

This pattern gets brittle when:

• the device is bypassing Google and sending direct anyway
• the message is using your From: domain but another platform's unaligned DKIM
• SPF was never updated after adding the relay path

Pattern 5: legacy device to local relay, local relay to the internet

Some devices simply cannot talk to Microsoft 365 or Google Workspace correctly.

Typical reasons:

• no modern TLS
• no authenticated submission support
• hard-coded port behavior
• no useful retry queue
• no ability to separate envelope sender from visible From:

In those cases, the right answer is often boring and effective: stop pretending the device is an internet sender.

Put a local SMTP relay in front of it.

That relay can:

• accept ugly or limited SMTP from the device
• rewrite the envelope sender into an aligned domain
• route through your real outbound platform
• apply DKIM signing directly or hand off to a system that does
• log and retry delivery like an actual mail system

That means the device is only speaking to a nearby trusted hop, while the relay is doing the DMARC-relevant work.

This remains one of the best designs for alarms, security systems, factory devices, and old embedded software that nobody wants to patch again.

Pattern 6: SaaS direct send only when the vendor supports alignment properly

For SaaS platforms, there is no reason to force everything through your own relay if the vendor already supports a correct aligned model.

The reliable direct-send pattern is:

1. custom DKIM signing for your domain
2. custom bounce or return-path domain aligned with your domain, or at least relaxed-aligned under the same organizational domain
3. SPF updated to authorize the vendor's documented sending infrastructure when SPF alignment is part of the design

If the SaaS platform supports only branded From: and nothing else, it is not really sending as your domain in a DMARC-safe way.

For delegated-signing setups, DKIM delegation with hosted keys covers the operational tradeoffs in more detail.

Use SaaS direct send when:

• the vendor supports custom DKIM for your domain
• the vendor documents the SPF or bounce-domain configuration clearly
• you want the vendor's infrastructure and retry model to stay intact

Do not use it when:

• the vendor only lets you change the visible sender address
• you cannot verify the delivered Authentication-Results
• you are trying to enforce p=reject and hoping branding alone will be enough

Patterns that look convenient but cause trouble

Direct-to-internet from the device itself

This is the classic copier mistake.

The device sends from a branch office IP with:

• From: no-reply@example.com
• no aligned DKIM
• no aligned MAIL FROM
• no real reputation or retry controls

Sometimes it works against a lenient receiver. Then DMARC enforcement tightens or a receiver gets stricter, and it falls apart.

Shared mailbox credentials used by everything

This can pass DMARC if the platform signs correctly, but it creates messy attribution, secrets sprawl, and accidental overuse of a single mailbox identity.

It is better than direct unauthenticated sending, but it is not always the best long-term pattern.

Vendor branding without authentication alignment

This is the SaaS version of false confidence. If headers show a vendor DKIM domain and a vendor bounce domain that do not align with your visible From:, DMARC can still fail even while the product UI says the sender is configured.

A practical decision tree

Use this order.

If the sender is a physical device or old internal app

1. Can it use modern authenticated submission to your mail platform?
2. If yes, use that.
3. If no, can it relay to a local SMTP server you control?
4. If yes, make that relay the real outbound sender and signer.
5. If no, do not let it send as your primary domain to the open internet.

If the sender is a SaaS platform

1. Does it support custom DKIM for your domain?
2. Does it support an aligned custom return-path or bounce domain?
3. Can you verify delivered headers at a real receiver?
4. If yes, let it send directly.
5. If no, route mail through a service or design that can create alignment another way.

How to verify the chosen pattern actually passes DMARC

Check a delivered message header, not just the vendor setup screen.

Look for:

1. dmarc=pass
2. header.from=example.com
3. aligned dkim=pass header.d=example.com or aligned spf=pass smtp.mailfrom=...example.com

Remember the exact DMARC rule from RFC 7489: one aligned SPF or DKIM pass is enough.

If the message fails, compare:

• visible From: domain
• SPF-authenticated smtp.mailfrom domain
• DKIM header.d domain

That usually reveals the real problem in a minute or two.

If you need help reading those headers, How to troubleshoot Authentication-Results for DMARC, SPF, and DKIM walks through the process.

What to look for in DMARC aggregate reports

These senders often show up in aggregate reports before anyone notices missing mail.

Common signs:

• one office or ISP IP sending mail for your domain with SPF pass but DMARC fail
• a vendor cluster showing DKIM pass on the wrong domain
• lots of tiny-volume sources with the same visible From: domain and no aligned result

That is why a good sender inventory built from DMARC reports matters so much for device and SaaS cleanup.

Key takeaway

Printers, scanners, alarms, and SaaS tools do not pass DMARC because they say they are sending as your domain. They pass DMARC because the final delivered message has aligned SPF or aligned DKIM for that domain.

In practice, the relay patterns that work are the ones where a real mail system, not the edge device, does the hard part:

• authenticated submission through Microsoft 365 or Google Workspace
• SMTP relay through a controlled connector or approved relay path
• local relay in front of legacy appliances
• direct SaaS sending only when the vendor supports proper alignment for your domain

If the sender cannot create aligned authentication, move the message through something that can.