Should a printer use the SMTP relay or the Gmail SMTP server?

If it only mails colleagues inside the company, the restricted Gmail SMTP server is the simplest option because it needs no authentication. If it mails anyone outside, use the SMTP relay service. The Gmail SMTP server is the one to avoid for shared devices, because it authenticates as a single person's mailbox and stops working the day that account is deleted.

Does mail sent through the SMTP relay pass DMARC automatically?

No. The relay settings decide whether Google accepts the message from your device, not whether the message aligns for DMARC. Alignment depends on your SPF record authorising Google, DKIM being turned on for that domain in the Admin console, and the From domain matching one of them. The only way to confirm it is to send a real message through the relay and read the Authentication-Results and DKIM-Signature headers on the copy that arrives.

We cannot find who set up the app that sends our invoices. Where do we start?

Publish a DMARC record at p=none with a reporting address and give it two weeks. The aggregate reports list every source sending as your domain, which is the inventory nobody has. Then compare that list against the relay's allowed senders, the per-user outbound gateway setting, and the app passwords on each account.

Google Workspace SMTP relay: setup, limits and DMARC traps

Say a 14-person distributor sends three kinds of mail that nobody in the office thinks of as mail. The warehouse printer emails scanned delivery notes. The accounting app emails invoices. The website emails order confirmations. All three leave with the company domain in the From line, and all three were set up years ago by somebody who no longer works there.

That arrangement holds until something makes it visible. A DMARC report arrives listing sources nobody can name, or Gmail starts rejecting the invoices, or a customer's security questionnaire asks which systems are authorised to send as your domain and the honest answer is that no one has the list. Google Workspace offers three separate ways for a device or an app to send mail, plus two user-level settings that can move sending off your infrastructure entirely. They authenticate differently, they have different ceilings, and they fail with different bounce text. Here is how we take that apart, in the order we do it.

Three ways Google will send for you, and what each one asks of you

Google documents three options for mail from a printer, a scanner or an app. The figures below are from Google's admin help, checked 5 October 2026.

The SMTP relay service, at smtp-relay.gmail.com on port 25, 465 or 587. An administrator turns this on for the organisation, and each user in the organisation can relay messages up to 10,000 recipients per day. This is the option for anything that sends in volume, or sends to anyone outside the company.
The Gmail SMTP server, at smtp.gmail.com. It authenticates as one person's mailbox and the sending limit is 2,000 messages per day. Fine for a single app sending a few notifications.
The restricted Gmail SMTP server, at aspmx.l.google.com on port 25. No authentication at all, and in exchange it delivers only to Gmail and Google Workspace users. Good for a scanner that mails colleagues, useless for anything that mails customers.

The option that gets picked by accident is the second, because it needs no administrator and no conversation. Somebody generates an app password on their own account, pastes it into the website, and the order confirmations go out tied to that one mailbox. Then that person leaves, the account is deleted, and the confirmations stop for no reason anyone can find. A customer always notices before the company does.

What the relay settings actually control

The relay lives in the Admin console under Apps, then Google Workspace, then Gmail, then Routing. Three groups of settings, each answering a different question.

Allowed senders answers who may put an address in the From line. The tightest option is only registered users in your domains, which requires the sender to be a Workspace user in one of your domains. It widens from there to any address within your domains, then to any address at all. That last setting is the first thing we look at on an inherited account: a relay scoped to any sender will send on behalf of addresses you do not own.

Authentication answers which machines may connect. Two boxes, and you can check one or both: accept mail only from the IP addresses you specify, or require SMTP authentication, which identifies the sending domain and needs the connection to arrive over TLS. Checking neither is what turns a loose allowed-senders setting into a dangerous one.

Require TLS encryption answers whether the connection has to be private. Google is explicit about the trade: if your mail server does not support TLS and you check the box, messages not sent over an encrypted TLS connection are rejected. Google's guidance pairs TLS with port 587, and lists ports 25, 465 and 587 without it.

The combination we set up

For a small business with a handful of sending devices we set all four at once: allowed senders restricted to your own domains, an IP allowlist naming the office and the server, SMTP authentication required, TLS required on port 587. If one device genuinely cannot do TLS or SMTP authentication, that belongs in the findings rather than in a looser rule for everything.

The two settings that move sending off your domain

Gmail also lets a user add other addresses to their account and send as them, which is how one person ends up sending as billing@ too. On its own that is a feature, and the mail still goes through Google.

The setting to know about is per-user outbound gateways, under Apps, then Google Workspace, then Gmail, then End User Access. Turning it on lets users send mail through an external SMTP server when they configure a From address hosted outside your email domains. The mail then leaves through somebody else's server, and Google notes the consequence directly: if that gateway modifies outgoing messages they will likely fail DKIM authentication, which makes an accurate SPF record more important rather than less.

This is what explains the DMARC report nobody can decode. If an employee wired their Gmail to an old host's SMTP server, the mail is on your domain, from an IP you do not control, with no signature of yours attached, and the relay configuration will not show it because the relay is not involved.

The header settles what the Admin console cannot

The Admin console tells you what is permitted, not what a message looked like by the time it reached Gmail, and the second is what decides the DMARC result. So we send one real message down every path we found, receive it at an outside address, and read two lines of the raw source.

The first is Authentication-Results, which records what the receiving server concluded about SPF, DKIM and DMARC. The second is the d= value inside DKIM-Signature, the domain whose key signed the message. If d= is your domain, DKIM aligns for that sender. If it is anything else, DKIM does not align on that path and the DMARC result rests entirely on SPF, the fragile half. Full walkthrough: reading email headers.

SPF, DKIM, and the alignment that decides the result

Three things have to be true for relayed mail to authenticate, and two out of three is the usual score. First, SPF has to authorise Google, in one record per domain:

example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com ~all"

Every other system that sends as the domain needs its own include or ip4 term in that same record, and the whole thing has to stay inside the ten DNS lookups the standard allows. That ceiling arrives faster than people expect once a CRM, a newsletter platform and a store are in there, and the fix is not a second SPF record: SPF too many DNS lookups.

Second, DKIM has to be turned on for the domain in the Admin console and the google._domainkey record published in DNS. Until it is, the signature on your outbound mail is not carrying your domain and the alignment check has nothing of yours to match. Gmail's sender guidelines ask for a key of at least 1024 bits and recommend 2048 where the DNS provider supports it. The Workspace failure modes are specific enough that we gave them their own post, DKIM fail on Google Workspace.

Third, and this is the part that gets skipped, the two have to align. For mail sent directly, the organisational domain in the From header has to match either the SPF domain or the DKIM domain. Only one of the two needs to align for DMARC to pass, which is why a domain can look healthy while half its sending paths sit one DNS edit away from failing. One threshold is worth knowing: senders of more than 5,000 messages a day to personal Gmail accounts count as bulk senders and need SPF, DKIM and DMARC, not one of them.

The bounces, decoded

When a relay path breaks, the device usually swallows the error and the company hears it from a customer. If you can reach the log, Google's wording maps cleanly to a cause.

550 5.7.1 Invalid credentials for relay. The registered IP does not match the domain of the account the message is sent from, or the envelope sender is empty or on an unregistered domain. Google's remedy: configure the server to use SMTP authentication to identify the sending domain, or to present one of your domain names in the HELO or EHLO command.
Mail relay denied. The mail is coming from a domain or an IP that is not registered in the relay settings. Usually an office that changed internet providers, or a server that moved.
550 5.4.5 Daily SMTP relay limit exceeded for user. One mailbox has run through its allowance, usually because every device points at the same account.
550 5.7.1 Daily SMTP relay sending limit exceeded for this customer. The whole organisation has hit its ceiling, which on a small account usually means a loop.

A per-user limit only helps when the users differ, which is why each sending system gets its own account.

What we check on a client account, in order

Every system that sends as the domain, written down. Two weeks of DMARC aggregate reports at p=none gives the real inventory, including the systems nobody mentioned.
The relay rule itself. Allowed senders, the IP list, SMTP authentication, TLS, tightened in that order, because allowed senders is where the exposure is.
Per-user outbound gateways and send-as addresses. Who has them, pointing where, and whether anyone still needs them.
App passwords. Which accounts have them, what they are wired into, and whether any belong to someone who has left.
SPF, DKIM and alignment on each path. One test message per path, headers read, result recorded against its source.
The policy, last. Only once every legitimate path aligns is it safe to move DMARC up, and that rollout order is its own job: moving DMARC from p=none to p=reject.

Step four finds the ugliest surprises. An app password outlives the conversation that created it and keeps working until the account is suspended. If you have never audited them, assume there are more than you expect: mail being sent as your domain.

How Guanacos Tech helps

Most of this work is inventory, not configuration. The relay takes twenty minutes to set up correctly and far longer to prove nothing else is quietly sending as the domain, so we treat the two as one job. We do it for small and mid-sized companies across North America and Latin America, in English and Spanish, through our Google Workspace consultants engagements. A 30-minute call is enough for us to read your relay rule, your SPF and DKIM records and one set of raw headers, and say which sending paths would survive a strict DMARC policy.

Google Workspace SMTP relay and Send mail as: the senders on your domain nobody can account for