Read the bounce before you touch anything

Gmail's rejection is not one error. It is several different problems that all get shortened to "550 5.7.1" in conversation, and the exact enhanced status code plus the sentence after it tells you which one you actually have.

"550-5.7.1 ... Our system has detected that this message is suspicious due to the very low reputation of the sending domain" means Gmail evaluated your domain's sending history and decided it looks enough like a spam source that it will not accept mail from it right now. This is a domain reputation problem, and Google Postmaster Tools built that record over time.

A close cousin, "low reputation of the sending IP address," is the same rejection scoped to the IP instead of the domain. If you send through Google Workspace, that IP belongs to Google, not you, so the block usually points to something else on shared infrastructure, or to a third-party server whose IP carries a bad history that has nothing to do with your domain.

A third message, "550-5.7.26, This mail is unauthenticated," is not a reputation problem at all. Gmail could not verify SPF or DKIM for that specific message and rejected it outright rather than judging it on reputation. That is Google's sender authentication requirement doing its job: since February 2024, every sender needs SPF or DKIM to pass, and bulk senders, roughly 5,000 messages a day or more to personal Gmail addresses, need both to pass plus a DMARC record.

Save the full bounce, not just the headline. It usually carries a link to Google's own explanation and, more importantly, the exact code that tells you whether you are dealing with reputation, authentication, or something else entirely. Treating "unauthenticated" as a reputation problem burns weeks on a warmup plan that was never going to fix it.

Step 1: authenticate everything, then check alignment

Before assuming reputation is the culprit, rule out authentication. Domains that used to pass SPF and DKIM drift out of compliance the moment a new tool starts sending on their behalf, an invoicing platform, a CRM, a marketing tool, without being added to the SPF record or given a DKIM selector.

Check three things on the domain the bounce names:

• SPF: the TXT record has to include every service sending on your behalf, and it has to resolve to a pass for the IP that is actually sending the message.
• DKIM: outbound mail needs a valid signature that verifies against the public key published at the matching selector._domainkey TXT record. On Google Workspace, DKIM is off by default per domain until you generate and publish that key in the Admin Console.
• DMARC: the domain needs a DMARC record, even p=none, and the visible From header has to align with either the SPF domain or the DKIM signing domain. Gmail's bulk sender rules only require one of the two, but aiming for both is the safer target.

Send a real test message to a Gmail address you control, open it, choose "Show original," and read the Authentication-Results header for that exact send. Confirm SPF=pass, DKIM=pass, and DMARC=pass. Fix whichever one fails before you spend any time on reputation, because a broken authentication record sitting under a reputation problem makes the bounce reason shift unpredictably between the two.

Step 2: check what Postmaster Tools actually says

If authentication is clean and you are still bouncing, Google Postmaster Tools is the only place that shows Google's own view of your sending history. It needs domain ownership verification and a real volume of DKIM or SPF authenticated mail to Gmail addresses before the dashboards populate, so sign up now if you have not.

Two dashboards matter here. Domain reputation and IP reputation are each rated High, Medium, Low, or Bad. Google defines High as "a history of very low spam rates" that complies with the sender guidelines, and Bad as "a history of sending a high volume of spam regularly," where mail is "almost always marked as spam or rejected by the receiving server." If your domain sits at Low or Bad, that rating, not anything visible from your own inbox, is producing the 550 5.7.1 bounce.

Spam rate is the percentage of your messages that reach an engaged recipient's inbox and then get manually marked as spam. Google's guidance is to stay under 0.10% and treat 0.30% as a hard ceiling. Cross it and you lose eligibility for Google's own delivery mitigation support until you hold under 0.30% for seven consecutive days.

Google has also flagged that the IP Reputation and Domain Reputation tabs specifically will eventually be deprecated, with no firm date given. Treat spam rate and authentication as the more durable signals to build your monitoring around going forward.

Step 3: stop the bleeding before you try to fix reputation

Reputation is backward looking. Every message you keep sending into a block adds another bad data point to a history Google is already unhappy with. Before anything else:

• Pause or sharply cut Gmail-bound volume, especially on any list you cannot prove is opted in and currently engaged.
• Pull anyone who has not opened or clicked in the last 90 to 180 days off active sending. Stale lists are the most common driver of a rising spam rate, because recipients who no longer recognize the sender are the ones most likely to hit "report spam" instead of unsubscribing.
• Look for a leftover send that is still running: a scheduled campaign, an automation, a compromised account relaying spam through your domain. A reputation collapse that lines up with one specific date is usually one identifiable sender behaving badly, not a slow organic decline.
• If you qualify as a bulk sender, add the one-click unsubscribe headers Google requires, List-Unsubscribe and List-Unsubscribe-Post, so recipients who no longer want the mail have an easy way out that is not the spam button.

Step 4: rebuild it deliberately

Once the bad signal is removed, Google's own advice for recovering reputation matches its advice for any new sender: start with low volume to your most engaged recipients and increase it slowly, avoiding sudden spikes. Google has not published a day-by-day schedule, so treat any "14-day warmup calendar" you find elsewhere as someone's estimate, not policy. What stays consistent across sources is the direction: small volume to people who open and reply, watched closely, expanded only when the spam rate and reputation dashboards hold steady or improve, not on a fixed calendar.

Expect this to take weeks, not days. The reputation dashboards in Postmaster Tools are historical, so one clean week does not erase a bad month.

When the reputation problem is not yours to fix directly

If you send through Microsoft 365, Zoho, or shared hosting SMTP, the IP behind your mail may be shared with hundreds of other tenants. Google's own guidance is direct about this: "The activity of any senders using a shared IP address affects the reputation of all senders" on it. If Postmaster Tools shows IP reputation at Low or Bad while domain reputation looks fine, someone else on that shared IP is the likely cause. The fix is working with the provider to isolate or rotate the IP, or moving to a setup where you control, or can request, a dedicated sending path. Domain reputation is the lever you fully control. IP reputation on shared infrastructure often is not.

New domains start with no reputation, not bad reputation

A brand-new domain, or one that has never sent meaningful volume to Gmail, does not have a low-reputation bounce waiting for it. It has no reputation at all, which Postmaster Tools may simply show as no data yet. Sending a large batch through a new domain on day one looks identical to an attacker spinning up a throwaway domain to send spam, and Gmail treats it accordingly. The fix is the same slow-start principle as a recovery: authenticate first, send small and consistent volume to real recipients, and let the domain build a track record before you rely on it for anything time-sensitive.

How Guanacos Tech helps

Most 550 5.7.1 cases we see are a mix of two or three of the causes above stacked on top of each other, a DKIM selector that quietly stopped verifying, a marketing tool nobody added to SPF, and a stale list someone kept mailing anyway. We run the diagnosis (authentication, Postmaster Tools reputation, spam rate history, list hygiene), fix the DNS and sending practices in the right order, and stay on the reputation recovery through the warmup period so you are not guessing at when it is safe to send at normal volume again. If you want a second set of eyes on your specific bounce, book a reputation review call.

Sources

• Postmaster Tools dashboards - Gmail Help
• Email sender guidelines - Google Workspace Admin Help
• Email sender guidelines FAQ - Gmail Help
• Prevent mail to Gmail users from being blocked or sent to spam

Why Microsoft 365 mail fails at Gmail when the tenant looks healthy

Exchange Online will send your mail whether or not your domain is authenticated. That is the part that fools people. Messages leave the tenant, the Sent folder fills up, nothing in the admin center is red, and yet a customer on Gmail says your quote landed in spam, or a bounce comes back saying the message was not authenticated.

On a Microsoft 365 domain the cause is almost always the same three-part story: SPF got published when the domain was added, DKIM for the custom domain was never switched on, and DMARC was never published at all. Microsoft signs outbound mail with your tenant's onmicrosoft.com domain until you enable DKIM for the custom domain yourself. So a signature exists, it just carries the wrong domain, and it does nothing for the address your reader actually sees in the From header. You end up authenticated by SPF alone, which is the fragile half: SPF breaks on any forwarded message, and there is no DKIM signature on your own domain to fall back on.

The three records, in the order that avoids downtime

Publish SPF first, DKIM second, DMARC last. Each record proves something different, and DMARC is the only one that can start rejecting mail, so it goes in after the other two are confirmed working.

• SPF says which servers are allowed to hand your mail to the internet. It is checked against the envelope sender, the address in the SMTP MAIL FROM command, not the From header your reader sees.
• DKIM attaches a cryptographic signature to the message. The receiver fetches the public key from your DNS and confirms the message was signed by whoever controls that domain and was not altered in transit.
• DMARC ties either result back to the domain in the visible From header, and tells receivers what to do when neither one lines up. A message passes DMARC when SPF or DKIM passes and the domain it passed for aligns with the From domain. One of the two is enough, which is exactly why the missing one matters.

SPF: one include, and the lookup budget you spend after it

For a tenant that only sends through Exchange Online, Microsoft documents a single record:

example.com.   TXT   "v=spf1 include:spf.protection.outlook.com -all"

The -all at the end is a hard fail: anything not authorized should be rejected. Microsoft documents both that and the softer ~all. Start with ~all if you are genuinely unsure you have found every sender, then tighten to -all once your DMARC reports have shown you the full list. Never publish two SPF records for the same domain. If one already exists, merge the include into it.

That record is cheap. It stops being cheap the moment you add a CRM, an invoicing system, a marketing platform and a helpdesk, because RFC 7208 section 4.6.4 caps SPF evaluation at 10 DNS lookups and requires receivers to return permerror past that. Every include, a, mx, ptr, exists and redirect term costs a lookup, including the ones nested inside somebody else's include. ip4 and ip6 entries cost nothing, which is why hybrid setups list their on-premises outbound addresses directly instead of adding another include:

example.com.   TXT   "v=spf1 ip4:203.0.113.25 include:spf.protection.outlook.com -all"

Count the live record with a checker that follows nested includes, not by counting the entries you can see. We walked through the counting and the ways out of it in the SPF lookup limit guide.

DKIM: two CNAMEs, and why Microsoft asks for two

Microsoft 365 uses two selectors per custom domain, selector1 and selector2, so it can rotate signing keys without leaving a gap. You publish two CNAME records pointing at keys Microsoft holds for your tenant:

selector1._domainkey.example.com.   CNAME   selector1-example-com._domainkey.contoso.onmicrosoft.com.
selector2._domainkey.example.com.   CNAME   selector2-example-com._domainkey.contoso.onmicrosoft.com.

Read the exact values out of the portal instead of building them by hand. The pattern is predictable, but the tenant name inside the target has to be right or the lookup resolves to nothing. In the Microsoft Defender portal these sit under Email and collaboration, Policies and rules, Threat policies, DKIM. Microsoft rearranges that menu periodically, so search the portal for DKIM if it is not where you expect it.

Order matters here too. Publish both CNAMEs, wait for them to resolve, then enable signing for the domain. Enabling first fails, because Microsoft checks that it can read the keys before it will sign with them. Key length is worth a look on older tenants: 2048-bit is the current standard, and a configuration created years ago may still be running 1024. In Exchange Online PowerShell that lives on the signing configuration, for example New-DkimSigningConfig -DomainName example.com -KeySize 2048.

Once signing is on for the custom domain, outbound mail is signed with that domain instead of the onmicrosoft.com one. That single change is what turns DKIM from decoration into an identifier DMARC can actually use.

DMARC: publish at p=none, then read the reports

The record is a TXT entry on the _dmarc subdomain:

_dmarc.example.com.   TXT   "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

p=none changes nothing about delivery. It asks receivers to send you aggregate reports naming every IP address sending as your domain, and whether SPF and DKIM passed and aligned for each one. That list is the only honest inventory of your senders, and it is always longer than the one in your head: the accounting system, the scheduling tool someone signed up for, the scanner in the back office.

Leave it at p=none for about two weeks, fix each legitimate sender until it aligns, then move to p=quarantine and finally p=reject. Enforcement is the whole point, and Microsoft's guidance walks the same monitor, quarantine, reject path, but jumping straight to reject on a domain you have not inventoried is how invoices stop arriving. Worth knowing in the other direction as well: Exchange Online Protection evaluates DMARC on inbound mail and honors the policy the sending domain published, so your own enforcement also protects your staff from mail spoofing your domain. Microsoft publishes a separate guide for putting DMARC reporting on parked domains and on the tenant's onmicrosoft.com routing domain, both worth doing once the primary domain is settled.

The alignment traps specific to Microsoft 365

Four things break alignment on tenants that otherwise look configured:

1. The onmicrosoft.com signature. The most common one by a wide margin. A DKIM pass reading header.d=contoso.onmicrosoft.com when your From address is at example.com does not align, and DMARC ignores it entirely.
2. Subdomains. A DMARC policy covers subdomains through the parent unless you override it with sp=. If a subdomain sends real mail from a different platform, give it its own SPF and DKIM rather than discovering it in a reject report.
3. Microsoft services that are not Exchange Online. Workflow automation and a CRM's own mail engine send on your behalf from infrastructure your Exchange include does not cover. They are separate senders and need their own authorization or their own DKIM signing, exactly like an outside vendor would.
4. Relays and connectors. An appliance, a website form on shared hosting, or an on-premises server routing outbound mail through a connector all add an address to the chain. If it is not in SPF and the message is not DKIM-signed on your domain, it fails.

Verify on a real message, not on a checker

DNS checkers tell you that a record exists and parses. They cannot tell you what a receiver concluded about an actual message, which is the only thing that matters. Send a test from the tenant to a Gmail address, open Show original, and read the Authentication-Results header. You want three things at once: spf=pass with an smtp.mailfrom on your domain, dkim=pass with header.d= on your domain rather than onmicrosoft.com, and dmarc=pass. Two out of three is where most tenants sit before this work, and where a lot of them quietly stay.

What the bulk sender rules add on top

Past a certain volume the three records stop being good practice and become entry requirements. Google's sender guidelines treat a domain sending close to 5,000 messages or more in a day to personal Gmail accounts as a bulk sender, and bulk senders need SPF, DKIM and a DMARC record of at least p=none, a user-reported spam rate kept under 0.3 percent, and one-click unsubscribe as described in RFC 8058. Microsoft has published a comparable requirement for high-volume senders reaching Outlook.com, Hotmail.com and Live.com addresses: SPF, DKIM and a valid DMARC record, with non-compliant mail routed to Junk ahead of harder enforcement. Cross either threshold without the records in place and the failures get loud quickly, showing up as authentication and reputation rejections rather than a quiet trip to the spam folder.

How Guanacos Tech helps

Most of the Microsoft 365 tenants we look at are two records away from passing everywhere, and the missing two are almost always DKIM on the custom domain and DMARC. We inventory every sender out of your aggregate reports, get each one aligned, and walk the policy from none to reject on a schedule that does not put your invoices at risk. If you are moving to or from Google Workspace, we do the same work on both sides of the cutover. Start with the free email troubleshooter or the DMARC analyzer, or book a call and we will read your headers with you.

Sources

• Set up SPF to identify valid email sources for your Microsoft 365 domain - Microsoft Learn
• How to use DKIM for email in your custom domain - Microsoft Learn
• Set up DMARC to validate the From address domain - Microsoft Learn
• Enable DMARC reporting for MOERA and parked domains - Microsoft Learn
• External DNS records required for Microsoft 365 - Microsoft Learn
• Email sender guidelines - Gmail Help
• Outlook requirements for high-volume senders - Microsoft Q&A
• RFC 7208, Section 4.6.4 - DNS Lookup Limits
• RFC 8058 - One-Click Unsubscribe

Is it spam or is it a bounce?

Before looking for a culprit, separate two problems people constantly mix up. A bounce is when the message never gets delivered: the receiving server rejects it and you get an error back, usually with a code like 550. Landing in spam is different: the message is delivered, but the recipient's filter routes it to the junk folder instead of the inbox, and nothing tells you that happened.

The difference matters because the diagnosis is different. A bounce is almost always an authentication problem or a direct block, and you find out because the error comes back to you. Landing in spam is a trust problem built up over time, the receiver decided that this particular message, or this sender in general, looks more like unwanted mail than legitimate mail, and that is where the seven real causes below come in. Almost all of them can be confirmed for free in under ten minutes.

Cause 1: SPF missing or broken

SPF is the DNS record that tells the world which servers are allowed to send mail on behalf of your domain. Google requires every sender to have SPF or DKIM set up correctly, and if you send 5,000 or more messages a day to personal Gmail accounts, it requires both. Without SPF, or with an SPF record that does not include the service actually sending the mail (your hosting provider, your CRM, your invoicing system), the message arrives unauthenticated, and Gmail can reject it outright with a 550-5.7.26 error or simply route it to spam.

A common mistake is accidentally publishing two separate SPF records, which breaks validation completely since the standard only allows one per domain. Check this by pulling your domain's TXT record and confirming there is exactly one v=spf1 entry that includes every real sender you use.

Cause 2: DKIM never signed

DKIM adds a cryptographic signature to every outgoing message, and the receiver verifies it against a public key published in your DNS. On Google Workspace, DKIM is off by default per domain until you manually turn it on in the Admin Console and publish the key, so if you never configured it, your mail goes out unsigned even if everything else is correct. Google recommends 2048-bit keys, stronger than 1024-bit, which you should only use if your DNS provider does not support the longer length.

The same pattern repeats on Zoho Mail and cPanel: DKIM does not turn itself on, you have to generate it and publish the matching TXT record under a specific selector, something like google._domainkey or zoho._domainkey. Check this by sending a test message to a Gmail address you control, opening it, and reading the Authentication-Results header under "Show original." It needs to say dkim=pass.

Cause 3: DMARC without alignment

DMARC does not replace SPF or DKIM, it connects them to the domain the recipient actually sees in the From field. Per RFC 7489, for DMARC to pass, the domain that authenticates SPF or the domain that signs DKIM has to match, or align with, the organizational domain shown in the visible From header. You can have SPF and DKIM both passing perfectly and still fail DMARC if, for example, your invoicing system signs with DKIM using its own domain instead of yours.

Without a published DMARC record, there is not even a rule telling the receiver what to do with mail that fails to align, so many providers treat it with more suspicion by default. Publishing DMARC at p=none does not block anything, but it starts sending you reports that show exactly which senders are failing alignment, information you simply do not have without it.

Cause 4: domain or IP reputation

Even with SPF, DKIM, and DMARC all correct, your domain's or IP's sending history can be damaged. Google Postmaster Tools rates this High, Medium, Low, or Bad: High means "a history of very low spam rates," Bad means mail is "almost always marked as spam or rejected." The spam rate Google watches is the percentage of your messages people manually mark as spam after receiving them, and the official guidance is to stay under 0.10% and never reach 0.30%.

If you use shared hosting, a basic Microsoft 365 setup, or any platform where you share an IP with other tenants, your reputation can drop because of another sender on that same IP. Google states this directly: "the activity of any senders using a shared IP address affects the reputation of all senders" on it. Check this by signing up for Google Postmaster Tools, which populates these dashboards once you have enough authenticated volume flowing to Gmail.

Cause 5: content and list quality

Beyond authentication, spam filters also evaluate what you are sending and to whom. Old lists nobody opens anymore are the most common problem: people who no longer recognize the sender are the ones most likely to hit "report spam" instead of simply ignoring the message or unsubscribing, which pushes your spam rate up over time. Content matters too: exaggerated subject lines, shortened links, image-only messages with no text, or blasting the identical message to thousands of people at once are signals modern filters already recognize.

Check this by looking at open rates by segment. If a large group of contacts has not opened anything in 90 to 180 days, pull them off active sending before they drag the rest down.

Cause 6: unauthorized third-party senders

This is the cause that slips through most often because it is not in your inbox, it is in third-party tools sending mail "as you" that nobody ever reviewed: the invoicing platform, the CRM, the online store, the billing system. If that service sends using your domain in the From field but is not in your SPF record and does not sign with an aligned DKIM, every message it sends counts against your overall reputation, even though you never clicked send yourself.

Check this by listing everything that sends mail using your domain, not just what runs through your Gmail or Workspace inbox, and confirming each one is authorized in SPF and signs with its own DKIM.

Cause 7: new domain

A freshly registered domain, or one that has never sent real volume to Gmail, does not have a bad reputation, it has zero reputation. Postmaster Tools may simply show no data yet. The problem is that sending a large batch all at once from a domain like that looks nearly identical to an attacker spinning up a throwaway domain to send spam, and filters treat it with the same suspicion.

Check this by being patient: start with low volume to contacts who will actually open and reply, increase slowly, and let the domain build history before relying on it for something urgent like a big campaign or a full migration.

Check it now, for free

The first six causes can be confirmed without spending anything: check your SPF and DKIM with the Guanacos Tech email troubleshooter, read a real header with the header analyzer, and if you already have DMARC published, check the reports with the DMARC analyzer. Between the three, you get visibility into almost everything covered above in a single session.

How Guanacos Tech helps

Most cases we review do not have one single cause, they have two or three stacked together: a DKIM key that never got turned on, an invoicing platform nobody authorized in SPF, and a list that stopped being cleaned a year ago. We run the full diagnosis, fix the DNS in the right order, and stay on it until reputation stabilizes. If you want a second set of eyes, book a free call.

Sources

• Set up DKIM to prevent spoofing - Google Workspace Admin Help
• RFC 7489 - Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• Email sender guidelines - Google Workspace Admin Help
• Postmaster Tools dashboards - Gmail Help
• Prevent mail to Gmail users from being blocked or sent to spam

Why the limit exists

SPF is not a list of IP addresses you publish once. It is a small program a receiving mail server has to run: fetch your TXT record, then follow every include, a, mx, ptr, and exists mechanism, plus any redirect modifier, each of which triggers its own DNS lookup. RFC 7208 section 4.6.4 caps that at 10: "SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS." Cross it and "the implementation MUST return permerror."

PermError is not a soft failure. It does not mean "treat this as neutral" the way a missing record does. Most large receivers, Gmail included, treat an SPF PermError as equivalent to no valid SPF at all, and Gmail's bulk sender rules require SPF or DKIM to pass, so a domain that blows the lookup budget can start bouncing with unauthenticated errors even though the record looks fine at a glance.

Two related limits sit inside that same rule. Each MX mechanism you use must not require querying more than 10 A or AAAA records to resolve, and the same 10-record cap applies to PTR lookups. RFC 7208 also recommends implementations cap "void lookups," DNS queries that return nothing, at two, and return permerror past that. In practice this means a bloated record can fail even before you count all 10 real lookups, if enough of those lookups come back empty.

Counting your lookups honestly

The mistake most SPF records make is counting the top-level include statements and stopping there. The limit is not "10 includes," it is 10 total DNS lookups across the whole evaluation, and an include can itself contain more includes that each cost a lookup.

Take a record that looks harmless:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:servers.mcsv.net include:spf.zoho.com redirect=_hspf.hubspot.com a mx include:sendgrid.net ~all

Read left to right against the RFC's list of what counts (include, a, mx, ptr, exists, redirect): include:_spf.google.com is 1, include:spf.protection.outlook.com is 1, include:servers.mcsv.net is 1, include:spf.zoho.com is 1, the a mechanism is 1, the mx mechanism is 1, and include:sendgrid.net is 1. That is 7 so far, before touching the HubSpot redirect. HubSpot's own SPF chain is not flat. Following it as published today means redirect=_hspf.hubspot.com (1 lookup) resolves to a record that itself includes _hspf1.hubspot.com (1 more), which includes _hspf2.hubspot.com (1 more), which includes a further sub-record. That redirect chain alone adds 4 or more lookups on top of the 7, pushing the total to 11 or higher, past the limit, on a record that looked like six or seven modest entries.

The usual offenders

Not every provider is equally expensive. As currently published, Google Workspace's include:_spf.google.com resolves directly to a flat list of IP ranges, no nested includes, so it costs exactly 1 lookup. Microsoft 365's include:spf.protection.outlook.com is the same shape: flat, 1 lookup. Mailchimp's include:servers.mcsv.net is also flat, 1 lookup. Zoho's include:spf.zoho.com resolves to a single flat list as well, 1 lookup, though Zoho's own documentation sometimes shows a combined record with additional includes like zcsend.net for their marketing product, each adding another lookup. HubSpot is the outlier: its SPF is a multi-level redirect and include chain, and following it end to end costs 4 or more lookups by itself, more than any other mainstream provider in a typical stack.

This changes over time. Providers restructure their SPF infrastructure without warning, and a provider that is flat today can add nested includes next quarter. Treat any lookup count, including the ones above, as something to re-verify with a live tool rather than something to hardcode into a spreadsheet.

Fix 1: remove dead includes

The fastest win is almost always deleting mechanisms nobody uses anymore. SPF records accumulate the way old CC lists do: a marketing tool you canceled two years ago, a fax-to-email gateway nobody remembers, a legacy on-prem relay that got decommissioned when you moved to Workspace or M365. Pull the current record, match every include against a live sender, and delete anything that is not sending mail today. This alone resolves a large share of "too many lookups" cases without touching anything else.

Fix 2: push the cost onto a subdomain

Every subdomain gets its own SPF evaluation and its own 10-lookup budget. If your root domain sends transactional mail through Workspace and marketing mail through HubSpot and Mailchimp, moving the marketing sends to a dedicated subdomain, for example mail.example.com or news.example.com, splits one crowded 10-lookup budget into two separate ones. This is also the fix dmarcian, the company that built and later retired its own SPF flattening tool, now recommends over flattening: segmenting senders by subdomain gives you "better controls, less attack surface, operational efficiency, and reputational resilience" instead of one bloated shared record.

Fix 3: flattening, and why it carries its own risk

Flattening replaces an include with the literal ip4/ip6 ranges it resolves to today, cutting the lookup count to near zero. It works, until the provider changes its sending IPs, which every major ESP does periodically without a public changelog. A flattened record goes stale the moment that happens, and mail from the provider's new IPs starts failing SPF silently, often before anyone notices the bounce pattern. dmarcian ran flattening as a public experiment for years and shut it down in March 2023, concluding that the practice trades one operational problem for a security one: an over-authorized, rarely-audited record is "unnecessary entries in SPF records" that widen your attack surface rather than shrink it. If you flatten, treat it as a stopgap with a recheck on your calendar, not a permanent fix.

Fix 4: lean on DKIM alignment instead of forcing SPF to cover everything

DMARC only needs one of SPF or DKIM to pass and align, not both. If a sender you cannot remove from SPF without breaking mail is properly DKIM-signed with an aligned domain, DMARC still passes for that sender even if SPF alone would exceed the lookup limit or fail outright. This does not fix the PermError risk, an SPF PermError is still treated as SPF failing outright by most receivers regardless of what DMARC ultimately decides, so it is a mitigation for alignment, not a substitute for getting the lookup count under 10. Prioritize DKIM setup for every sender you keep, and use it as the safety net while you work the SPF count down, not as a reason to ignore the count.

Verify before you consider it done

Publish the change, then re-check the live record rather than trusting your own count. A record that looked fine on paper can still exceed the limit once you follow a redirect chain like HubSpot's all the way down, and a typo in one include can silently break the whole record instead of just that one entry. Run a real test send through the Guanacos Tech email troubleshooter and confirm SPF returns pass, not permerror or none, on an actual message.

How Guanacos Tech helps

We see this most often in companies that have switched email or marketing platforms two or three times over the years and never cleaned up the trail. We audit the full lookup chain, including redirects and nested includes most SPF checkers stop counting after the first level, cut it under 10 in the right order, and set up DKIM alignment as backup coverage for anything that has to stay. If your SPF record keeps bouncing back as a PermError, book a call and we will trace it with you.

Sources

• RFC 7208, Section 4.6.4 - DNS Lookup Limits
• About SPF records - Google Workspace Admin Help
• Concluding the Experiment: SPF Flattening - dmarcian
• Set up SPF to identify valid email sources for Microsoft 365 - Microsoft Learn

You did everything right. Two-factor is enforced on every account. Nobody reused a password from a 2019 breach. And the attacker still got in, read the CFO's mail for a week, and rerouted a wire.

When this happens, the post-mortem almost never finds a cracked password or a defeated MFA prompt. It finds a stolen browser session. The login already happened, on a legitimate device, by the real user. The attacker just walked in carrying the proof.

Why 2FA quietly stopped being enough

Here is the part most admins were never told plainly. Two-factor authentication protects the moment you sign in. Once you're in, your browser holds a session cookie. That cookie is the "yes, this person is signed in" badge, and your browser shows it on every request so you don't have to type your password and tap your phone forty times a day.

Malware called an infostealer goes after that badge. It runs on an infected laptop, copies the live session cookies out of the browser, and ships them off. The attacker loads those cookies into their own browser and lands inside the account already authenticated. No password prompt. No MFA challenge. There's nothing to challenge, because as far as the system is concerned the session was already approved.

This is not a fringe technique. Constella's identity research found infostealers processed 51.7 million packages in 2025, a 72% jump over the prior year, and a big reason those packages are so valuable is that they carry live session cookies that bypass MFA outright. SpyCloud, working from a different data set, recaptured 8.6 billion stolen cookies and session artifacts from malware infections, and counted 1.17 million malware logs that held both enterprise credentials and active session cookies. The families doing most of this in early 2026 are LummaC2, ACRStealer, StealC, and Vidar. One infected machine in your org can become an authenticated session in someone else's hands.

What Google turned on, and when

On May 28, 2026, Google announced that Device Bound Session Credentials (DBSC) in the Chrome browser on Windows is now generally available and enabled by default for Google Workspace users. The rollout started gradually on May 25 and can take up to 60 days to fully appear across Rapid and Scheduled Release.

The idea behind DBSC is simple once you strip the acronym away. When a session is created, Chrome generates a private cryptographic key and stores it inside the device's TPM, a hardware-backed security chip built into the machine. The session cookie gets tied to that key. From then on, every time the session refreshes, Chrome has to prove it still holds the matching device key. A cookie copied off that laptop is missing the key it was bound to, so on the attacker's machine it simply fails validation. The stolen badge no longer opens the door.

If the system sees that a session doesn't match the device it was bound to, the user is prompted to sign in again. The honest user shrugs and re-authenticates. The attacker is stuck.

Two things matter for your blood pressure here. This is on by default, for all Workspace customers, Workspace Individual subscribers, and personal Google accounts. There is no admin control to disable it and no end-user setting to flip. You don't have to deploy anything to get the baseline protection.

The fine print: where DBSC does not reach

This is one strong control, not a force field. Knowing its edges is the whole job, because attackers move to whatever you left uncovered.

• Chrome and Windows only. It needs Chrome 146 or later on Windows, and a TPM to hold the keys. TPM is standard on most Windows 11 hardware, but older or unmanaged machines may not qualify.
• macOS, mobile, and other browsers are still exposed. A session stolen from Safari, from a phone, or from Firefox or Edge does not get this device binding. Constella's analysis makes the same point: the Chrome-on-Windows scope leaves macOS, mobile, other browsers, and non-browser token theft on the table.
• Non-browser tokens aren't covered. OAuth tokens and app credentials living outside the browser are a separate problem DBSC doesn't touch.

Read that list as a map of where you still need other defenses, not as a reason to wave DBSC off. For the place most credential theft actually happens, the corporate Windows laptop running Chrome, the highest-value cookie just got a lot less useful to steal.

What an admin should actually do

Nothing is required to switch DBSC on. But "nothing required" and "nothing worth doing" are different things. A few moves turn a passive default into something you can see and steer.

Watch the binding events. In the security investigation tool, DBSC writes audit logs you can review. User log events show DBSC key binding and DBSC key validation as Succeeded or Failed. Access Evaluation log events surface denied requests with codes like DBSC_BOUND_COOKIE_MISSING, DBSC_BOUND_COOKIE_CORRUPTED, and DBSC_BOUND_COOKIE_EXPIRED. A spike in failed validations is a signal worth chasing, not noise to mute.

Consider enforcing bound sessions. DBSC works alongside Context-Aware Access. If you want to go further than the default, you can use Context-Aware Access to require a bound session and block non-bound ones from reaching specific apps. Sensible for your most sensitive systems; test it before you point it at everyone, since it can lock out anyone on an unsupported browser, OS, or device.

Standardize the fleet so devices actually qualify. DBSC only helps on machines that meet the bar. Managed Chrome plus Windows 11 with a working TPM and current browser versions is what makes the protection real instead of theoretical. If your fleet is a patchwork of personal laptops and stale Chrome builds, that's the gap to close first.

Keep layering. Phishing-resistant passkeys to harden the login itself, Context-Aware Access to gate by device posture, and basic endpoint hygiene so infostealers can't run in the first place. DBSC takes one weapon out of the attacker's hands. It doesn't take all of them.

The honest takeaway

Session theft was the quiet gap behind a lot of "but we had MFA" incidents, and Google just closed a big slice of it for free on the platform most of your users live on. That's genuinely good news. It is also the kind of change that's easy to misread as "we're done." You're not done. You're better protected on Chrome and Windows, and you now have logs to prove it and a clear list of what still needs covering.

If you'd rather not piece this together alone, this is the sort of audit we do every week: confirm DBSC is actually landing on your fleet, wire up the monitoring so failed bindings reach a human, decide whether Context-Aware Access enforcement fits your risk, and find the macOS and mobile gaps before someone else does. We're an independent Workspace and Cloud team, not a reseller pushing a license. If your last security review predates all of this, it's a fair time for a fresh look.

What "Less Secure Apps" actually meant

Less Secure Apps was Google's label for any client that connected to Gmail using a plain username and password — no OAuth 2.0, no token exchange, just credentials passed directly over IMAP, POP3, or SMTP. The clients that used this path were largely designed in the 1990s and early 2000s, before OAuth existed as a standard.

The label was technically accurate. Basic auth has no token rotation, so a stolen password is a full account takeover — no time limit, no scope restriction. It has no MFA support, so your two-step verification policy is silently bypassed for any app using this path. There is no scope limitation either: a client authenticating via basic auth gets full access to everything in the account, not just the mailbox it needs. And the credentials are fully phishable — a credential-stuffing attack or a single leaked password spreadsheet is all it takes.

Every modern security framework treats basic auth as an unacceptable risk for this reason. The deprecation was not a surprise for anyone following the threat landscape.

The deprecation timeline

Google announced the end of Less Secure Apps access in 2019 — giving organizations several years to migrate. For personal Gmail accounts, basic auth was turned off on May 30, 2022. Workspace (paid) accounts kept the admin toggle longer, but Google removed it entirely in June 2024.

As of today, there is no toggle to flip. The option is gone from the Admin Console. No Workspace account — regardless of tier, age, or admin configuration — can re-enable basic auth access for any client. This is not a policy that can be requested as an exception. The infrastructure no longer supports it.

If you are reading this because a system just started throwing authentication errors, the timeline explains why. The system likely worked for years, coasted through the 2022 personal-Gmail cutoff without being touched, and finally hit the wall when the Workspace toggle was removed.

What actually broke when LSA went away

The error message is usually "Authentication failed" or "Username and password not accepted," sometimes accompanied by a link to a Google help article about Less Secure Apps that now leads to documentation explaining why the feature no longer exists. The systems generating this error fall into predictable categories.

• Multifunction printers and copiers — Xerox, Canon, Ricoh, Sharp, and Konica Minolta devices configured to scan-to-email via SMTP submission. This is the most common ticket we see. The device has had the same SMTP config for a decade and nobody thought to update it.
• Legacy CRM, ERP, and accounting software — notification emails, invoice delivery, and alert emails sent through Gmail SMTP with hardcoded credentials. Often configured by whoever set up the software years ago and not documented anywhere.
• Backup and monitoring scripts — shell scripts or Python scripts running on a cron schedule that email nightly reports. smtp.gmail.com on port 587, username and password in a config file or environment variable.
• Older desktop email clients — pre-2019 versions of Outlook, older versions of Thunderbird, Mac Mail on macOS versions from before OAuth support was standard. Any client that never prompted users to re-authenticate through a browser flow.
• Marketing and automation tools — third-party tools that were integrated using Gmail credentials directly rather than through the Gmail API or an OAuth-scoped service account.

In each case, the system was working fine until June 2024. Then it stopped. The error is the same; the fix depends entirely on which category the system falls into.

The three migration paths

There is no single answer. The right migration path depends on what the system is and what it actually needs to do.

OAuth 2.0

This is the correct long-term answer for any modern application that supports it. The app registers a client ID in Google Cloud Console, the user (or an admin, for service accounts) grants scoped consent, and the app receives refresh tokens that rotate automatically. Access can be scoped narrowly — read-only, specific labels, send-only — rather than full account access. Revocation is per-app rather than requiring a password change. Most major SaaS platforms already support this; check the vendor's authentication documentation before assuming they don't.

App Passwords

For clients that genuinely cannot speak OAuth — older printers, niche line-of-business apps with no update path — Google provides App Passwords as a compatibility shim. An App Password is a 16-character, single-use password generated per device under the user's account at Manage your Google Account → Security → App passwords. The account must have 2-Step Verification enabled before this option appears.

App Passwords are limited but functional. The client uses the App Password instead of the account password. If the device is compromised, you revoke that specific App Password without touching the account password or other devices. This is meaningfully better than plain basic auth, but it is still a static credential — it does not rotate unless you regenerate it manually.

SMTP Relay Service

For high-volume server-to-server email — system notifications, transactional sends, scripted reports — the right answer is Google Workspace's SMTP Relay Service, not a per-user account. Configured at the domain level in Admin Console under Apps → Google Workspace → Gmail → Routing → SMTP relay service, it allows sending from specific IP ranges or authenticated users through Google's infrastructure. It does not count against per-user send limits. It does not require a user account's credentials in a script. It is the correct architecture for anything sending mail at scale from a server.

How to find what's still using LSA in your environment

Before you can fix anything, you need a complete list of affected systems. Most organizations discover these one at a time as they break, which is a slow and reactive way to work through a migration. A structured audit is faster.

• Admin Console audit logs: Go to Admin Console → Reporting → Audit and investigation → User log events. Filter for Login failure events. Look for repeated failures from the same source IP address — that pattern almost always indicates a service account or device, not a human failing a password attempt.
• Gmail routing audit: Admin Console → Apps → Google Workspace → Gmail → Routing. Review any IPs in your inbound or outbound mail gateway configuration to understand what is sending mail through your domain.
• Facilities and IT asset inventory: Talk to the facilities or office management team. Printers and copiers are the single most common LSA breakage point, and they are rarely tracked in IT systems. Pull a list of every MFP on the network and physically check its scan-to-email configuration.
• Server-side script audit: Check scheduled tasks on Windows servers and cron jobs on Linux systems. Search script directories for smtp.gmail.com or password= — those strings in a script file almost certainly indicate a hardcoded SMTP credential that will break.

Document what you find: system name, owner, what email function it performs, and which migration path applies. That list becomes your migration project plan.

What to do for each system you find

Once you have the inventory, the remediation decision for each system is straightforward.

• Printer or MFP: Create a dedicated Google account for the device (e.g., printer-floor3@yourdomain.com), enable 2-Step Verification on it, generate an App Password, and update the device's SMTP configuration. The better long-term answer is to switch to the SMTP Relay Service and configure the device's IP — then the account credential is removed from the equation entirely.
• Line-of-business application: Check the vendor's documentation for OAuth support first. If the vendor supports OAuth and your version is recent enough, migrate. If the app has no OAuth path and cannot be updated, use an App Password on a dedicated service account.
• Server scripts: Use the SMTP Relay Service. Do not use App Passwords for production scripts — they are static credentials sitting in config files and they do not rotate. SMTP Relay with IP allowlisting is the correct architecture here.
• User email clients: Any desktop or mobile client released after approximately 2020 supports OAuth. Remove the account from the client and re-add it. The first sign-in will redirect to a Google login page and complete the OAuth flow automatically. No special configuration required.

The security upside

Basic auth is genuinely indefensible in 2026. A phished password is a complete account compromise — no MFA stands between the attacker and the inbox. There is no audit trail of what the app accessed or when. There is no way to revoke access for a single device without changing the user's password across every device they use. The access scope is always full, regardless of what the app actually needs.

Every major breach report from the past decade has a basic-auth story in it. Credential stuffing, password spraying, and supply-chain attacks against apps storing plaintext passwords all rely on basic auth being available somewhere in the authentication surface. Removing it closes that path entirely.

The migration is operationally annoying — mainly because the affected systems are old, poorly documented, and owned by departments that don't think of themselves as IT stakeholders. But the end state is materially better. Per-device App Passwords mean a compromised printer credential doesn't expose the entire account. OAuth scopes mean an integrated app can only read what it needs. SMTP Relay means scripts aren't running with a user's full identity attached.

Bottom line

If you have systems throwing "Authentication failed" errors and this is the first time you're hearing about Less Secure Apps, OAuth, App Passwords, or SMTP Relay — you are not alone. The printer-stops-scanning-to-email scenario is the most common first symptom for SMBs hitting this cutoff, and it shows up six to eighteen months after Google pulled the toggle because most organizations don't notice until the device breaks in a way that disrupts a workflow.

The playbook is: audit (login failure events, routing config, printers, scripts), classify each system as OAuth-capable / App Password candidate / SMTP Relay candidate, then migrate in priority order. Budget two to four weeks of elapsed time for an organization with a mixed legacy environment. There is nothing to turn back on. The path forward is the migration.

What S/MIME actually does

S/MIME (Secure/Multipurpose Internet Mail Extensions) encrypts the body and attachments of an email message using a public/private key pair anchored in an X.509 certificate issued by a Certificate Authority. The sender's mail client encrypts the message using the recipient's public key. Only the recipient's private key can decrypt it. Neither your email provider nor any server in transit can read the content.

S/MIME also signs outbound messages. A digital signature lets the recipient cryptographically verify that the message came from you and was not modified in transit — stronger than SPF/DKIM header checks, which only authenticate the sending domain.

This is fundamentally different from TLS-in-transit. Standard Gmail already uses TLS between mail servers, which protects messages on the wire. TLS ends at the server. S/MIME protects the message itself, mailbox to mailbox. Both sender and recipient must have valid S/MIME certificates for encryption to work end-to-end.

When you actually need it

The honest answer: most organizations don't need S/MIME. The ones that do are usually driven by a specific regulatory trigger or contractual obligation:

• HIPAA — Protected health information (PHI) transmitted over email may require encryption at rest and in transit. S/MIME satisfies the in-transit encryption requirement between mailboxes when TLS-only delivery isn't sufficient.
• SOX and financial controls — Some financial services compliance frameworks require encrypted communication for sensitive board-level or M&A correspondence.
• FedRAMP / CJIS — Government contractors working with controlled unclassified information (CUI) often face explicit certificate-based encryption mandates.
• Attorney-client privilege — Law firms handling highly sensitive matters sometimes deploy S/MIME to establish a technical paper trail supporting privilege claims.
• M&A and IP-sensitive work — Deal teams and R&D groups where a single leaked email has outsized consequences.

If your legal or compliance team has never raised S/MIME in a risk assessment, you probably don't need it. One common misconception: Gmail's Confidential Mode is not a substitute. Confidential Mode sets an expiry on access and prevents forwarding — it does not encrypt the message body. It is a UI restriction, not cryptographic protection.

What tier of Workspace you need

S/MIME is not available on Business Starter, Business Standard, or Business Plus. It is an Enterprise-tier feature. Specifically, it requires Workspace Enterprise Standard, Enterprise Plus, Education Plus, or Frontline.

This matters when you're doing a compliance-driven SKU evaluation. If S/MIME is a hard requirement, it pushes you to Enterprise Plus at roughly $30/user/month — versus Business Plus at $18. For a 100-seat org, that gap is $14,400/year. That number belongs in any compliance cost analysis alongside the cost of a data breach.

The license uplift is often the first objection in a deployment project. Address it early. If the regulatory or contractual requirement is real, there's no workaround — you need the Enterprise tier.

Hosted S/MIME vs. traditional

This is the trade-off most documentation glosses over. When you enable S/MIME in Google Workspace, the default mode is Hosted S/MIME. Google holds your users' private keys in its key management infrastructure. When an encrypted message arrives, Google decrypts it on the server, scans it for malware and spam, and re-encrypts it for delivery to the client.

That breaks the strict definition of end-to-end encryption. Google — and by extension, any valid legal process served to Google — can access the plaintext. The payoff is that Workspace features continue to work: Gmail search indexes the content, Vault retains the messages for eDiscovery, malware scanning catches threats before delivery.

Traditional S/MIME keeps private keys on the user's device and never exposes them to the server. Messages are encrypted by the client before sending and decrypted by the client after receiving. The server never sees plaintext. This is true end-to-end encryption.

The cost is significant: Vault cannot see encrypted message content, Gmail search doesn't index it, malware scanning is blind to the body, and mobile clients have inconsistent support. For most regulated organizations, the Hosted S/MIME compromise is the right operational choice — the regulatory requirement is for encryption in transit between mailboxes, which Hosted S/MIME satisfies. Understand the trade-off explicitly before committing.

Setup at a glance

Enabling S/MIME in Google Workspace involves four parallel workstreams. None of them are complicated individually, but coordinating them across a mid-size org takes time.

• Enable in Admin Console: Apps → Google Workspace → Gmail → User settings → S/MIME. Enable for the relevant organizational unit. You can also enable extra CA roots here.
• Obtain certificates: Get user certificates from a public CA — DigiCert, GlobalSign, and Sectigo are the common choices — or issue from an internal PKI if your organization already runs one. Each user needs a certificate tied to their email address.
• Upload root and intermediate CA certificates: Upload the CA chain to Workspace so Gmail trusts the certificates. Admin Console → Apps → Google Workspace → Gmail → S/MIME CA certificates.
• Distribute user certificates: For small teams, manual upload via the Gmail settings page works. For any org over 20 users, use the Gmail API's keypairs endpoint to push certificates programmatically.

Plan for six to twelve weeks end-to-end for a first deployment at a 50-plus-seat organization. Certificate procurement alone takes two to three weeks if you haven't worked with a CA before. Build in time to train users on what the lock icon in Gmail means and what to do when a message can't be encrypted because the recipient lacks a certificate.

What goes wrong

S/MIME deployments that start well often drift into problems six to eighteen months later. The most common failure modes:

• Certificate expiry: S/MIME certificates typically expire after one or two years. Renewal is not automatic by default. When a certificate expires, the user loses the ability to decrypt messages encrypted to their old public key — and previously encrypted archived messages may become unreadable if the expired cert is not preserved.
• Recipient doesn't have S/MIME: If the recipient's domain or mailbox has no certificate, Gmail falls back to TLS-only delivery — or in strict modes, may refuse to send. Users need to understand when a message is and isn't being encrypted, and why.
• Mobile Gmail inconsistency: The Gmail iOS and Android apps support Hosted S/MIME for reading and composing encrypted messages, but the experience has historically been less reliable than desktop. Test your rollout on mobile before going live.
• Certificate rotation without re-encryption: When a user's certificate is rotated (new key pair issued), old messages encrypted to the previous public key can only be decrypted with the old private key. If the old key isn't archived correctly, those messages are permanently unreadable.
• eDiscovery gaps: In Hosted S/MIME mode, Vault can search and export encrypted messages because Google holds the keys. In traditional S/MIME mode, Vault cannot see message content — only metadata. This surprises legal teams who assumed Vault covered everything.

Bottom line

S/MIME is the right answer when a regulatory requirement, government contract, or explicit legal obligation demands certificate-based encryption. You accept the operational cost: PKI management, certificate lifecycle work, a license uplift to Enterprise tier, and ongoing support tickets from users who can't read encrypted messages on a new device.

It is the wrong answer when leadership wants "more encryption" in a general sense. If the goal is reducing data risk broadly, a combination of DLP rules, Google Vault retention policies, strong 2-step verification, and endpoint verification delivers more risk reduction per dollar than an S/MIME deployment for a team that doesn't face a hard regulatory mandate.

Spend the S/MIME conversation answering one question first: does your compliance framework explicitly require encrypted email between mailboxes? If yes, you need S/MIME. If no, build your security stack from cheaper, higher-leverage controls first.

Google Workspace Shared Drives are drastically different from 'My Drive'. In My Drive, files are owned by individuals. In Shared Drives, files are owned by the organization.

Why you need to migrate today

When an employee leaves and you delete their account, all files they created in My Drive are deleted too, unless you manually transfer ownership. With Shared Drives, this never happens.

The Guanacos Tech Approach

We help businesses map out their permissions and migrate data cleanly so everyone has exactly the access they need, with zero data loss.

Data Loss Prevention (DLP) isn't just for massive enterprise corporations. Small businesses handle sensitive customer data, and a single leaked document can be fatal.

How DLP Protects You

Google Workspace DLP scans emails, Drive files, and Chat messages for sensitive information like credit card numbers or custom keywords. It can automatically block the sharing of this data externally or warn the user.

The Guanacos Tech Approach

We configure DLP rules that are strict enough to keep you compliant and secure, but flexible enough that they don't break your team's workflow.

While most admins focus on securing email and documents, the browser itself is often the biggest vulnerability. Chrome Enterprise Cloud Management allows you to secure the browser your team uses every day.

Centralized Control

You can force essential extensions (like password managers), block malicious extensions, and ensure that the browser is always up-to-date across your entire fleet of Mac, Windows, and ChromeOS devices.

The Guanacos Tech Approach

We deploy Chrome policies from the Google Admin console to ensure all company data accessed via browser is protected, without needing heavy MDM software.

You've probably noticed that some companies have their official logo displayed directly in the Gmail inbox before you even open the email. This isn't a premium Google feature—it's an email authentication standard called BIMI.

Brand Indicators for Message Identification (BIMI)

BIMI requires your domain to have a strict DMARC policy (p=quarantine or p=reject). Once you prove your domain is secure from spoofing, mailbox providers reward you by displaying your verified logo.

The Guanacos Tech Approach

We specialize in cleaning up your SPF, DKIM, and DMARC records to get you to strict enforcement, paving the way for BIMI implementation and maximum email deliverability.

If an employee deletes a crucial email and then empties their trash, that email is gone forever—unless you use Google Vault. Google Vault is a retention and eDiscovery tool natively integrated into Business Plus and Enterprise plans.

Retention Policies and Holds

Vault allows you to set rules like "keep all emails for 5 years." Even if a user deletes an email, the admin can still retrieve it through Vault. You can also place legal holds on specific users to preserve their data indefinitely.

The Guanacos Tech Approach

We help you configure Vault properly so you're legally compliant without hoarding unnecessary junk data forever, protecting you during HR disputes or legal inquiries.

Google keeps expanding Gemini features directly inside Workspace (Gmail, Meet, Drive, Docs, Vids, etc.). This is something SMBs are curious about but still confused about. The shift is happening: AI is moving from being an "extra tool" you have to open separately, to a built-in assistant in your daily workflow.

What's actually changing?

It's not just about generating text anymore. Here is what is happening right now:

• Personalized Smart Replies in Gmail: Forget generic three-word responses. Gemini is rolling out context-aware, tone-aware replies that sound like you.
• Document Summaries: Gemini can now summarize long documents in Drive and even create audio overviews for you to listen to on the go.
• Video Creation: With Google Vids, AI is helping teams generate training videos and updates without needing a production crew.

The Guanacos Tech Perspective

At Guanacos Tech, we help businesses actually adopt AI inside Google Workspace — not just enable it. Most companies turn on AI features but don't redesign their workflows, missing the real value.

Real value comes from saving time on admin tasks. If getting a summary of a 50-page contract saves you 30 minutes, that's real ROI. If drafting a client email takes 30 seconds instead of 10 minutes, that scales across your team.

If you've been following Google Workspace updates, you might be looking for "Duet AI." That name is officially retired. In late 2025, Google unified its powerful AI capabilities under the Gemini brand, launching Gemini Enterprise as the new standard for business AI.

Gemini Enterprise isn't just a rebrand; it's a massive leap forward in capability, reasoning, and integration.

Why the change?

Google wanted to bring its most capable model, Gemini Ultra 1.0 (and now 1.5 Pro), directly to Workspace users. Duet AI was great, but Gemini Enterprise is designed to be an agent—a partner that can execute complex, multi-step tasks across Gmail, Docs, Sheets, and Slides.

Key Features for Business

• Context Window: Gemini 1.5 Pro features a massive context window, allowing it to "read" and reason across thousands of lines of code or hundreds of documents in seconds.
• Side Panel Integration: It lives in the side panel of your favorite apps. In Gmail, you can ask it to "summarize this thread and draft a reply." In Slides, it can "generate visuals for this slide."
• Enterprise-Grade Security: Unlike the consumer version of Gemini, the Enterprise edition ensures your data is never used to train Google's models. Your IP remains yours.

Is it worth the upgrade?

For teams that spend hours analyzing data or drafting content, the ROI is immediate. The ability to ground Gemini's responses in your own company data (Drive files, emails) makes it far more useful than a generic chatbot.

We're helping clients roll out Gemini Enterprise with proper data governance policies in place. If you're interested in a pilot, let us know.

This is a REAL pain seen constantly in admin communities: "I enabled 2FA and locked out my entire company." It happens more often than you think.

Why does this happen?

Admins often try to enforce security policies (like 2-Step Verification) without a proper rollout plan. Or worse, they rely on a single Super Admin account. If that account gets compromised or locked out due to a lost phone/key, the recovery process can be painfully slow and stressful.

Guanacos Tech Advice

We see this more than you’d think — security done wrong is just as dangerous as poor security. Here are a few quick best practices:

• Backup Super Admin: Always have a secondary Super Admin account with a physical security key stored in a safe place.
• Recovery Methods: Ensure you have recovery options (phone, email) set up outside of your Google Workspace environment.
• Staged Rollout: Never Turn on 2SV for "Everything" at once. Use Organizational Units (OUs) to roll it out to IT first, then leadership, then the rest.

This is a massive opportunity for SMB automation. Historically, if you wanted deep insights from your data, you needed a data analyst or some serious Excel wizardry.

Gemini changes the game

With Gemini inside Sheets, you can now analyze multiple tables at once. It can generate complex formulas for you, run multi-step data tasks, and even spot trends you might have missed.

Real SMB Use Cases

• Sales Pipelines: Ask Gemini to "Highlight deals that have been stalled for more than 14 days" or "Project next month's revenue based on current close rates."
• Inventory Management: "Create a formula to flag items with less than 10 units in stock."
• Finance Reporting: "Categorize these expenses and create a summary chart."

You don't need a data analyst anymore for basic reporting — just the right setup. We help companies turn Google Sheets into intelligent dashboards.

Hybrid environments are everywhere. Your team might use Workspace, but your biggest client uses Teams. In the past, this meant fumbling with invites and browser links. That's changing.

What's improving?

Google and Microsoft are finally playing nice. Meet devices can now join Teams meetings, and vice versa, with much less friction. This move toward cross-platform collaboration is a huge win for productivity in mixed environments.

Why this matters for your business

Your tools shouldn’t force your clients to change platforms. Mixed ecosystems are normal, and fighting against them is a losing battle.

We help businesses set up smart configurations that avoid "meeting chaos." We ensure that when a client sends a Teams invite, your Google Meet hardware—and your team—can handle it seamlessly.

If you're noticing your open rates dropping or emails landing in spam, pay attention. In 2026, Google has tightened its sender requirements again, and a new tool called the AI Security Add-on is becoming essential for Enterprise users.

The new AI Security Add-on

Launched recently, this add-on for Google Workspace uses privacy-preserving AI models to automatically classify and protect sensitive files in Google Drive. But more importantly for email admins, it enhances spam and malware defenses in Gmail.

It acts as a second layer of defense, identifying complex phishing attempts that standard filters might miss. If you handle sensitive financial or data assets, this add-on ($10/user/month) is a recommended upgrade.

DMARC is no longer optional

We've said it before, but it bears repeating: If you send bulk emails (5,000+ per day), you must have a DMARC policy in place.

• SPF & DKIM: Must be valid.
• DMARC: Must be set to at least p=none (monitoring), but ideally p=quarantine or p=reject.
• One-Click Unsubscribe: Marketing emails must support RFC-compliant headers for easy unsubscribing.

Don't know your DMARC status? Use our Free Deliverability Troubleshooter to check your risk score instantly.

Admins constantly struggle with updates. Real community discussion confirms this: Google ships changes continuously, and many admins only discover them after something breaks.

The Firehose Problem

Following the official Workspace Blog blog is essential, but it can be a firehose of information. Not every update matters to every business. A change to Classroom doesn't affect a law firm, but a change to Drive sharing settings definitely does.

Our Role

Our job at Guanacos Tech is to translate Google updates into what actually matters for your business. We act as the filter, focusing purely on the security and productivity changes that affect SMBs.

Video is the new document. Whether it's a training update for HR, a pitch for a client, or a quarterly recap, we're all consuming more video content at work. Enter Google Vids, the newest app in the Workspace suite, which is now generally available.

Google Vids is an AI-powered video creation app designed specifically for work. And no, you don't need to be a video editor to use it.

"Help Me Create"

Simply type a prompt like "Create a sales training video for our new Q1 product line," and attach a related Google Doc. Vids will generate a storyboard, suggest scenes, stock footage, and background music instantly.

Features We Love

• Teleprompter Mode: Record yourself confidently with a scrolling script right on the screen.
• AI Voiceovers: Don't want to record your own voice? Choose from a library of high-quality, natural-sounding AI voices to narrate your video.
• Collaboration: Just like Docs and Sheets, you can comment, tag colleagues, and edit Vids together in real-time.

It sits alongside Docs, Sheets, and Slides as a core productivity tool. If your team hasn't tried it yet, check your app launcher—it might already be there.