Guanacos Tech Blog

When will your GKE cluster upgrade itself? Read the release schedule, then move the date

Guanacos Tech — Wed, 30 Sep 2026 12:00:00 +0000

Ask a small team when their Kubernetes cluster will next upgrade itself and you get one of two answers: "it does not" or "no idea". Both are wrong in the same way. GKE publishes the dates. They sit on a page most people have never opened, and they are the difference between an upgrade that lands on a quiet Sunday and one that lands while your busiest customer is checking out.

This is the work we do on a client cluster in the first week: find the date, decide whether it is a good date, and move it if it is not. Here is the order we do it in.

Where GKE publishes the schedule, and how to read it

The page is called the GKE release schedule. It is a table with one row per Kubernetes minor version and a column per release channel: Rapid, Regular, Stable and Extended. For each version and channel it gives the date the version becomes available for new clusters and the date GKE begins auto-upgrading existing clusters to it. Checked 30 September 2026.

Two things about that table matter more than the numbers in it. The documentation says the dates are best-effort predictions, and that availability and upgrade dates can be delayed depending on the qualification and stability of a release, so treat a date as a window rather than an appointment. And the spacing between channels is the thing you are really choosing:

Rapid picks up a minor version one to two weeks after it reaches general availability upstream in open source Kubernetes, and targets auto-upgrade one to two months after that.
Regular sits in the middle, and it is the reference point for the support clock below: support for a minor version is counted from the day it becomes available in Regular.
Stable receives a version three to four months after Regular, and targets auto-upgrade roughly two months after that. It prioritises stability over new features.
Extended lines up with Regular for availability, and keeps a minor version supported for longer.

There is a second feed worth a bookmark: the per-channel release notes. Every week or two, GKE marks individual patch versions as deprecated inside a channel. The Google Cloud release notes of 23 September 2026 carry the standard wording for several of them, that a deprecated version will be removed in 90 days, or at the end of support if that comes sooner. So even inside a channel, sitting on one exact patch version is a temporary state with a 90-day clock on it.

The clock that decides everything: standard, then extended support

GKE's versioning and support page frames support per minor version, counted from the day the version becomes available in the Regular channel. There is around 14 months of standard support, during which the version receives new features, security fixes and bug fixes. After that the version enters extended support, which adds roughly 10 more months of security patches and is available to clusters enrolled in the Extended channel. Up to about 24 months in total. Checked 30 September 2026.

The sentence we read out loud to clients is the one at the end of that lifecycle: at the end of extended support, GKE upgrades clusters still running the now-unsupported minor version regardless of blocking issues. The upgrade is not the optional part. Only the timing is.

What version your clusters are on today

Before touching a setting, take the inventory. One command per project:

gcloud container clusters list \
  --format="table(name, location, currentMasterVersion, releaseChannel.channel)"

An empty channel column means the cluster is on No channel, the configuration that Google's release channel documentation says is deprecated and will be removed on 14 June 2027, after which GKE enrols the remaining clusters in the Stable channel (checked 30 September 2026). We covered that deadline and the setup it forces in our post on the June 2027 release channel deadline. For today the relevant part is narrower: a cluster outside a channel can only use the blunt version of the controls below.

Then read the current upgrade policy on each cluster:

gcloud container clusters describe CLUSTER_NAME \
  --location=LOCATION \
  --format="value(maintenancePolicy)"

Empty output is common, and it is the finding. No maintenance window means GKE may start an automatic upgrade at whatever hour it chooses.

Maintenance windows and exclusions: the two settings that decide when

A maintenance window is a recurring block of time that GKE is allowed to use. Outside it, GKE does not start an automatic upgrade. That is the setting that moves an upgrade off Tuesday lunchtime permanently, and it takes minutes to configure with gcloud container clusters update or in the cluster's settings in the console.

A maintenance exclusion is the other half: a one-off date range in which you want nothing to happen, such as a launch week or a year-end freeze. Exclusions have scopes, and which scope you can use depends on whether the cluster is enrolled in a channel:

No upgrades blocks everything, control plane and nodes. For a cluster outside a channel this is the only scope available, and it is capped at 30 days. For a cluster in a channel the documentation allows up to 90 days and advises keeping it under 30.
No minor upgrades lets patches and node upgrades through while holding the minor version. Channel only.
No minor or node upgrades holds both, and allows patches. Channel only.

The two narrower scopes can be set to run until the end of support for the cluster's minor version, and can be configured to track that date instead of one you type, so nobody has to remember to renew them. A cluster can hold up to 20 exclusions. Read the current limits on the maintenance exclusions page before you plan a long freeze.

One warning we give every client: blocking minor and node upgrades does not remove the work, it moves the work to you. Google's own wording is that if you use that scope you must perform those upgrades yourself, or GKE will upgrade the cluster at the end of support for the minor version. A freeze with no upgrade plan behind it is a deferred outage with a date on it.

gcloud container clusters update CLUSTER_NAME \
  --location=LOCATION \
  --add-maintenance-exclusion-name=year-end-freeze \
  --add-maintenance-exclusion-start=2026-12-15T00:00:00 \
  --add-maintenance-exclusion-end=2027-01-05T23:59:59 \
  --add-maintenance-exclusion-scope=no_upgrades

Moving between channels without a surprise upgrade

Changing the channel itself is one flag:

gcloud container clusters update CLUSTER_NAME \
  --location=LOCATION \
  --release-channel=regular

The flag is easy. The direction is where teams get hurt. Moving toward a faster channel can put the cluster in line for a version nobody has tested it against, because the destination channel's auto-upgrade target may already be ahead of where the cluster sits today. Moving toward a slower channel is the safer direction, and it does not roll a cluster backwards, since GKE does not downgrade a cluster to match a channel. So read the schedule table for the destination channel first and find where your current minor version sits in it. If the destination's auto-upgrade target is two minor versions ahead of you, what you have is a migration, not a setting change.

Our order on client projects is always the same: set the maintenance window first, then change the channel. Done that way, the first upgrade after the switch lands inside a window somebody chose.

What we set up on a client cluster first

Inventory every cluster in every project, with version and channel, in one table a non-engineer can read.
Write down each cluster's end of standard support date from the versioning page, so "we are fine" becomes a date.
Set a maintenance window on the real quiet hours of the business, in the business's timezone, not the cluster region's.
Choose the channel per workload rather than per company: Rapid for a staging cluster, where a broken upgrade is useful information, Regular or Stable for anything a customer touches.
Qualify the next minor version in a pre-production cluster before the production auto-upgrade date, not after it.
Add PodDisruptionBudgets and enough surge capacity that a node upgrade can drain cleanly, because a well-chosen window only helps if the workload survives being moved.
Route upgrade notifications somewhere a person reads, and put the next two auto-upgrade dates on the operations calendar.

Cost and risk notes

Windows, exclusions and channel changes cost nothing. Three things around them do. Extended support is billed differently from standard support, so if you are considering the Extended channel in order to hold a version longer, check the current GKE pricing page on the day you decide: that is a figure we verify per client rather than quote from a blog post. Surge upgrades add nodes for the length of the upgrade, which is a small and short bill. And qualifying a version in a pre-production cluster costs a few days of one cluster, the cheapest line here next to a failed production upgrade.

The risk that bites in practice is quieter than an outage. It is a cluster drifting to within weeks of end of support while everyone assumes upgrades are somebody else's schedule. No notification makes that safe. A date in a shared calendar does.

How Guanacos Tech helps

We run this as a fixed piece of work: the cluster inventory, the support dates, the maintenance windows, the channel decision per workload, one qualification run in pre-production, and a one page runbook so the next upgrade is a calendar entry rather than an incident. We are an independent consultancy and our engineers hold Google certifications, so you get the reasoning behind each setting along with the setting.

If you have a cluster nobody has logged into for a year, that is the normal starting point and not an embarrassing one. See what we do in Google Cloud consulting for small teams. A 30 minute call is enough to tell you the date your cluster is heading for and whether it needs moving.

Sources

Google Workspace or the email that came with your hosting: an honest comparison for a small business

Guanacos Tech — Wed, 30 Sep 2026 12:00:00 +0000

The call usually starts the same way. A client sends an invoice, the customer says it never arrived, and the message turns out to have been sitting in a junk folder for three days. The mailbox came free with the web hosting plan, set up years ago by whoever built the site, and nobody has looked at it since.

That is the real decision most small businesses face. Not Google Workspace against Microsoft 365, which people choose deliberately, but Google Workspace against the mailboxes bundled with hosting that cost nothing extra. Free is a strong argument. Here is what we check before telling a client to switch, and when we tell them not to bother.

What each option actually gives you

Hosting email means your mailboxes live on the same server as your website, managed through cPanel or your provider's own panel. You get a mailbox per address, webmail, IMAP and POP access, and a shared outbound mail server. Storage comes out of the hosting disk quota, and administration is a form in a control panel.

Google Workspace is a separate mail platform. Your MX records point at Google instead of your host, mail never touches the web server, and each person gets a Gmail mailbox plus Drive, Calendar, Meet and Docs. Administration happens in the Admin console: users, groups, aliases, security policy, audit logs.

The feature lists are easy to compare and mostly beside the point. Four things decide it: whether your mail arrives, what happens to the data when someone leaves, what a takeover would cost, and the twelve-month bill. In that order.

Shared reputation: the problem you do not see until mail bounces

This is the one that brings people to us, and it is structural rather than a misconfiguration you can tidy up.

On shared hosting, the outbound mail server is shared with every other site on that machine, and receiving providers judge the sending IP. If another account there buys a list or gets compromised and starts sending, the IP's reputation drops and your invoices go to spam alongside their spam. You did nothing and you have no lever to pull.

Hosting providers know this, which is why they publish sending caps. Hostinger, to take one whose limits are public, documents caps per day, per hour and per message on cPanel email, and separately warns that mail sent through PHP's mail() function is capped at 100 messages a day and 10 a minute, recommending authenticated SMTP instead (checked 30 September 2026). Those caps protect the shared IP. They are also the ceiling on your order confirmations.

The second half of the problem is authentication. Gmail's sender guidelines require every sender to publish SPF or DKIM for the sending domain, to have valid forward and reverse DNS on the sending IP, and to use TLS. For mail sent to personal Gmail addresses, the domain in the From: header has to align with either the SPF domain or the DKIM domain. Bulk senders also have to keep the spam rate in Postmaster Tools below 0.30%, and marketing messages need one-click unsubscribe.

None of that is impossible on hosting email: DKIM signing is often in the panel, and SPF is a TXT record you can write yourself. But you are authenticating a sender whose reputation you share with strangers, and a growing business eventually hits a cap it cannot raise. With Workspace, SPF is one include and Google signs with DKIM once you enable it:

; SPF, if Google Workspace is your only sender
example.com.   TXT   "v=spf1 include:_spf.google.com ~all"

; MX, one record
example.com.   MX    1 smtp.google.com.

Read Google's SPF documentation before editing anything: a record holds at most ten include: lookups, and hosting records tend to be crowded already.

Either way, check what your domain publishes today. A missing SPF record, unsigned DKIM or a stale hosting include is worth fixing on whichever platform you choose.

Storage, backup, and the day somebody leaves

Hosting mailboxes eat the hosting plan's disk. That works until it does not: a sales mailbox with ten years of attachments fills the quota, the site starts throwing errors, and the fix is to delete old mail or buy a bigger plan. Backups are whatever your host takes of the whole account, on their schedule.

Workspace storage is pooled across the organization rather than fixed per mailbox. Business Starter includes 30 GB per user, Business Standard 2 TB, and Business Plus and Enterprise Plus 5 TB, all drawn from one shared total. Pooled is the useful part: one person with a huge mailbox does not break anyone else.

Offboarding is where the gap gets uncomfortable. On hosting email, deleting a mailbox deletes the mail, and there is no built-in handover. In Workspace, deleting a user is a guided process: a super admin can transfer the departing person's Drive and Docs files and primary Calendar data to another account, and the account stays suspended until the transfer finishes. Google also documents that the deleted address is removed from the organization twenty days later, which is your window to restore an account you deleted in haste.

Where one person owns the client relationships, this is not an administrative detail. It is whether you keep the history when they resign.

Security: two-step verification, devices, recovery

Hosting mailboxes are usually protected by a password in a panel. Some providers offer a second factor on the hosting account itself, far fewer per mailbox, and almost none give you a way to require it. If a salesperson reuses a password that later turns up in a breach, you find out when customers receive invoices carrying someone else's bank details.

In Workspace, two-step verification is a policy you enforce rather than a setting you hope people find. The Admin console lets you turn it on for the whole organization or for a single organizational unit, and you can require security keys or passkeys specifically. Google's own guidance is to enforce security keys across all organizational units, with the caveat that in security-key-only mode users cannot generate their own backup codes, so an admin has to hand them out. That last detail matters: enforcement without a lockout plan creates a different emergency.

You also get what only exists on a managed platform: audit logs of who signed in from where, the ability to sign a stolen device out, and password resets that do not need a support ticket.

The real twelve-month cost

Hosting email looks free because it is bundled. It is not free, it is unpriced: you pay for it inside the hosting plan, and the disk quota is the budget.

Workspace is a per-user subscription, and the number that matters is the twelve-month total for the licenses you genuinely need, not the monthly headline. Two things move it. First, the payment plan: Google's billing documentation is explicit that the Annual/Fixed-Term plan carries the lowest per-user monthly price but commits you to a minimum license count you cannot reduce until renewal, while the Flexible plan bills monthly for the users you have, prorated, and lets you remove accounts at any time. With seasonal staff, Flexible usually wins even at the higher unit price. Second, the license count, which is where most quotes go wrong.

We read the current figure off Google's pricing page when we quote, rather than repeating one from memory, because list prices and introductory offers change. What we can tell you is how to count licenses:

Aliases are free. Google documents up to 30 email aliases per user at no extra cost, so a person who needs sales@ and ana@ needs one license and one alias, not two licenses.
Shared addresses are groups, not users. An alias belongs to one person, so info@, support@ and facturacion@ should be Google Groups that deliver to several people at no license cost.
Not everyone needs the same edition. If two people need the larger storage and meeting recording and the rest only need mail, the whole company does not have to sit on one plan.
Count what sits outside the subscription. Migration, a day of training and DNS work are real and one-off. Quote them separately.

Our own rates sit on how we work. A company of twelve people often needs eight licenses, and an honest count changes this comparison more than the plan choice does.

When hosting email is genuinely enough

We talk clients out of migrating more often than you would expect. Hosting email holds up when all of these are true:

Two or three mailboxes, low volume, mostly replies rather than outbound campaigns.
Nothing automated sends on the domain's behalf: no e-commerce order confirmations, no CRM, no invoicing system, no newsletter.
The mailboxes are not the record of anything anyone would need to read later.
Your provider gives you DKIM in the panel and you have published SPF and DMARC properly.
Nobody depends on shared calendars or shared files, which is the half of Workspace this comparison ignores.

A two-person studio invoicing by hand is fine. A ten-person firm whose accounting software emails clients is not. That is usually the line.

How we migrate when a client decides to switch

The order matters more than the tooling. Doing it out of order is what produces the lost-mail stories.

Inventory first. Every mailbox, forwarder, alias and autoresponder, plus everything that sends using the domain: the contact form, the invoicing system, the CRM, the printer.
Create users as you will pay for them. People as licensed users, shared addresses as groups, secondary ones as aliases.
Copy the mail with the old system still live. Migration runs over IMAP while hosting mail keeps delivering, so nothing is in flight at cutover.
Lower the MX TTL two days ahead, not on the morning of the cutover.
Change the MX records, then authenticate the same day. SPF updated for the new sender, DKIM enabled and published, DMARC at p=none with reports going somewhere you read.
Re-point everything still sending through the old server. This is the skipped step, and it is why order confirmations fail a week after an otherwise clean migration.
Watch the DMARC reports for two weeks before tightening the policy.

The full runbook, including the IMAP copy and the cutover hour, is in our guide to moving email off cPanel hosting.

How Guanacos Tech helps

We run this comparison as an audit or as the first step of a migration, and it takes about an hour: what your domain publishes, where mail actually leaves from, how many licenses you would really need, and whether the mailboxes hold anything you cannot afford to lose. Sometimes the answer is that your hosting email is fine and the SPF record is the thing to fix. We say so.

Our Google Workspace consultants will walk your domain with you on a 30-minute call and tell you what we would change, in what order, before anyone touches DNS.

Sources

Changing MX records to Google Workspace without losing a single message

Guanacos Tech — Tue, 29 Sep 2026 12:00:00 +0000

The MX change is the moment clients get quiet on the call. Everything else in a migration can be undone in an afternoon. This one feels like pulling a plug on the company phone line, and the question is always the same: what happens to mail that arrives mid-switch?

The honest answer is that nothing has to be lost, and the losses that do happen are almost never caused by the record itself. They are caused by an account that did not exist yet, an old mailbox that was shut off too early, or sending authentication that nobody updated. Here is the order we run for a client, and what we watch at each step.

What the MX record actually controls

An MX record answers one question for every mail server on the internet: when someone sends a message to your domain, which host should accept it? That is the whole job. It does not move the mail already sitting in your old mailboxes, it does not decide who is allowed to send as your domain, and it has nothing to do with your website.

That matters because the two halves of email break in different ways. Incoming mail follows MX. Outgoing mail is judged by SPF, DKIM and DMARC, which live in completely separate DNS records. We have seen a cutover go perfectly on the receiving side while every invoice the company sent that week landed in spam, because the SPF record still listed only the old host.

One more thing worth saying out loud: DNS does not switch, it expires. Every server that looked up your domain recently keeps the old answer for as long as the TTL allows, so mail arrives in two places for a while. Plan for the overlap instead of fighting it.

Lower the TTL first, days before you touch anything

The time to live, or TTL, is the number of seconds other servers may keep using a cached copy of your record before checking again. Google's own DNS guidance puts it plainly: a record with a TTL of 86400 seconds means changes take up to 24 hours to take effect, and it recommends a value of 3600 so that servers check every hour.

There is a catch that costs people a day. A shorter TTL only starts applying after the previous period has expired. If your MX record is sitting at 86400 and you lower it to 3600 an hour before the cutover, the rest of the internet is still entitled to the old answer for the next day. So the TTL change is its own step, done at least one full old-TTL period ahead. For a 24-hour record we lower it two days out.

Read what you have before you plan the window:

dig +noall +answer MX example.com
dig +nocmd +noall +answer TXT example.com | grep spf1

The number in the second column of the MX answer is the remaining TTL in seconds. That number, not the calendar, decides how early you start.

The values Google publishes today

Google's setup page now shows a single MX record pointing at smtp.google.com, and registrars usually want it at priority 1. Accounts that started before 2023 have the older set of values beginning with aspmx; Google states those legacy values are still supported and that no change is required if your mail is working. We do not rewrite a working legacy record during a migration. One risky change at a time is enough. Checked on the Google Workspace Help page for MX setup, 29 September 2026.

; what a current single-record setup looks like
example.com.    3600    IN    MX    1 smtp.google.com.

Two details cause most of the support threads. Registrar formats differ: some require the trailing dot, some want the priority and the host in one field as 1 smtp.google.com, and some add your domain to the value automatically so you end up with smtp.google.com.example.com. And the old MX records have to go. Google's instructions say to remove any other MX records, because mail may not work correctly if incorrect ones are left behind. A leftover record at priority 10 pointing at the old host is how half a company.s mail ends up in a mailbox nobody reads.

Create the accounts before you touch DNS

This is the step that actually loses messages, and it is not a DNS step at all. Google's guidance for avoiding problems during an MX change is to create your user accounts in the Admin console first, along with any groups or nicknames your domain uses.

Say a 12-person accounting firm has ten mailboxes, two shared addresses for clients, one address the billing software sends from, and an alias printed on an old business card. If facturacion@ exists on the old server but not in Workspace, mail to it starts bouncing the minute the record flips, and a bounce is not recoverable. We build the inventory from the old server's account list and from a month of logs, not from memory, because the addresses people forget are the ones machines use.

Dual delivery and split delivery: the two safety nets

You do not have to choose between the old system and the new one on a single evening. Google supports two arrangements for the overlap, both configured in the Admin console under Apps, then Google Workspace, then Gmail, then Routing.

Dual delivery puts a copy of each incoming message in both systems. Either side can be the primary one: Google recommends Gmail as primary, and notes that you might keep the legacy server as primary during a pilot or a migration, then move to Gmail only when the pilot ends. This is what we use when a team wants a week of reading mail in both places before they commit.

Split delivery routes incoming messages to two different systems based on the recipients you name, which fits a company moving one department at a time. Google's documentation notes that routing changes can take up to 24 hours, though they usually apply faster, so build that into the plan rather than testing five minutes after you save.

For a small business moving everyone at once, neither is strictly necessary. For a phased move, or a shared mailbox the business depends on, the overlap is cheap insurance.

The cutover hour, in order

Google's own advice is to schedule the change when your mail volume is low, an evening or a weekend. We add one rule: pick an hour when the people who can answer questions are still awake.

Confirm every address on the inventory exists in Workspace, including groups and aliases.
Confirm the sending side is ready: SPF authorizes Google, the DKIM key is published and turned on, and the DMARC record is in place.
Confirm the old mailboxes still accept mail and will keep doing so for at least a week.
Publish the Google MX record and delete every other MX record for the domain.
Re-read the record from outside your network with dig, not from the registrar screen.
Send a test message from an outside address, then reply from the new mailbox to something external.
Watch both systems for the rest of the evening. The old one keeps receiving for a while, and that is expected.

The mail that still arrives at the old host

Google is explicit that it can take up to 72 hours for new MX records to be recognized, and that until records have been updated worldwide you will still receive traffic at your old server. Read that as a week of caution, not a three-day countdown, because a domain that resolves everywhere on day two often has one stubborn sender on day five.

Two things keep that mail from being lost. First, leave the old mailboxes accepting and, where the host allows it, forwarding to the new addresses. Nobody should cancel the old hosting plan on cutover day, and we say so in writing before the project starts. Second, bring the history across properly. Google's data migration service and data import tool pull mail over IMAP from the Admin console under Data, then Data import and export, using a mapping file of source and destination addresses; the documentation notes a limit of 100 IMAP users per import and that you have to be signed in as a super administrator. Run the import after the cutover, then a second pass for anything that landed at the old host during the overlap.

Re-authenticate, then test with a real message

The receiving side is now Google. The sending side has to say so too, and this is where a clean MX change still produces a week of mail in spam folders.

If Google Workspace is the only thing sending for your domain, Google documents the record as v=spf1 include:_spf.google.com ~all, where ~all asks receivers to treat unlisted senders as suspicious. Most small businesses are not that simple: the shop, the CRM, the invoicing system and the helpdesk send too, and each one you add spends part of the 10-lookup budget SPF allows.

; Google plus one external sender, as an illustration
v=spf1 include:_spf.google.com include:sendgrid.net ~all

DKIM has to be generated and turned on in the Admin console, not just left to default behaviour. Google recommends the google selector prefix and a 2048-bit key, says to fall back to 1024 only if your DNS provider cannot handle the longer value, and notes that authentication can take up to 48 hours to start working. The Admin console may keep showing a message telling you to update DNS for up to 48 hours after the key is correct, which is worth knowing before someone starts changing things that were already right.

Then check it from the receiver's side rather than your own. Gmail's sender requirements state that all senders must set up SPF or DKIM, and that senders of 5,000 or more messages a day to Gmail must have SPF, DKIM and DMARC. Postmaster Tools has an authentication view showing the percentage of your mail that passes each check, which is the only number that settles an argument about whether a migration hurt deliverability.

How Guanacos Tech helps

We run MX cutovers as a scheduled hour with a written order of operations, because the failures here come from sequencing rather than from difficulty: an address that did not exist, a record deleted too early, a sending system nobody inventoried. Our Google Workspace migration consultants page sets out the scope we work to, including the overlap week and the authentication checks afterwards. Bring your current MX record and a list of everything that sends mail as your domain to a 30-minute call, and you will leave with the cutover hour, the risks specific to your setup, and what to keep running until the last sender catches up.

Sources

Your email lands in Gmail's Promotions tab: what actually moves it, and what is folklore

Guanacos Tech — Tue, 29 Sep 2026 12:00:00 +0000

Every few weeks a client forwards us the same screenshot: their own newsletter, sitting in the Promotions tab of their own Gmail. The question underneath is always "is something broken?"

Usually nothing is broken. Promotions is part of the inbox, not the spam folder. Most of the advice circulating about how to escape it is folklore that got repeated until it sounded like documentation. Here is what the primary sources actually support, what they do not, and the order we work through it on a client account.

Promotions is not spam, and the difference decides what you fix

Gmail sorts incoming mail into categories: Primary, Promotions, Social, Updates and Forums. Google's help page for categories describes the sorting as automatic, and tells the user to move a message when it lands in the wrong place so that Gmail learns their preference. Every one of those categories is the inbox. The message was delivered. It is searchable, it fires a notification on most setups, and it counts as inbox placement by any sane definition.

The spam folder is a different outcome produced by a different set of signals: authentication failures, complaint rates, domain and IP reputation. This distinction is not academic. It decides which week of work you do next. We have watched a small business rewrite every subject line it owned for a month while its real problem was an unsigned third-party sender.

So establish which problem you have before anything else. If the mail arrives and you can find it under Promotions, you have a categorisation question and this post is the right one. If it never arrives, or it lands in Spam, or you are getting bounces, start with the 550 5.7.1 reputation guide instead.

What Google actually says decides the category

Google does not publish the classifier, and anyone who tells you they have reverse engineered it is selling something. What the help documentation does state is narrower and more useful: the sorting is automatic, and when a person moves a message to a different category, Gmail uses that choice to sort mail from that sender for that person in future. The same page walks users through turning categories off entirely, or building a filter that assigns one.

Read that carefully and you land on the thing most Promotions-tab advice quietly ignores. Category is a property of the relationship between one sender and one recipient, not a property of your message. Two people on the same list can receive a byte-identical message and see it in two different tabs, and both outcomes are correct. Any tool or agency promising to "move your emails to Primary" is promising something no sender controls.

What a sender does control is whether the mail describes itself honestly: authentication that proves the domain, a list of people who asked for it, an unsubscribe that works on the first click, and content that earns opens and replies. Those are worth doing whatever tab you end up in, because they are the same signals that keep you out of Spam.

Five claims that do not survive a look at the sources

These come up in almost every conversation we have about the Promotions tab. None of them has a primary source behind it, and two of them are actively harmful.

"Remove the unsubscribe link and you will land in Primary." Google's sender guidelines require marketing and subscribed messages to include a clearly visible unsubscribe link in the message body and to support one-click unsubscribe. Stripping it does not buy Primary. It puts you on the wrong side of a published requirement and pushes people toward the spam button, which is the one signal that genuinely hurts you.
"One image, no links, and you are safe." No primary source ties tab placement to an image count or a link count. What a single-image email does reliably is break for anyone using a screen reader and turn into a blank rectangle for anyone with images off. You would be trading a measurable accessibility loss for an unmeasurable guess.
"Avoid the word free." Word-level triggers are a carry-over from the keyword filters of twenty years ago. Nothing in Google's current sender documentation describes a banned vocabulary, and writing around a word list makes copy worse in ways your readers can feel.
"Ask your whole list to drag you to Primary." This one is half true, which is why it survives. Moving a message does teach Gmail that recipient's preference, and Google documents exactly that. It works for the one person who does it. As a campaign it converts at a rate that rarely justifies the effort, and it does nothing for next month's subscribers.
"Plain text always lands in Primary." Plenty of plain-text bulk mail sits in Promotions, and plenty of styled transactional mail sits in Primary. The format is not the lever.

Annotations: design for the tab instead of fighting it

There is a documented way to make a promotional message work harder inside the Promotions tab, and it comes from Google. The Gmail developer documentation for Promotions tab annotations describes markup, expressed as JSON-LD or microdata in the message, that lets Gmail surface a preview image, a deal with its discount code and expiry date, and a sender logo next to the subject line.

Notice what that is and is not. Google publishing an interface for the Promotions tab is a fairly direct statement that the tab is worth designing for rather than an exile. It is not a route out of it. For a shop or a restaurant sending genuine offers, a week spent on annotations and a cleaner offer is a better investment than a year spent chasing Primary.

Authentication is the floor, not the lever

Since 1 February 2024, Google has required senders of more than 5,000 messages a day to Gmail accounts to authenticate with SPF and DKIM, publish a DMARC record for the sending domain, have valid forward and reverse DNS on the sending IP, transmit over TLS, and keep the spam rate reported in Postmaster Tools below 0.30%. The guidelines add that senders should stay under 0.10% and should never let the rate reach 0.30%.

None of that is a Promotions-tab control, and we want to be honest about that. It is the floor. Fall below it and you will have a delivery problem large enough to hide the tab question completely. If you have no DMARC record yet, the one that starts collecting evidence without changing how anything is delivered looks like this:

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

A policy of p=none asks receivers to report what they see and to change nothing. Two weeks of those reports will tell you every system sending as your domain, including the invoicing tool and the CRM nobody mentioned in the kickoff call. That inventory is the real deliverable.

One-click unsubscribe, done the way the standard describes

Marketing and subscription mail needs both of these headers, on every message:

List-Unsubscribe: , 
List-Unsubscribe-Post: List-Unsubscribe=One-Click

RFC 8058 defines that pair. The second header is the signal that the URL is safe to POST to, which exists because mail software sometimes fetches URLs found in headers and used to unsubscribe people by accident. The sender has to stand up an endpoint that accepts an HTTP POST at that address and must not answer it with a redirect, because redirected POSTs have never worked reliably across clients. Google's guidance is to honour the request within 48 hours and to keep the visible link in the body as well.

This belongs in a post about tabs for one reason. The alternative to an unsubscribe that works on the first click is the spam button, and the spam button is the signal that moves you from a tab you dislike to a folder nobody reads.

Measure instead of guessing

Postmaster Tools reports spam rate, domain and IP reputation, authentication results and delivery errors for mail you send to personal Gmail accounts. It does not report tab placement, and nothing official does. If a dashboard claims to show you your Primary-versus-Promotions split, ask where the number comes from. Usually it is a handful of seed accounts, and a seed account has no history with your domain, which is precisely the input that decides the category for a real subscriber.

The instruments that do tell you something are the ones you already have. Track open and reply rate by segment rather than for the list as a whole, because a tab change shows up as a step down in engagement for one group and not another. Watch the spam rate in Postmaster Tools as an early warning. If you want help reading those graphs, we wrote a walkthrough of the Postmaster Tools dashboards.

What we check on a client account, in order

Which problem it actually is. Delivered to Promotions, or not delivered. Five minutes with a test send and the raw headers settles it.
Every sending source, authenticated. SPF and DKIM passing and aligned for the newsletter platform, the invoicing tool, the CRM, the store and the helpdesk. This is where most of the findings are.
DMARC at p=none with reports going somewhere a human reads. Two weeks of data before any policy change.
The unsubscribe path, end to end. Both headers present, the POST endpoint actually answering, the visible link in the body, and the suppression list honoured inside 48 hours.
The list itself. How addresses were collected, when the dormant segment last opened anything, and whether a purchased list is poisoning a domain that took years to build.
Segmentation and cadence. Sending less mail to people who want it beats sending more to everyone, on every metric that Gmail can see.
Annotations, last. Only once the mail is authenticated, wanted and measurable, and only if it is genuinely promotional.

Notice that Promotions never appears as a target. If the work above is done, the tab sorts itself out for the recipients who care, and the recipients who do not care were never going to convert from Primary either.

How Guanacos Tech helps

We do this work for small and mid-sized businesses across North America and Latin America, in English and Spanish, and it almost always starts the same way: a screenshot, a worry, and an hour of evidence that turns the worry into a short list. If the mail is genuinely being filtered rather than sorted, that is email deliverability consulting for small business and we fix it at the DNS and sender level. If it is sorted into Promotions and the fundamentals are sound, we will tell you so rather than sell you a month of work, and we will show you the evidence. Book a 30-minute call and bring the screenshot and one bounced message if you have one.

Sources

Business email on your own domain: how we set it up so it works from day one

Guanacos Tech — Mon, 28 Sep 2026 12:00:00 +0000

Say a twelve person accounting firm has been sending from info@sudominio.com for six years. The mailbox came bundled with the hosting plan, nobody remembers who configured it, and this quarter two clients swore the invoice email never arrived. It did arrive. It went to spam, twice, and by the time anyone checked, the folder had been emptied.

That is the shape of most of the business email work we pick up. The domain is fine. The company is fine. The mail was set up once, quickly, by whoever was closest to the hosting panel, and then it was never looked at again. This is the order we build it in when we start from scratch, and the order we rebuild it in when we inherit something that half works.

Why the mailbox that came with your hosting costs more than it looks

Shared hosting bundles email because bundling is cheap, not because the host is good at delivering mail. Three things follow from that, and all three show up in client work.

You send from an address you do not control. The outbound IP belongs to the server, and it is shared with every other site on it. Your sending reputation is partly the average of what strangers do with their contact forms.
Nobody owns the accounts. When someone leaves, there is often no way to suspend the mailbox, transfer it, or read what is in it, short of asking for the password.
Authentication is usually half done. The panel may publish an SPF record for you. Very few sign outbound mail with DKIM unless you go and turn it on, and almost none publish DMARC.

None of that is fatal at five messages a day. It becomes expensive the first time an invoice, a quote or a password reset does not land.

The real options, and what separates them

For a small business there are three shapes worth considering, and the differences that matter are not the feature grids.

Keep mail on the hosting panel. Cheapest on the invoice. You accept a shared reputation, thin recovery options and manual authentication.
A dedicated mailbox platform. Google Workspace, Microsoft 365 or Zoho Mail. You get an admin console, per user accounts you can suspend and transfer, and DKIM signing you switch on once.
A platform plus a separate sender for application mail. Your store, your CRM and your invoicing software send from your domain too. They need their own authentication whichever platform you pick.

Judge them on four questions. Who owns the sending reputation. Can an administrator lock an account in under a minute. Is the mail recoverable if the laptop is stolen. Can a third party sender be authorised without breaking everything else. Feature lists rarely answer any of those.

On cost, compare list prices against what an hour of nobody being able to send is worth to you. Google Workspace Business Starter is published at USD 8.40 per user per month on the Flexible Plan, list price checked on 28 September 2026 on the Google Workspace pricing page, with 30 GB of pooled storage per user; the Business editions are sold for up to 300 users. We do not quote our own figures here, and neither should anyone selling you a platform without seeing your domain first. What an engagement covers is on how we work.

Your domain: where it is registered and where its DNS actually lives

This is the step that costs the most wasted hours, and it is not technical. Where you bought the domain and where its DNS records are answered from are two different places, and they are often not the same company.

Before touching anything, we look up the domain's nameservers and confirm which control panel answers for it. Editing a TXT record at the registrar while the nameservers point at a third party DNS provider produces a record that is real, saved, and invisible to the internet. People lose entire afternoons to this.

Two habits worth keeping. Lower the TTL on the mail records a day before you plan to change them, so a mistake expires in minutes instead of hours. And write down the current records before you edit them, because the only reliable rollback is the one you can paste back.

Users, aliases and groups: what needs a licence and what does not

A common way to overpay is to buy a licence for every address the company wants to exist. You need a licence for every person who needs a mailbox. Addresses are cheaper than that.

Users. One per human who signs in and sends. This is what you pay for.
Aliases. Google Workspace lets you add alternate addresses to an existing user at no extra cost, up to 30 per user. If billing and sales are both handled by the same person, they are aliases, not accounts.
Groups. A shared address such as info@ that several people answer is a group, not a mailbox. Turned on as a Collaborative Inbox, members can take a conversation, assign it to someone else and mark it complete, which is what a small team usually wanted from a shared account in the first place.

Set this up before you migrate anything. Deciding after the fact which of the eleven addresses were really people is slower than deciding first.

Authenticate on day one, not after the first complaint

Gmail's sender guidelines, in force since February 2024, require every sender to authenticate with SPF or DKIM, to have valid forward and reverse DNS for the sending domain or IP, to use a TLS connection, and to keep the spam rate reported in Postmaster Tools below 0.30 percent. Senders above 5,000 messages a day to Gmail must also publish DMARC and support one click unsubscribe on marketing mail. A new domain that skips this is not neutral, it is unauthenticated.

Four DNS records carry the whole thing. For a new Google Workspace domain, mail routing is a single MX record; older domains may still be on the five record set Google used before, and there is no urgency to change one that works.

; Mail routing, new Google Workspace setups
sudominio.com.            3600  IN  MX   1 smtp.google.com.

; SPF, one record per domain, no more than ten DNS lookups
sudominio.com.            3600  IN  TXT  "v=spf1 include:_spf.google.com ~all"

; DMARC, monitoring first
_dmarc.sudominio.com.     3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@sudominio.com"

DKIM is the one that is not copied from a guide, because the key is yours. In the Admin console it is under Apps, Google Workspace, Gmail, Authenticate email: generate a new record, choose 2048 bit if your DNS provider supports it, and keep the default selector prefix google unless the domain already uses it. Two details catch people out. Google's documentation says you may need to wait 24 to 72 hours after turning on Gmail before the key is available in the console, so this is not a same hour task on a brand new tenant. And if your DNS provider caps a TXT string at 255 characters, a 2048 bit key has to be split into several quoted strings inside one record value, not into several records.

DMARC goes last, and it goes out at p=none. Google recommends starting there so you can read who is sending as your domain before anything gets rejected, and waiting about 48 hours after SPF and DKIM are live before publishing it. Nothing about DMARC is configured in the Admin console; it is a DNS record and only a DNS record. Tightening to quarantine and then reject comes later, once the reports show you the full list of senders.

The SPF record has a hard limit worth knowing before you add your third sender: ten DNS lookups, counted across every include. Workspace plus a CRM plus an invoicing platform can reach it faster than you expect, and the failure is silent. We walk through the counting and the fixes in the SPF too many DNS lookups guide.

Signatures, devices and the day someone leaves

The parts nobody plans for are the parts that get called in as emergencies later.

Two step verification, enforced. Optional two step verification is off for exactly the people you most need it on. Enforce it with a short enrolment window and a documented recovery path for the owner's own account.
Recovery for the administrator. A super administrator locked out of the console with no recovery phone and no second admin is a multi day outage. Create a second administrator on day one.
Offboarding written down. Suspend the account, transfer the files, set a forward to whoever inherits the relationship, then release the licence. Deleting the account first loses the mail.
Signatures set centrally. Eleven people writing their own signature produces eleven versions of the company address. Set the template once at the organisation level.

If you already have mail somewhere else

Almost nobody starts from an empty domain. The sequence that keeps everyone working is the same whether the mail sits on cPanel, a personal Gmail account or an old Microsoft tenant: build the users and groups on the new platform first, copy the mail across while the old system is still receiving, and only then change the MX record. The cutover is the last step, not the first.

Two things to schedule around it. Mail can arrive at the old host for hours after the change while DNS caches expire, so leave the old mailboxes reachable rather than deleting them the same day. And every form, store and invoicing tool that sends using your domain needs re authorising against the new platform, because the MX change moves incoming mail and does nothing at all for outgoing. We wrote up the full sequence for the most common starting point in moving email off cPanel to Google Workspace.

How Guanacos Tech helps

We set up business email on a client's own domain end to end: the platform choice with the reasons written down, users, aliases and groups sized so you are not paying for addresses, the four DNS records published and verified, and a first read of the DMARC reports two weeks later to catch the sender nobody mentioned. If you would rather hand it over than learn a DNS panel, that is what Google Workspace consultants are for. A 30 minute call is enough for us to look at your domain and tell you what is actually missing.

Sources

Receipts that pass SPF and still fail DMARC: SendGrid, Mailgun and Amazon SES alignment

Guanacos Tech — Mon, 28 Sep 2026 12:00:00 +0000

A ten person online store we would typically work with had a complaint that sounded like nothing. Order confirmations from the shop platform arrived fine. Password resets and payment receipts, sent through a transactional provider by the developer, landed in Gmail's spam folder about half the time. Someone had already checked SPF, SPF passed, and the conversation moved on to subject lines and images.

SPF passing is not the test. DMARC asks a second question, and transactional mail is where the answer usually goes wrong. It is also invisible from the outside: the record looks correct, the provider dashboard says the domain is verified, and the mail still fails.

Why transactional mail fails DMARC while SPF looks fine

DMARC does not care that a message passed SPF. It cares whether the domain that passed is the domain your reader sees. That is alignment, and RFC 7489 fits in one sentence: a message passes DMARC when SPF passes and the SPF domain aligns with the From header, or when DKIM passes and the DKIM domain aligns, or both. Only one of the two has to align.

Google says the same thing from the receiving side. Its sender guidelines require senders of more than 5,000 messages a day to Gmail accounts to publish SPF and DKIM and a DMARC record, and the From domain must align with either the SPF domain or the DKIM domain. Both mechanisms are required, one alignment is enough, and mail that fails can be rejected with a 5.7.26 error. Guidelines checked 28 September 2026.

Marketing platforms usually break this on the DKIM side, which is what the guide on Mailchimp, HubSpot and Klaviyo alignment covers. Transactional providers break it somewhere more specific: the envelope.

Envelope sender versus From header

Every message carries two sender addresses and most people only ever see one.

The envelope sender, also called the return path or MAIL FROM, is the address the sending server hands over during the SMTP conversation. Bounces go there. Nobody reads it. SPF authenticates this one.
The From header is the address in the message itself, the one the recipient sees and the one a phisher would want to forge. DMARC protects this one.

When both belong to you, SPF alignment happens by itself. When a provider sets the envelope to its own domain and leaves your name in the From header, SPF passes for the provider and aligns with nothing. The receiver then has exactly one chance left: DKIM. If DKIM signs with the provider's domain in the d= tag instead of yours, DMARC fails, and the report you eventually read shows a pass for SPF next to a fail for the message.

Alignment has two modes and the default is the forgiving one. Relaxed alignment, aspf=r and adkim=r, accepts any subdomain of the same organizational domain, so mail.example.com aligns with example.com. Strict alignment demands an exact match. Almost every fix below works because relaxed is the default.

From here, everything is one of two moves: make the envelope domain yours, or make the DKIM d= yours.

SendGrid: domain authentication does both, if you finish it

An API key is enough to send mail through SendGrid. It is not enough to pass DMARC. The step that matters is domain authentication, previously called sender authentication, and it is a set of CNAME records you publish on your own domain rather than TXT records you paste in.

With Automated Security switched on, SendGrid generates three CNAMEs: two for DKIM and one that creates a branded subdomain used for the return path. The DKIM records use the selectors s1 and s2, so you publish something shaped like this, with the target values taken from your own dashboard because they carry account-specific identifiers:

s1._domainkey.example.com.   CNAME   s1.domainkey.uNNNNNN.wlNNN.sendgrid.net.
s2._domainkey.example.com.   CNAME   s2.domainkey.uNNNNNN.wlNNN.sendgrid.net.
emNNNN.example.com.          CNAME   uNNNNNN.wlNNN.sendgrid.net.

Two DKIM selectors rather than one is how SendGrid rotates keys without your involvement. Once verified, SendGrid signs your mail with your domain in d=, so DKIM aligns, and the branded subdomain puts the return path inside your organizational domain, so SPF aligns under relaxed mode as well. That is a message that passes DMARC on both mechanisms, which is where you want a receipt to be.

Two things go wrong at this step, repeatedly. The first is a DNS provider that refuses underscores in CNAME record names, which is common on older shared hosting panels. SendGrid's answer is to turn Automated Security off in the advanced settings and publish MX and TXT records manually instead, at the cost of handling key rotation yourself. The second is a provider that proxies records by default, Cloudflare being the usual example: a proxied authentication CNAME resolves to the proxy, not to SendGrid, so verification fails or stops working later. Every record in that set has to be DNS only.

Mailgun: the sending subdomain does most of the work

Mailgun asks you to verify a domain before it will send, and the verification exists for two reasons: to prove you own the name, and to authorise Mailgun's servers to send as it. Its documented setup is two TXT records, one for SPF and one for DKIM, and its guidance is to use a subdomain such as mg.example.com rather than the root domain, which keeps Mailgun's sending reputation separate from the mail your staff sends by hand.

mg.example.com.                 TXT   "v=spf1 include:mailgun.org ~all"
mx._domainkey.mg.example.com.   TXT   "k=rsa; p=MIGfMA0GCSq..."

That subdomain is the reason Mailgun is usually the easiest of the three. Mail leaves with the envelope sender on your sending domain and DKIM signed with d=mg.example.com, and under relaxed alignment both line up with a From header at example.com. Publish the SPF record on the subdomain, not on the root; a second SPF record at the root is not a fix, it is a permanent error, because a domain may publish exactly one.

Amazon SES: Easy DKIM aligns, the default MAIL FROM does not

SES is the one that catches out careful people, because the default configuration passes SPF and fails DMARC at the same time.

When you send through SES without configuring a MAIL FROM domain, the envelope sender is a subdomain of amazonses.com. That domain publishes a valid SPF record covering the SES infrastructure, so an SPF check passes cleanly. It just passes for Amazon. The envelope domain and your From domain do not match, so SPF alignment fails and DMARC can only be satisfied through DKIM.

Easy DKIM does satisfy it. SES publishes CNAME records that let it sign with your domain, so a verified identity with Easy DKIM enabled aligns on DKIM and passes DMARC. Plenty of small senders stop there and are fine. It is a single point of failure though: one broken DKIM record, one message modified by a forwarder, and there is no SPF alignment underneath to catch it.

The fix is a custom MAIL FROM domain, which is always a subdomain of the identity you verified. AWS documents two records on it: an MX record so that bounce feedback reaches SES, and a TXT record publishing SPF.

mail.example.com.   MX    10 feedback-smtp.us-east-1.amazonses.com.
mail.example.com.   TXT   "v=spf1 include:amazonses.com ~all"

Use the region you actually send from in the MX value. Because the custom MAIL FROM domain is a subdomain rather than an exact match, this only aligns under relaxed SPF policy, which is the default; a DMARC record carrying aspf=s will reject the whole arrangement. Set it up in each region and each account you send from, not just production, or the first invoice sent from a staging account will be the one that fails.

One domain, three senders, ten lookups

Most of the domains we audit are not sending through one provider. There is Google Workspace for the staff, a store platform for order mail, a transactional provider for receipts, and something nobody remembers enabling for the monthly newsletter. Each one wants an include: in the SPF record, and SPF allows ten DNS lookups per evaluation under RFC 7208 section 4.6.4. Exceed it and the result is PermError, which most receivers treat as no SPF at all.

Subdomains are the way out. A transactional provider on mail.example.com and a marketing platform on news.example.com each carry their own SPF record with their own lookup budget, while the root keeps only the senders that use the root, and relaxed alignment means all of them still satisfy DMARC for a From header at example.com. If you are already at the limit, the guide on getting under the SPF 10-lookup limit has the counting method.

Which policy belongs on each subdomain is covered in the post on DMARC subdomains and the sp tag.

What we check before and after the change

This is the order we work in on a client domain, and it is deliberately boring.

Inventory first, DNS second. Read two weeks of DMARC aggregate reports and list every source sending as the domain. Changing records before you know who sends is how invoices stop arriving.
Confirm the policy is still p=none while the work is in progress, with a rua address somebody reads. Nothing below is safe to do under enforcement.
Fix one provider at a time and send a real message after each one, to a mailbox on a different platform than the one you use daily.
Read the headers of that message rather than trusting a dashboard. The Authentication-Results line names the SPF domain and the DKIM d= value, which is the only place alignment is visible.
Watch one more reporting cycle before touching the policy, then ramp, quarantine before reject, with the third-party sender checklist done rather than assumed.

The failure we see most often is step three skipped: three providers fixed in one afternoon, one of them wrong, and no way to tell which without starting over.

How Guanacos Tech helps

We are an independent consultancy with Google-certified engineers, working with small and mid-sized companies across North America and Latin America in English and Spanish. Transactional mail is a normal way for this work to start: receipts going missing, one developer who owns the API key, and nobody who owns the DNS zone. We build the sender inventory from your own reports, fix each provider so it aligns on both mechanisms where the provider allows it, keep the SPF record inside its lookup budget, and then take the policy up to enforcement on a schedule instead of a hope.

If you want to look first, the DMARC report analyzer and the email troubleshooter are free and need no account. If you would rather hand it over, here is email deliverability consulting for small business and how we work. Bring a bounced receipt and its full headers to the call and we can usually name the cause on the screen.

Provider documentation for SendGrid, Mailgun and Amazon SES checked 28 September 2026.

Sources

NVIDIA T4 and P4 GPUs lose support on 1 August 2027: the migration we plan now

Guanacos Tech — Fri, 25 Sep 2026 12:00:00 +0000

Say a twenty person video studio in Guatemala City has two Google Cloud VMs with NVIDIA T4 GPUs attached. One runs nightly transcoding. The other is a Windows virtual workstation that an editor logs into from home three days a week. Both were built in 2021 by a contractor who has long since moved on. Nobody opens the Cloud console anymore, because nothing is broken.

That is the profile a GPU end of support notice hurts most. The machines keep working right up to the day they stop, and the day is already on the calendar.

What changed, and the date that matters

In the Google Cloud release notes for 22 September 2026, Compute Engine marked the NVIDIA T4 GPUs (nvidia-tesla-t4 and nvidia-tesla-t4-vws) and the NVIDIA P4 GPUs (nvidia-tesla-p4 and nvidia-tesla-p4-vws) as deprecated, with an end of support date.

The end of support date for both is 1 August 2027. Google's own end of support page states it plainly: until that date, resources running T4 GPUs keep working normally, and as of 1 August 2027 you cannot create, launch or access any Google Cloud resource that runs them. The P4 follows the same date and the same wording.

This is not a preview or a rumour. It sits in the published deprecation pages, and it has a sibling that already landed: the NVIDIA P100 reached end of support on 15 September 2026, ten days before we wrote this. If you were still on a P100, that decision has already been made for you.

The wording to take seriously is access. This is not only a ban on creating new machines. A VM that exists but cannot be started after that date is an offline machine with a disk attached, and the disk keeps billing.

Who this affects among small and mid-sized businesses

The T4 was the workhorse of cheap GPU compute for years. It is cheap enough that small teams put it on things a larger company would never accelerate. In client projects we see it in five places.

Inference on an N1 VM. A single T4 attached to a general purpose machine, running a transcription model, an OCR pipeline, an image classifier or a recommendation service.
Virtual workstations. The -vws variants exist for CAD, video editing and 3D work delivered to a remote desktop. Compute Engine attaches the NVIDIA RTX Virtual Workstation licence automatically when you create that kind of instance, which is why the cost sits quietly inside the VM line on the bill.
GKE node pools. A node pool pinned to T4 accelerators in a cluster somebody set up once.
Dataflow pipelines and Managed Service for Apache Spark jobs whose worker configuration names the T4 explicitly.
Cloud Workstations configurations and Gemini Enterprise Agent Platform workloads that reference the T4 as their accelerator.

The common thread is that in every one of those places the GPU model is written into a config file, a template or a Terraform resource, not chosen by a human each morning. Nobody is going to notice the deprecation by looking at a screen. Something has to go and read the configuration.

What we check first on a client project

Before anyone proposes a migration, we want a complete list. The first pass is one command per project, from the documented set of common Compute Engine commands:

gcloud compute instances list \
  --filter="guestAccelerators.acceleratorCount>0" \
  --format="table(name,zone,guestAccelerators.acceleratorType,guestAccelerators.acceleratorCount,disks.type)"

Run it against every project in the organisation, not just the one called production. GPU VMs have a habit of living in a project named after a proof of concept from three years ago.

Then we check the places that command does not reach:

Instance templates and managed instance groups. The running VMs may be fine while the template that recreates them still names a T4. That is the failure that wakes you up at 3am after an autoscaling event in August 2027.
GKE node pools. List the node pools and read the accelerator on each, including pools scaled to zero.
Dataflow templates and Spark job definitions that set a worker accelerator.
Cloud Workstations configurations.
Infrastructure code. Terraform, Deployment Manager, shell scripts in a repo. Grep for tesla-t4 and tesla-p4 across every repository, including the ones nobody has committed to in a year.
Committed use discounts. Existing one year and three year commitments on T4 stay valid until their scheduled expiration, but new three year commitments on T4 cannot be purchased or renewed. Any commitment that would expire close to August 2027 needs a decision now rather than an automatic renewal into a dead end.
Whether the workload still needs a GPU. Some of the pipelines we inherit were accelerated because a T4 was cheap, not because the maths required it. Two of the migrations are a delete.

The move, in the order we do it

Google's recommended targets are the G2 machine series with NVIDIA L4 GPUs and the G4 machine series with NVIDIA RTX PRO 6000. The important structural detail, and the one that surprises people: you cannot change an existing instance in place from an N1 general purpose machine type to an accelerator-optimized machine type. There is no edit that turns a T4 VM into an L4 VM. You build a new instance and move the data.

Pick the target and the zone. G2 and G4 are not offered in every zone that offered T4. Check the GPU locations page for your region before you promise anyone the machine stays where it is. Sometimes the honest answer is that the workload moves region, and that has latency and data residency consequences worth raising early.
Rescue Local SSD data. If the old instance uses Local SSD disks with anything you want to keep, copy their contents to a Persistent Disk volume first. Local SSD data does not survive the move, and it does not survive a stop.
Create the new G2 or G4 instance. Install the drivers fresh. For a virtual workstation this means the NVIDIA RTX Virtual Workstation drivers, not the standard ones.
Move the Persistent Disk volumes. Detach from the old instance, attach to the new one.
Re-test the actual workload before deleting anything. The T4 is Turing and the L4 is Ada Lovelace. A container image with a pinned CUDA or driver version, a compiled kernel, or a model artefact built for a specific compute capability can refuse to load. This is where the real work is, and it is the reason we do not schedule the migration for July 2027.
Update everything that creates machines. Instance templates, GKE node pools, Dataflow worker settings, workstation configurations, Terraform. A migrated VM with an un-migrated template is not migrated.
Delete the old instances only after a full business cycle has run clean on the new ones. A month end is a good marker for most of our clients.

Cost and risk notes

We will not print GPU prices here, because they move and a stale figure in a blog post is worse than no figure. Price your specific configuration in the Google Cloud pricing calculator on the day you plan, and check it again before you commit.

What we can tell you is that the shape of the bill changes. A T4 was an accelerator you attached to an N1 machine you sized yourself, so CPU and GPU were independent. G2 and G4 are accelerator-optimized series with fixed ratios of GPU to vCPU and memory. If your T4 box was a small CPU with one GPU, the nearest supported machine may give you more CPU than you asked for. That is not automatically more expensive, because Google's guidance says customers moving from T4 to L4 can see two to four times better performance, and a job that finishes in a third of the time on a per-second billed machine can land cheaper even at a higher hourly rate. Measure your own workload. Do not accept either the optimistic or the pessimistic version without a benchmark.

Three risks we flag on every one of these projects:

The forgotten machine. August 2027 feels far away, which is exactly why the editor's virtual workstation will still be on a T4 in July 2027. Put the inventory in a ticket with a date, not in someone's head.
The commitment trap. Renewing a discount on hardware with a published end of support date locks money to a machine you have to leave.
The silent template. Autoscaling and node repair recreate machines from templates. A template that names a retired accelerator turns a quiet Tuesday into an outage.

How Guanacos Tech helps

We do this as a fixed piece of work: inventory every GPU across every project, map each one to a workload and an owner, test the L4 or RTX PRO 6000 replacement against the real job, and hand you a migration plan with dates that sit well before the deadline rather than on top of it. If the honest answer for a given workload is that it no longer needs a GPU, we say that too, and the cost saving is yours.

If you want a second pair of eyes on a Google Cloud project you inherited, that is the kind of thing our Google Cloud consulting for small teams work starts with. Book a 30 minute call and bring your project IDs.

Sources

What is DMARC, and how to set it up without breaking your own email

Guanacos Tech — Fri, 25 Sep 2026 12:00:00 +0000

A twelve-person accounting firm calls us in the last week of the month because their invoices stopped arriving. Not all of their mail: the messages people write by hand from Gmail still land fine. It is the ones the billing system sends that vanish. Somebody on a forum told them to set up DMARC, they pasted a record they found online, and by the afternoon the CRM had gone quiet too. That is a normal way to arrive at this topic, and it is fixable in an afternoon once you know what DMARC is actually checking.

DMARC is not a spam filter, and it is not a switch that makes your mail deliver better. It is a public instruction from you, the owner of the domain, to every mail server that receives a message claiming to be from you. It says two things: here is how to tell my real mail from mail that only claims to be mine, and here is what I want done with the mail that fails that test. Written down it is one line of DNS. Understood, it is the only part of email authentication that tells you who is sending as your domain.

The problem DMARC solves

Anyone can write your domain in the From line of a message. That is not a bug in a particular mail server, it is how the format works, and it is why a convincing fake invoice from your own domain is such a cheap attack. Two older mechanisms each close part of the gap.

SPF is a list, published in your DNS, of the servers allowed to send mail for your domain. DKIM is a signature added to the message itself, checked against a public key you publish in your DNS. Both are useful and both have the same blind spot: neither one is tied to the address your reader sees in the From line. A message can pass SPF for a completely different domain and still show your name to the person reading it.

DMARC is the rule that connects the two. It asks a further question, and then it does something almost no other part of email does: it sends you a report.

Alignment is the whole trick

To pass DMARC, a message has to pass SPF or DKIM, and the domain that passed has to match the domain in the From header that your reader sees. Google states both halves plainly in its own documentation: outgoing messages must pass either SPF or DKIM, and for direct mail the domain in the From header must be aligned with either the SPF domain or the DKIM domain. Passing one of the two is enough. Passing neither in a way that matches your domain is a DMARC failure, however clean the rest of the message looks.

There are two strictness settings for that match. Relaxed, which is the default, accepts a match at the level of the organisational domain, so mail signed for mail.example.com aligns with a From address at example.com. Strict requires the domains to be identical. Google's own troubleshooting guidance is worth repeating here: strict alignment can push legitimate mail from associated subdomains into spam, and relaxed alignment usually gives enough protection against spoofing. Unless you have a specific reason, leave it relaxed.

Alignment is also where the invoice problem in the first paragraph comes from. Say the billing system sends as facturacion@example.com but its servers use a return path on the vendor's own domain and sign with the vendor's DKIM key. SPF passes. DKIM passes. DMARC fails, because neither passing domain is yours. A record set to reject on day one turns that from an authentication detail into missing invoices.

Your first record: p=none and somewhere to send the reports

Order matters more than speed. Google's guidance is to have SPF and DKIM set up, and in place for at least 48 hours, before you enable DMARC. If you skip that, mail from your domain will probably have delivery problems.

The record is a single DNS TXT record on the _dmarc host of your domain. The v and p tags come first; the rest can be in any order.

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

p=none means: do not change how you treat my mail, just tell me what you are seeing. rua is the address where the daily aggregate reports arrive. Google recommends making that a group or a dedicated mailbox rather than somebody's personal inbox, and after the first week of XML attachments you will understand the recommendation. Reports are normally sent once a day, by each receiver that saw your mail.

Two more tags are worth knowing before a consultant offers them to you. sp sets a separate policy for subdomains that exist, and np sets one for subdomains that do not exist at all, which is how you stop somebody inventing facturas.example.com and sending from it. When np is absent, the policy from sp applies, and when sp is absent too, the policy from p applies. Both are defined in RFC 9989, the current DMARC specification.

Read the reports before you harden anything

This is the step people skip, and it is the only step that makes the rest safe. Each aggregate report is an XML file from one receiver covering one day of your mail: which IP addresses sent it, how many messages, whether SPF and DKIM passed, and whether they aligned with your domain. You are not reading it for the numbers. You are reading it to build a list of everything on earth that sends mail as your domain.

For a small business that list is longer than the owner expects, and it is usually some version of this: Google Workspace or Microsoft 365 for the people, the invoicing or accounting system, the CRM, the online store, the newsletter tool, the website contact form, a scanner in the corner of the office that mails PDFs, and one service nobody remembers signing up for. Go through it and put every sender in one of three groups.

Aligned already. Nothing to do. Most of your Workspace or Microsoft 365 mail lands here.
Yours, and failing. The ones to fix, one at a time, usually by turning on the vendor's DKIM signing for your domain or setting a custom return path. This is the real work of a DMARC project.
Not yours. Somebody sending as your domain who should not be. This is the group that justifies the whole exercise, and the reason you will eventually want a policy that is not none.

Moving up to quarantine, then reject

Google's recommended rollout is to watch the reports for at least a week, confirm your own outgoing mail is authenticating, then move to quarantine so failing mail goes to the spam folder where a recipient can still find it, starting with a small share of messages and raising it over time to all of them, and only then move to reject.

One correction to older guides, including plenty still online. They tell you to run that ramp with a pct tag in the record. RFC 9989, published in May 2026, replaced RFC 7489 as the DMARC specification and removed pct from the record syntax; the appendix covering the change is titled "Removal of the 'pct' Tag". What the specification keeps for a cautious rollout is the t tag, a signal that you do not want your stated policy enforced yet, which changes nothing about reporting and has no effect while the policy is none. The practical reading for a small domain: do not build your plan around a percentage. Get every sender on your list aligned, sit at quarantine for a week when someone is around to notice complaints, then go to reject. The safety comes from the inventory, not from the fraction.

It also helps to know what the big receivers ask of you, because it is less than people assume. Gmail requires senders of more than 5,000 messages a day to Gmail accounts to have SPF, DKIM and DMARC in place, and says plainly that the DMARC enforcement policy can be set to none. The same guidelines ask for the From header to align with the SPF or DKIM domain, a spam rate kept under 0.30% in Postmaster Tools, valid forward and reverse DNS, and TLS on the connection. So p=none satisfies the requirement. You move up to reject to protect your own domain from being used against your customers, not to satisfy Gmail.

The mistakes we fix most often

Almost every broken DMARC setup we are handed is one of these six.

Two records on _dmarc. A leftover from an earlier attempt sitting beside the new one. DMARC expects exactly one policy record, and with two published you effectively have none.
A rua address nobody can read. A typo in the mailto, or reports landing in a mailbox no human opens. The domain then sits at p=none for two years, which protects nothing and tells nobody anything.
Strict alignment copied from a blog post. It sounds safer and it is the setting most likely to send your own subdomain mail to spam.
Jumping straight to p=reject. The record is easy to publish and the damage is invisible to you, because the bounces go to the systems that send on your behalf, not to your inbox.
Forgetting the subdomain the marketing tool sends from. A policy on the root domain does not fix an unaligned sender on a subdomain, and sp exists for exactly this.
Expecting DMARC to survive forwarding. When a message is forwarded, SPF commonly breaks, because the forwarding server is not on your list. DKIM survives forwarding far better, which is a good reason to make sure DKIM is signing before you enforce anything.

How Guanacos Tech helps

On a deliverability project, this is most of what the work actually is: name every system that sends as the domain, read enough reports to be sure the list is complete, fix alignment one sender at a time, and stay on the reports long enough to know the fix held before the policy moves up. Nothing about it is clever. It is just ordered, and the order is what keeps invoices arriving. If you want to do it yourself with the record above and a week of reports, that is a perfectly good outcome. If the reports came back with nine senders and two you cannot identify, that is what our email deliverability consulting for small business is for. Bring your domain and one failing message to a 30-minute call and you will leave knowing which senders are the problem and what clearing them takes.

Sources

Why 2FA did not stop this Google account takeover, and what would

Guanacos Tech — Fri, 25 Sep 2026 12:00:00 +0000

This month we investigated an account takeover for a client. Nobody clicked a strange attachment, no laptop was infected, and the victim was careful. Her Google account was still taken over, kept quietly for a week, and then used to send a malicious "invitation" to more than 1,400 of her contacts. We are sharing how it worked, with every name removed, because the same pattern is hitting small businesses everywhere and it is easy to stop once you have seen it.

How it started: a real person's hacked mailbox

The email came from a school principal our client had genuinely worked with a few weeks earlier. His account had been hacked, and the attackers used it to email everyone he had been in contact with, all in Bcc. The message was short: "has shared a file with you", a "Read document" button, and his real email signature.

Because it came from his real mailbox, it passed every technical check. SPF, DKIM and DMARC all confirmed it was genuinely his, and the spam filter had no reason to stop it. That is what makes this kind of phishing work: it arrives from someone you know, not from a stranger.

The fake sign-in page

The button did not go to a random website. It opened a page hosted on a legitimate Google service, so the first address looked like google.com. That page asked the reader to "verify your identity to view the document" and then sent them to a copy of Google's sign-in screen on the attackers' own domain.

This was not a crude copy. It was the real Google sign-in page, passed through the attackers' server in real time. Security teams call this an adversary-in-the-middle attack. Everything typed goes to the attacker first and then on to Google: the password, and then the phone check Google asks for. Within eight minutes of the click, the attackers were signed in to her account from a hosting server.

Why the phone check did not help

Google did ask for a second step. It was completed through the same fake page, because to the victim it looked like a normal part of signing in. Codes sent by SMS, codes from an app and "Is it you?" prompts can all be relayed like this. The page does not need to break anything. It just forwards what the person does.

What the attackers really wanted was the result: once Google accepts the sign-in, it gives the browser a session, the thing that keeps you signed in. The fake page kept that session for the attackers. From then on they did not need the password or the phone again.

There was one thing they could not relay. Their first move was to try to change her 2-Step Verification settings, most likely to add their own phone and lock her out. That step asked for her passkey, which only works on the real google.com, and it failed.

A week of silence, then the blast

Google flagged both actions as suspicious and sent a security alert that morning. The alert was opened, but the password was not changed and nobody signed out the other sessions, so the attackers stayed in. For seven days they did nothing visible.

Then, on a Monday, they used the stolen session from a different server to send a "special dinner party invitation" from her account to more than 1,400 contacts, in five messages. The link installed remote-control software on the computers of anyone who ran it. They also hid the bounce messages and replies so the victim would not notice. It stopped when she changed her password that afternoon.

The chain then closed on itself: some of those 1,400 recipients worked at the same school the first email came from. Each hacked mailbox becomes the trusted sender for the next round.

What would have stopped it

Two things would each have stopped this attack on their own. Everything else lowers the odds.

Passkeys or security keys for sign-in. They check that the site really is Google before they answer, so a relay page gets nothing. This is what the US cybersecurity agency CISA calls phishing-resistant MFA. Google Workspace can require it for everyone with the "Only security key" 2-Step Verification setting, which accepts both security keys and passkeys.
Acting on the alert the same day. After any Google security alert: change the password and sign out of every session (an admin can do it for the user). Changing the password alone was what finally ended this attack, a week too late.

If passkeys are not an option yet, these still help a lot:

Shorter sessions. In the Admin console, Google session control sets how long web sessions last before people must sign in again. A stolen session that expires in a day is far less useful than one that lasts weeks.
Alerts that reach an admin. Send suspicious sign-in and 2-Step Verification change alerts to the person who can act, not only to the user.
A password manager. It only fills your Google password on the real Google domain. When it refuses to fill, treat that as a warning, not a bug.
A team rule for shared files. If an email asks you to sign in to see a file, even from someone you know, check with them by phone or text first.
Look at the address bar before you sign in. Google's sign-in page is always on accounts.google.com.

If it already happened

Change the password, sign out all sessions, and check what the attacker may have changed: recovery email and phone, 2-Step Verification methods, mail forwarding and filters, and connected apps. Then pull the Gmail and sign-in logs in the Admin console to see what was sent and from where, warn your contacts, and report the fake page and its hosting provider. Your computer was probably not infected, but it is worth a check, because some of these campaigns end with remote-control software.

How Guanacos Tech helps

We investigate account takeovers in Google Workspace from the logs up: how they got in, what was touched, who received what, and whether any device was affected. Then we set up the controls above, including passkeys or security keys without locking anyone out, shorter sessions and admin alerts, and give your team a one-page guide they will actually read.

Sources

Before you set DMARC to p=reject: the third-party sender checklist

Guanacos Tech — Thu, 24 Sep 2026 12:00:00 +0000

Why p=reject fails silently for the senders you forgot

Say a 12-person accounting firm finishes what looks like a clean DMARC rollout. Mail from Google Workspace passes, the newsletter passes, two weeks of reports look tidy, and somebody flips the policy to p=reject on a Friday afternoon. On Monday a client calls to ask where the invoice went.

Nobody inside the firm saw a bounce. A rejected message is refused at the receiving server, and the refusal goes back to the envelope sender, which here is the billing platform, not a person at the firm. The mail stopped quietly, and the first signal was a customer who paid late.

That is the failure mode of enforcement. It does not break the senders you tested. It breaks the ones nobody wrote down: the invoicing tool, the scanner in the hallway, the booking system's reminders, the store's shipping notices, the helpdesk that replies as support@. Each puts your domain in the From line and signs with somebody else's, and until the policy had teeth, receivers let it through.

So the real work before p=reject is not DNS work. It is an inventory. Here is the checklist we run on a client domain, in the order we run it.

Build the sender inventory from the aggregate reports

Guessing gives you a list of the senders you already knew about. The aggregate reports give you the real one, including the tool a department signed up for last year without telling anyone.

Leave the policy at p=none with a rua address for at least two weeks, and a full month when the business has a monthly billing or payroll cycle. A sender that fires once a month will not appear in a two-week window, and that is usually the sender that hurts.

Then read the reports and write down, for every source: which vendor the IP belongs to, whether SPF passed and aligned, whether DKIM passed and aligned, and roughly how many messages. Alignment is the column that decides everything. RFC 9989, published in May 2026 as the standards-track replacement for RFC 7489, keeps the same rule at the centre: one of SPF or DKIM has to pass and match the domain in the visible From header. A vendor whose SPF passes on the vendor's own domain contributes nothing.

If reading raw XML is not how you want to spend the afternoon, paste a report in instead.

Sort every line into three buckets. Yours and aligned, which needs nothing. Yours and not aligned, which is the work. Not yours at all, a forwarder or somebody spoofing you, and neither should stop the rollout.

What to configure, category by category

Nearly every unaligned sender is fixed by one of three moves: get the vendor signing DKIM with your domain, move that mail onto a subdomain you delegate, or relay through your own mail platform instead. Which move applies is mostly a property of the category.

Marketing and newsletter platforms

These are the easiest, because every serious platform supports custom DKIM. Publish the CNAME records the vendor gives you, wait for them to resolve, then turn on signing.

One detail catches people out. Several platforms, Mailchimp and HubSpot among them, do not let you move the return path onto your own domain, so SPF keeps reading as a pass on their domain and a fail on alignment, permanently. That is fine: only one identifier has to align, and DKIM is the one you control. Do not paste the vendor's include: into SPF hoping to fix that column, because it cannot align and it spends one of your ten lookups. We went through each of these in why Mailchimp, HubSpot and Klaviyo fail DMARC alignment.

CRM and sales tools

Salesforce is the pattern here. Its documentation has you create a DKIM key in Setup, choosing an RSA key size, with 2048 bits recommended, and a selector that identifies the key. What matters for DMARC is signing with your From domain rather than a vendor default. Salesforce also documents an email relay option that routes outbound mail through your own server, Workspace or Microsoft 365 included, which solves SPF alignment too because the mail genuinely leaves your platform.

Sales tools that send from an individual's mailbox over an authorised connection usually align already, since the message really does leave Workspace or Exchange Online. Verify rather than assume.

Invoicing, accounting and the back office

This is the category that breaks quietly and costs money when it does. Invoices, statements, payroll notices and receipts go out monthly, so they are under-represented in a short reporting window, and the recipient is a customer who will not call to say the invoice never arrived.

Three outcomes are common. The tool supports custom DKIM, which is the clean answer. It lets you supply your own SMTP credentials, so you point it at your mail platform and it inherits your authentication. Or it offers neither and sends as you with no way to sign, and then the honest fix is to change the From address: onto a subdomain you delegate to that vendor, or onto the vendor's domain with your company in the display name and a reply-to that comes back to you.

Stores, booking systems and their email apps

Shopify is representative of the category. Its help centre has you add CNAME records at your DNS provider to authenticate the sending domain, and sets two conditions on the DMARC record itself: the domain must have only one DMARC TXT record, and it should not be on strict alignment, adkim=s or aspf=s. If the check does not pass, Shopify rewrites the visible sender to an address on its own domain, precisely the outcome you were trying to avoid. Those DNS changes can take up to 48 hours.

Helpdesk and shared inboxes

Helpdesks reply as support@ or hola@ from their own infrastructure, so they need the same DKIM treatment as a marketing platform. The sequence is what matters: add the external address, publish the DKIM records the vendor gives you, confirm they resolve, and only then enable signing in the vendor console. In the other order, the vendor signs with a key that does not resolve and mail that used to pass starts failing.

The office printer and the line-of-business app

The multifunction printer in the hallway scans to email. So does the alarm panel, the backup software, the point of sale, and whatever script somebody wrote in 2021. None appear on a vendor list, all use your domain, and several only send when something is wrong, the worst possible time for a message to be refused.

For Google Workspace tenants, Google documents sending from a printer, scanner or app through the SMTP relay service, which relays the message through Google so it carries your DKIM signature instead of nothing. Devices authenticate with credentials or by IP address, the practical option for a printer. Your SPF record needs Google authorised, which it almost certainly already is:

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

For Microsoft 365 tenants, the trap sits one step earlier. Microsoft's documentation is explicit that DKIM signing must be configured for your custom domain so the signing domain aligns with the From address. A tenant that never did this signs with its .onmicrosoft.com domain, and mail from Exchange Online then passes SPF, passes DKIM, and still fails DMARC. If your reports show Microsoft ranges failing alignment while everything looks configured, that is nearly always why.

Where a device cannot authenticate at all, give it a subdomain and leave the main domain clean. A scanner sending as scans@notify.example.com is a contained problem. The same scanner as scans@example.com is a reason not to enforce.

Two limits that bite during the inventory

Every vendor you add tempts you to paste another include: into SPF, and the record has a ceiling. RFC 7208 section 4.6.4 caps a single SPF evaluation at ten DNS-querying mechanisms, and going over produces a PermError, which fails SPF for every message regardless of origin. So the working rule through the inventory: DKIM is how you align a third party, SPF is for the handful of systems that genuinely relay your mail, and an include leaves the record the same week the vendor does. If you are already over the limit, getting back under ten lookups comes before any policy change.

A week at quarantine, then reject

Once every line is aligned or deliberately moved off the domain, tighten in two steps rather than one.

The percentage dial you may remember from older guides is gone. RFC 9989 removed the pct tag and put a plain testing flag in its place, t=y, which reports without enforcing. Records that still carry pct stay valid, but a staged percentage is no longer something to build a rollout on. Stage with the policy value itself.

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; adkim=r; aspf=r"

Quarantine turns a hard failure into a soft one. Anything you missed lands in a spam folder instead of vanishing, and the recipient can still find it and tell you. Watch the reports daily that week, and if the business has a billing run, schedule the week so the run falls inside it.

Then move to enforcement:

_dmarc.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=r; aspf=r"

Keep the rua address in the record permanently. The inventory is a snapshot, and somebody will buy a new tool in March. If subdomains are part of your plan, the sp tag decides what happens to them, and that has its own traps.

Worth knowing before you set a date: a domain sending more than 5,000 messages a day to Gmail already has to publish a DMARC policy, keep its spam complaint rate below 0.3 percent and support one-click unsubscribe on bulk mail, enforced by Google since February 2024. Reaching p=reject goes beyond that, and the inventory makes it safe rather than brave.

How Guanacos Tech helps

We run this as a defined piece of work for small and mid-sized companies in North America and Latin America, in English and Spanish: a month of aggregate reports, the sender inventory, alignment fixed vendor by vendor, a quarantine week, then the reports watched through the first weeks of enforcement so a missed sender turns into a phone call instead of a lost invoice. The surprise is rarely a spoofer. It is almost always a tool one department bought and nobody else knew about.

Start on your own if you like: the DMARC analyzer and the email troubleshooter are free and need no account. To hand it over instead, our email deliverability consulting for small business page explains how an engagement runs, and a 30-minute call is enough for us to read your record and name the senders standing between you and p=reject. Vendor documentation cited here checked 24 September 2026.

Sources

Why is my email going to spam? A 10-minute self-diagnosis before you pay anyone

Guanacos Tech — Thu, 24 Sep 2026 12:00:00 +0000

Say a 14-person insurance brokerage sends about 300 messages a day: renewal notices, policy documents, the occasional quote. Nothing changes on their side. Then a client says the renewal never arrived, and a week later another one finds it in the junk folder. Someone in the office starts copying their own Gmail on every message to test it, which proves nothing, because mail you send to yourself almost always lands.

That call reaches us most weeks, and it opens with the same sentence: our emails are going to spam. That one sentence covers at least three unrelated problems, and the repair for one does nothing for the other two. Before you pay anyone, us included, you can tell them apart in about ten minutes using free tools and one message that actually got filtered. This is the order we work in on a first call.

Three different problems that look identical from the outside

Filtering is a verdict, not a cause. The verdict comes from three independent inputs, and knowing which one is failing decides everything you do next.

Authentication. The receiving server cannot prove the message really came from your domain. This is a DNS problem. It is the cheapest to fix and the most common by a wide margin in small companies.
Reputation. Your records are correct, but the domain or the machine sending for you has a history: complaints, a spike in volume, a shared hosting IP carrying somebody else's traffic. No DNS edit clears this. Only time and better sending behaviour do.
Content and list hygiene. People are marking the mail as spam, the list has addresses that stopped existing years ago, or bulk mail has no working unsubscribe. This one hides behind the other two and outlives both.

Google's sender guidelines set the floor for all of them. Every sender is expected to set up SPF or DKIM, to have valid forward and reverse DNS records for the sending domain or IP, to transmit over TLS, and to keep the spam rate reported in Postmaster Tools below 0.30%. Senders who push more than 5,000 messages a day to Gmail accounts have to do all three, SPF and DKIM and DMARC, and support one-click unsubscribe on marketing and subscribed mail. Guidelines checked 24 September 2026.

Under 5,000 a day you are not exempt, you are just judged on fewer rules. The 0.30% spam-rate ceiling and the authentication requirement apply to everyone.

Minutes 1 to 3: look at what your domain publishes

Start in DNS, because it is the only part of this where a wrong answer is unambiguous. You are looking for three records. A healthy small-business set looks roughly like this:

example.com.                    TXT   "v=spf1 include:_spf.google.com ~all"
google._domainkey.example.com.  TXT   "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
_dmarc.example.com.             TXT   "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Four faults account for most of what we find at this stage.

Two SPF records. One was added for the website host, one for the mail platform, years apart. Two v=spf1 records on the same name is a permanent error and the receiver stops evaluating. There must be exactly one, with every sender inside it.
SPF over the lookup budget. RFC 7208 section 4.6.4 caps a single evaluation at ten DNS-querying mechanisms. Each include you added for a CRM, an invoicing tool and a newsletter platform spends part of that budget, and several expand into more includes internally. Past ten the record returns PermError and effectively stops protecting you.
No DKIM at all. In Google Workspace, DKIM is generated in the Admin console and then published as a record in DNS. Plenty of tenants complete the first half and never do the second, so nothing is ever signed.
No DMARC. Without it you have no reporting, which means no list of who sends as your domain, which is the list every later decision depends on.

Run your domain through the check below before reading any further. It takes a few seconds and it tells you whether the next six minutes are about authentication or about something else.

Minutes 4 to 6: read one message that was actually filtered

Records that look correct in DNS can still fail on a real message, and only the message tells you. Find one that landed in a recipient's spam folder, ideally at Gmail. Ask the recipient to open it, use the three-dot menu and choose Show original, then send you the whole thing as text. Google documents this path on its page about tracing a message with its full header.

In what comes back, find the line beginning Authentication-Results. It carries the receiver's own verdict:

Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of bounce@mail.crmvendor.com ...) smtp.mailfrom=mail.crmvendor.com;
       dkim=pass header.i=@crmvendor.com;
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=example.com

That example is the single most common finding in our audits, and it explains why so many people conclude that their records are fine. SPF passes. DKIM passes. DMARC still fails, because DMARC does not ask whether SPF or DKIM passed for somebody. It asks whether the domain in the visible From: header lines up with the domain that SPF or DKIM authenticated. Google's own DMARC setup documentation calls this alignment, and it is the step almost every third-party sending platform gets wrong until you configure it deliberately.

So read those lines in this order: dmarc= first, then header.from=, then whether smtp.mailfrom or the DKIM d= domain matches it. If you would rather not squint at raw headers, paste them into our header analyzer and it will name the failing part. If dmarc=pass and the mail still got filtered, authentication is not your problem and you can stop working on DNS entirely.

Minutes 7 to 9: Postmaster Tools, and what an empty dashboard means

Google Postmaster Tools is the only view Google gives you of how Gmail treats your domain. It is free and costs one verification record. Its dashboards report on outgoing mail to personal Gmail accounts, covering spam rate, authentication, delivery errors, compliance status and the feedback loop.

Two limits matter before you read anything into it. Mail delivered to a client's Google Workspace mailbox is not what these graphs measure, and nothing outside Google appears at all, so Outlook and corporate filters stay invisible here.

Then there is the result that confuses people most: no data. Google is explicit that most dashboards display data only when there is a sizable daily volume, up to the order of hundreds of messages, from your authentication domains, and that data may be withheld on low-volume days to protect user privacy. Some dashboards need your mail to be DKIM-signed before they show anything at all.

For the 14-person brokerage at 300 messages a day, split across Gmail, Outlook and corporate recipients, an empty dashboard is the expected result. It is not a verdict on your domain and it is not evidence of a penalty. If you are large enough to see numbers, the spam rate is the one to watch, held under the 0.30% ceiling and ideally far under it. Our guide to setting up Postmaster Tools walks through each dashboard.

If you already have DMARC reporting turned on, this is also the moment to open the last two weeks of aggregate reports in our DMARC report analyzer. Those XML files list every system sending as your domain, including the ones nobody remembered.

Minute 10: decide what this actually is

You now have three answers. Match them to one of these.

DNS shows a gap, and the header shows dmarc=fail. Authentication. This is a DNS job with a clear end state, and a competent admin can finish it in an afternoon. Publish one SPF record covering every sender, sign with DKIM, publish DMARC at p=none with a reporting address, then read reports for two weeks before tightening anything.
Everything passes, mail still lands in spam, and it has been getting worse for weeks. Reputation or content. Look at volume changes, at what you sent just before it started, and at how old the list is. Nothing in DNS will move this.
Messages are being rejected outright rather than filtered. Different problem, and the bounce text names it. Our post on telling Gmail 550 5.7.1 from 5.7.26 splits that one in a minute.

Two signs it is worth bringing in help rather than continuing alone. First, more than a handful of separate systems send as your domain: a CRM, an invoicing or e-invoicing platform, a help desk, a newsletter tool, an online store, the office scanner. Each one needs its own alignment work, the order matters, and SPF runs out of lookups long before you run out of senders. Second, DMARC is already at p=quarantine or p=reject and mail has started disappearing. That combination has a deadline attached, because every day at enforcement is a day of legitimate mail being discarded silently.

Three things not to do, all of which we have been called in to undo. Do not register a fresh domain to escape the problem, because a new domain has no reputation at all and the old one stays broken. Do not raise volume to prove the mail works. Do not buy a subscription to a dashboard that reports a deliverability score without telling you which record to change, because a score is not a diagnosis.

How Guanacos Tech helps

Most of what we do on a deliverability project is the unglamorous part of the list above: name every system that sends as the domain, fix alignment one sender at a time, keep SPF inside its lookup budget, and stay on the DMARC reports long enough to know the fix held before moving the policy up. If the ten minutes above told you this is authentication, you may well finish it yourself, and that is a fine outcome. If it told you there are nine senders and an SPF record that already errors out, our email deliverability consulting for small business is built for exactly that. Bring what you found, a bounced message and your domain, to a 30-minute call, and you will leave knowing which of the three problems you have and what clearing it will take.

Sources

Gmail error 550: is yours 5.7.1 (reputation) or 5.7.26 (authentication)?

Guanacos Tech — Wed, 23 Sep 2026 12:00:00 +0000

One number, three different problems

Say a nine-person design studio sends proposals from its own domain. On a Monday morning nothing reaches the clients who use Gmail, and the office manager forwards a returned message with 550 in it. That number on its own tells you very little. It means Gmail refused the message permanently and will not try again. The useful part is the enhanced status code that follows it, and the sentence attached to that code.

Three of those codes account for almost every Gmail rejection we get called about. 5.7.1 is a reputation verdict. 5.7.26 is an authentication verdict. 5.7.25 is a verdict about the machine that opened the connection, not about your domain. In a mail client they look like the same red box, and they lead to completely different work. So the first thing we do on any of these tickets is read the bounce properly, before anyone opens the DNS panel.

Read the bounce: the three lines that matter

Ask for the whole returned message, not a screenshot of the first line. In Gmail the full text sits behind the error details link on the bounce, or in Show original. In Outlook it is inside the delivery report. Three things decide everything that follows.

The enhanced status code. The digits right after 550: 5.7.1, 5.7.26 or 5.7.25. Gmail wraps long explanations, so you will usually see the code repeated at the start of every line as 550-5.7.26. The hyphen means the line continues, not that the code is different.
The sentence Gmail attached to it. Two rejections can share a code and still need different repairs. That is exactly the case with 5.7.26. Copy the sentence out word for word before anyone paraphrases it.
What the sentence names. A domain, an IP address, or both. "The sending domain" and "the sending IP address" point at different owners, and often at different companies.

A 5.7.26 bounce of the first kind reads close to this:

550-5.7.26 This mail is unauthenticated, which poses a security risk to
550-5.7.26 the sender and Gmail users, and has been blocked. The sender
550-5.7.26 must authenticate with at least one of SPF or DKIM.

A 5.7.1 reads close to this instead:

550-5.7.1 Gmail has detected that this message is likely suspicious
550-5.7.1 due to the very low reputation of the sending domain.

Same three digits at the front, two unrelated projects behind them.

5.7.1 is reputation, 5.7.26 is authentication, 5.7.25 is the sending host

5.7.26, authentication. Gmail could not tie the message to the domain in the visible From address. Either nothing passed, or something passed under a different domain than the one your recipients see. This is a configuration and DNS problem, and it is the fastest of the three to close.
5.7.1, reputation. Gmail did evaluate the message and did not like the sender's history. Read the wording carefully. "Very low reputation of the sending domain" is about your domain. "Very low reputation of the sending IP address" is about the machine or the shared pool you send through, which on cheap hosting is shared with strangers. Neither is fixed by editing a record.
5.7.25, the sending host's DNS. The public IP that connected has no usable reverse DNS. Google's sender guidelines require the sending IP to have a PTR record that resolves to a hostname, and that hostname to have an A or AAAA record resolving back to the same IP. Only the owner of the IP can publish that, and the owner of the IP is rarely you.

The two wordings that share the 5.7.26 code are worth separating now, because they send you to different places. The one quoted above, "must authenticate with at least one of SPF or DKIM", means nothing passed at all. The other one, "Unauthenticated email from example.com is not accepted due to domain's DMARC policy", means your own published policy told Gmail to reject the message, because the authentication that did pass was not aligned with the From domain. We see the second version most often in companies that moved to p=reject before the list of systems sending as their domain was finished.

If yours is 5.7.26: authenticate first, then align

Work in this order. Each step is checkable, which matters when several people are guessing at once.

Name the system that actually sent the message. Not "our email". The mail server, the CRM, the invoicing app, the website contact form, the scanner in the corridor. Every one of them authenticates on its own, and the one that broke is usually the one nobody remembers turning on.
Check what that system is allowed to send as. If it relays through your mail provider with a real mailbox and a password, it is usually covered already. If it connects to Gmail from its own servers, it needs either an SPF include that names those servers or its own DKIM key published on your domain.
Get alignment, not just a pass. For messages sent straight to personal Gmail accounts, Google asks that the organizational domain in the From header match either the SPF domain or the DKIM domain. One of the two is enough. A vendor that signs with its own domain and passes SPF on its own return path can still produce 5.7.26 on your From address, and its support desk will tell you authentication is fine, because from where they sit it is.
Send one real message and read the headers. A lookup tool tells you what your record says today. The headers of a message Gmail accepted tell you what Gmail did with it. That is the check that closes the ticket.

The full walk-through, including the DMARC policy wording, is in our 5.7.26 guide. One warning before you add an include: SPF is capped at ten DNS lookups by RFC 7208, and one more vendor can tip a long record into a PermError, which fails authentication for every message at once. Count the lookups first.

If yours is 5.7.1: reputation, and no record edit will clear it

This is the slower one. People lose weeks treating it as a DNS problem, publishing a new record every day and watching nothing change. Reputation is a running average of how Gmail users react to your mail, so it moves on Gmail's schedule.

Decide whether it is the domain or the IP. The bounce says which. If it names the IP and you send through shared hosting, you are carrying someone else's behaviour, and the real fix is to stop sending from that pool.
Verify the domain in Postmaster Tools and read it. The dashboards show domain and IP reputation along with authentication and delivery error rates for the domain you verified. It is the only view of what Gmail thinks that is not guesswork. Our setup guide covers what each dashboard is worth.
Get authentication perfect anyway. Reputation recovery on a domain that still fails SPF or DKIM does not start. Authentication is the floor, not the fix.
Stop whatever caused it. A volume jump, a bought list, a form with no confirmation step, a compromised mailbox sending overnight. Google tells senders to keep the spam rate reported in Postmaster Tools below 0.1 percent and never to reach 0.30 percent, guidance we checked on 23 September 2026. Complaints at that level do not average away quickly.
Then rebuild slowly. Small volumes to people who reply, held steady for weeks. There is no button, and anyone offering one is selling something.

The 5.7.1 guide has the order we follow on a live reputation case, including what to do when the IP is not yours.

If yours is 5.7.25: someone else owns the fix

Reverse DNS is published by whoever owns the IP address, so a registrar panel is the wrong place to look. If you send through Google Workspace, Microsoft 365 or a normal email platform, their addresses already have PTR records, and a 5.7.25 usually means something else is relaying: an old office server, a VPS running a website's contact form, an appliance with an SMTP setting from a previous decade. Find the IP in the bounce, work out who runs it, and ask them to set a PTR that resolves to a hostname whose A or AAAA record points back to the same address. On a VPS that is a support ticket. On a box under a desk it is often a reason to stop sending directly and relay through the mail provider instead.

What to do while the fix propagates

The hours after the change are where good work gets undone.

Do not release the stuck queue in bulk. A few hundred retries against a provider that just rejected you reads as exactly what it looks like.
Let the record's TTL pass before testing. If the TTL was four hours, the answer you get in five minutes is the old one.
Test with one message to a Gmail address you control, then read its headers. Delivery to your own inbox is not proof on its own.
Call the people waiting on something urgent. A short phone call beats a proposal sitting in a queue.
Do not register a new domain to escape the problem. A fresh domain has no reputation at all, a look-alike domain attracts more suspicion, and both leave the original broken.

How Guanacos Tech helps

Most of these cases arrive as one sentence: our email is bouncing. An hour later it is usually three separate things, one of which has been quietly failing for months. We read the bounce, name every system that sends as the domain, fix authentication one sender at a time, verify with real messages rather than lookup tools, and stay on the DMARC reports long enough to know it held. If you have a bounce in hand, our email deliverability consulting for small business starts there. Bring the returned message to a 30-minute call and you will leave knowing which of these three problems you have and what clearing it will take.

Sources

Migrating from Microsoft 365 to Google Workspace: the checklist we run, in order

Guanacos Tech — Wed, 23 Sep 2026 12:00:00 +0000

The week after the move is where it shows

Say a 22-person distributor has been on Microsoft 365 since whoever set it up left the company. Deciding to move to Google Workspace takes an afternoon. The move itself usually goes fine, for about a week. Then the calls start: the accounting address nobody can open any more, and the delivery notes from the warehouse software that now land in spam, because nobody counted it as a sender.

None of this is hard work. It goes wrong because the steps get done in the wrong order. Mail gets copied before identity is settled, or the MX record gets switched before anyone lists who else sends mail as the domain. Below is the order we run on a migration for a small or mid-sized company, and what we check at each step.

Step 1: decide what moves, and what stays behind

Before any tool gets opened, we build four lists with the client on one page.

Mailboxes, split three ways: real people, shared addresses several people open, and addresses that only send (alerts, invoices, form notifications).
Calendars and rooms, including who books on behalf of whom.
Files, separated into personal OneDrive content and the SharePoint sites the team actually uses. There is always a site nobody has touched in three years.
Groups and aliases: distribution lists, the address that forwards to two people, the one that forwards to someone who left.

Then the shorter and more useful list: what does not move. Archived mail sitting under a retention policy, a mailbox tied to a line of business application nobody will touch this quarter, chat history. Google publishes a migration product matrix that says which of its tools handles which source and which type of data, and the answer differs for mail, for files and for an older on-premises Exchange server. We read it while planning.

Step 2: identity first, before DNS

Every Workspace account gets created before anything touches the domain's records. Google's own guidance on changing MX records puts this first: the hour mail starts arriving at Google, any address without an account behind it has nowhere to go.

Three details save the most trouble here.

Match the addresses exactly. The data migration service maps users between the two accounts by looking for similar addresses. Every address that does not match becomes a manual mapping, and eventually a mailbox somebody forgot.
Decide what each shared mailbox becomes. Google has two shapes for this and they behave differently. A Google Group set up as a Collaborative Inbox lets a team receive at one address and assign conversations to each other. A delegated account is one mailbox that other people open from inside their own Gmail, and on a work account it can carry a large number of delegates. Support and sales queues usually want the group. An address with years of history that one person mostly answers usually wants delegation.
Sort out administrative access early. Connecting the two tenants needs a super administrator on the Workspace side and a Global Administrator on the Microsoft 365 side. On small teams that second account is often held by whoever set things up years ago, and getting it back takes longer than the migration does.

Step 3: mail, the overlap, and the MX hour

Lower the TTL on the MX record at least a day ahead. Google recommends 3600, one hour, short enough that a mistake at the cutover costs an hour instead of a day. The old TTL governs how fast the change you make now takes effect, so the drop goes first.

Copy the data before the switch, not after. The data migration service copies Exchange Online mail and calendar into Workspace accounts, up to 250 users at a time, so a larger company runs it in batches. People keep working in Microsoft 365 while it runs.

During the overlap, two arrangements are worth telling apart. Dual delivery leaves the MX record pointing at the old system, which delivers to its own inboxes and then forwards everything on to Google. Split delivery points the MX record at Google, and Gmail routes named recipients on to the other system. Google recommends Gmail as the primary server, with the legacy server as primary only during a pilot or migration, and switching to Gmail alone once everyone is ready.

The cutover itself is one record. The Workspace value is a single host, and some registrars expect the priority and the destination in the same field:

example.com.   3600   IN   MX   1 smtp.google.com.

If the domain was set up on Workspace before 2023 it may still carry the older aspmx values, and Google's position is that records which are working do not need changing. Schedule the switch for an evening or a weekend, when a lost hour costs least. Google says new MX records can take up to 72 hours to be recognized and allows up to 48 hours for propagation, so nobody should judge it on the first ten minutes. Once it settles, run a delta pass to collect the mail that reached the old system during the change.

Step 4: authentication while both systems still send

This is the step that gets skipped, and the one that produces the spam complaints two weeks later. While both platforms send as the domain, both have to be authorized, and the moment one stops sending, it comes back out.

SPF is one record, one v=spf1 string, with both includes inside it:

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

Google publishes its sending ranges behind _spf.google.com and Microsoft publishes its own behind spf.protection.outlook.com, because both send from addresses that change. Two includes plus a CRM plus an invoicing platform is where domains cross the limit: SPF evaluation stops at ten DNS lookups and returns permerror, which RFC 7208 requires, and a permerror is not a pass. Count them before the cutover.

DKIM needs work on the Google side, because it is not signing by default. The key is generated in the Admin console under the Gmail settings, published as a TXT record at the DNS provider, and then authentication is turned on. Two timing details matter. After Gmail is switched on for the organization, the key cannot be generated for 24 to 72 hours. Once the record is published, authentication can take up to 48 hours to start working. Put both in the calendar rather than discovering them on cutover morning. Leave the Microsoft DKIM records in place while Microsoft still sends: the two use different selectors and do not collide.

Leave DMARC at p=none while the list of senders is still moving, and read the reports. Tightening the policy in the same week as the cutover means the one system you forgot starts failing at exactly the moment nobody can tell which change caused it.

Two rule sets apply to whatever you end up with. Since February 2024, Google asks every sender, at any volume, for SPF or DKIM and valid forward and reverse DNS, and asks senders of more than 5,000 messages a day to Gmail accounts for SPF and DKIM together, a DMARC record, alignment with the From header, and a spam rate under 0.30% in Postmaster Tools. Microsoft publishes its own requirements for high volume senders to its consumer services, also drawn at 5,000 messages a day from the same From domain, with SPF, DKIM and DMARC at p=none or stronger, and says non compliant mail is routed to Junk first. Most companies this size sit far below those thresholds. The first tier still applies.

Step 5: calendar, delegations and rooms

Calendar data travels with mail in the same migration run. What does not travel is the wiring around it. Delegation rights, the assistant who books for two directors, room resources and their booking rules: these get rebuilt in Workspace, and rebuilding them deliberately beats recreating an arrangement that grew by accident over six years. We schedule that for the day after the mail cutover, with the people who actually use it.

Invitations sent from the old system before the switch can behave oddly afterwards, usually the long-running recurring meetings. For a standing client call, cancelling and reissuing from Workspace beats debugging it.

Step 6: files, with the shape decided first

The data migration service copies OneDrive content into users' My Drive, and SharePoint Online sites into Drive. Google Workspace Migrate covers heavier cases and other sources, the second reason to read the product matrix early.

The decision that matters is not which tool you use, it is whether a folder belongs to a person or to the company. Content that lands in an individual's My Drive leaves with that individual. Content that belongs to the business belongs in a shared drive. Deciding that before the copy costs one meeting. Deciding it afterwards costs a second migration. Permissions and links do not survive a copy unchanged either, and external shares deserve a review pass, because a migration is the one moment when everyone is willing to look.

Step 7: retire Microsoft 365 without breaking your sending

Do not cancel the licenses in the same week. Keep them long enough to prove that nothing still depends on them, then work backwards.

Find every system that sends as the domain: the accounting software, the CRM, the website contact form, the office printer, the alerting on a server somebody still runs.
Move each one onto Workspace or onto its own authenticated path, one at a time, and confirm each with a real message rather than a lookup tool.
Remove the Microsoft include from SPF only when nothing sends through Microsoft any more. The same goes for its DKIM records.
Read the DMARC aggregate reports for at least two weeks after the last sender moves. They are the only place where a forgotten sender announces itself before a customer does.
Export whatever has to be kept for legal or accounting reasons before the old tenant closes, and write down where it went.
Then, and only then, tighten the DMARC policy.

How Guanacos Tech helps

We run this as one project with a written order of operations, because the expensive failures here are sequencing failures rather than technical ones. That means the inventory first, identity next, a cutover scheduled for an hour your business can afford to lose, authentication held open while both platforms still send, and the reports watched afterwards until the domain is clean. If you are weighing the move, our Google Workspace migration services page has the scope we work to. Bring your mailbox count and the list of things that send mail on your behalf to a 30-minute call, and you will leave with the order, the risks and the week it should happen.

Sources

Free DMARC report analyzer: upload the XML and know who sends as your domain

Guanacos Tech — Tue, 22 Sep 2026 12:00:00 +0000

The DMARC record went in a month ago. The rua address pointed at a real mailbox, and that mailbox now holds forty compressed files. Each one contains a page of XML. Nobody has opened the second one.

That is the state we find most small companies in, and it is not laziness. The reporting works. The reading never starts, because the format was written for machines. Say a twelve person accounting firm: invoices leave from the accounting package, campaigns from a marketing tool, and everyday mail from Google Workspace. The reports know about all three senders. The team does not.

You do not have to learn the XML to get the answer out. This is the short path we run on a client domain: what the file actually holds, how to turn one into a readable list in about a minute, the three verdicts that come out of that list, and what each one costs if you leave it alone.

What is actually inside the file

An aggregate report is a count, not a copy. The receiver groups every message it saw claiming your domain by sending IP address and by authentication outcome, then sends you the totals for the period. No subject lines, no recipients, no message bodies.

The format has its own specification. RFC 9990, published in May 2026 on the standards track, covers aggregate reporting; together with RFC 9989 and RFC 9991 it replaced RFC 7489, which had been the reference since 2015. Under RFC 9990 each record carries a row element with the connecting source_ip, a count of messages, and a policy_evaluated block holding the disposition and the DKIM and SPF results, alongside identifiers and auth_results.

Reports arrive because your published record asked for them:

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

Google Workspace Admin Help puts the cadence plainly: reports are usually sent once a day, by email, to the addresses in the record, and every mail server that receives mail from your domain sends one. That is why the mailbox fills. A domain with real volume collects reports from providers it has never heard of. Point rua at a group, not at a person who might leave.

If you want the XML decoded element by element, we wrote that separately: how to read a DMARC aggregate report. For the decision you are trying to make today, you can skip it.

Turn one report into a readable list

Take the newest attachment from the receiver you send the most mail to. It will be an .xml, .xml.gz or .zip file. Upload or paste it, and read the list that comes back instead of the markup.

Our DMARC report analyzer is free and needs no signup. It decompresses and parses the file in your browser, in memory, and shows the policy you actually published, the total volume in the report, your DMARC pass rate, every sending source ranked by volume, and, the part that matters most, which legitimate looking senders are not aligned and would be quarantined or rejected the moment you enforce.

The three columns that decide everything

Whatever tool you use, you are reading three things per row.

Source. The IP address that connected, and usually a recognisable owner behind it: your mail provider, a marketing platform, a web host, something you cannot place.
SPF alignment. Not just whether SPF passed, but whether the domain it passed for lines up with the domain in your From header.
DKIM alignment. The same question asked of the signature on the message.

The gap between passed and aligned is where most people lose an afternoon. RFC 9989 defines two modes: relaxed alignment means the two domains share an organizational domain, strict means they are identical. The adkim and aspf tags both default to relaxed, so unless you set them you get the forgiving version and it is still not automatic.

DMARC passes when at least one of SPF or DKIM passes and is aligned. Google's sender guidelines make the same point for bulk mail into Gmail: set up both SPF and DKIM, but only one of them has to align for the message to meet the requirement. A row showing SPF pass with no alignment is a failing row.

The three verdicts, and what each one costs

Aligned and passing

Your own provider, usually the largest block of volume. Nothing to do. Note the volume so you know what normal looks like next month.

Legitimate, but not aligned

This is the work, and it is almost always the same cast: the invoicing system, the CRM, the helpdesk, the newsletter tool, the online store, the office printer that emails scans. They send as your domain with their own authentication, which passes for their domain and not for yours.

The fix is per sender and lives in the vendor dashboard, not in a single DNS edit. Most platforms offer a custom return path or a set of DKIM CNAME records to publish; some are better handled on a dedicated subdomain so their reputation stays separate from your everyday mail. Each one you leave unaligned is a category of mail that stops arriving the day you enforce. That is the real cost of not reading the reports.

Unauthenticated and nothing to do with you

Scattered IPs, small counts, no authentication that lines up with anything you own. Some of it is spoofing, some is stale noise from lists and scrapers. You cannot fix this in DNS, because there is nothing of yours to fix. Enforcement is what stops it, which is the point of the whole exercise.

The rows that will fool you once

Forwarding is the usual false alarm. When a message goes through an alias or a mailing list, the forwarding server connects from its own IP, so SPF breaks, while the DKIM signature often survives intact. The row looks alarming and is a forwarder doing its job. If DKIM still aligns, DMARC still passes.

One report is one receiver's view of one day, not your traffic. A hundred percent pass rate on a quiet Sunday tells you nothing. And low count rows from unfamiliar IP addresses are worth a look but rarely worth a panic; volume is the signal.

From one file to a sender inventory

The deliverable from this exercise is not a clean report. It is a list you can act on, and it takes a week or two of reports rather than one.

Collect reports for at least a week so quiet days and monthly billing runs both show up.
Write down every source with volume, and mark whether SPF aligns, DKIM aligns, or neither does.
Sort into three buckets: keep as is, fix alignment, and not ours.
Give every sender in the fix bucket an owner and a due date. Someone has to log into that vendor dashboard.

That list is the thing we build first on every deliverability engagement, because you cannot safely tighten a policy you have not inventoried.

When to move the policy

Stay at p=none until every legitimate sender in the inventory aligns on SPF or DKIM. Then move to quarantine, watch a full week of reports, and only then reject. We walk through the ordering and the percentage rollout in moving DMARC from p=none to p=reject.

Worth knowing if you send in volume: since 1 February 2024, senders of more than 5,000 messages a day to Gmail accounts must have SPF, DKIM and a DMARC record in place, and must keep the spam rate reported in Postmaster Tools below 0.3%. The DMARC policy itself may stay at none to meet that bar, so reading your reports is not about passing an audit. It is about knowing what breaks before you decide to tighten.

How Guanacos Tech helps

We do this on client domains most weeks: collect a fortnight of reports, build the sender inventory, align the senders worth keeping, and move the policy in stages while watching what changes. If you have a mailbox of XML you have not opened, or you have read them and want a second pair of eyes before you enforce, that is what our email deliverability consulting for small business covers. A short call is enough to tell you whether your inventory is clean or whether something would break on the day you turn enforcement on.

Sources

What a Google Workspace consultant actually does for a 10 to 50 person company

Guanacos Tech — Tue, 22 Sep 2026 12:00:00 +0000

A thirty-person company rarely has an IT department. It has an office manager who created the email accounts three years ago, a developer who knows the DNS password, and a founder who is the only super admin and cannot remember the recovery phone number on the account. It holds together until someone resigns, a laptop is stolen, or Gmail starts bouncing the invoices.

That is usually when the call comes. Below is what the work actually is, in the order we do it, so you can tell a real proposal from a vague one and decide which parts your own team should keep.

The five situations that make a company call

Nearly every Google Workspace engagement we run starts in one of five places.

A migration. Mail is moving from Microsoft 365, an old Exchange server, cPanel or Zoho, and nobody wants to be the person who loses a message on cutover day.
A security scare. Someone clicked something, a mailbox started sending invoices to a client list, or an insurer asked for proof that two-factor authentication is enforced.
An offboarding mess. A person left four months ago and still owns half the shared files, or their account was deleted in a hurry and now the accountant needs a message that was in it.
Licensing waste. The bill grew past what headcount justifies and nobody knows which seats belong to people who left.
Nobody owns the admin console. This is the quiet one. Settings sit at their defaults, or at whatever a contractor chose in 2021, and there is no second super admin if the first one is unreachable.

The first four are projects with an end date. The fifth is usually the reason the other four happened, and it is the one worth solving properly.

What the first audit covers, item by item

The audit is a read, not a change. We ask for a delegated admin account, or we sit with whoever has one, and we go through the same list every time. Google publishes a security checklist written specifically for organizations of one to a hundred users, and it is the honest backbone of this part: administrator accounts, user accounts, apps, Calendar, Chat, Chrome, devices, Drive, Gmail, Groups, Sites and Vault. Many of the settings it recommends are already on by default, which is good news. The findings are almost always in the handful that are not.

These are the items that produce findings, in reading order:

Super admins. How many exist, whether each one is a real identifiable person, and whether each has 2-Step Verification. Google's own guidance is blunt here: super admin accounts control access to all business and employee data in the organization, so they should use 2-Step Verification, security keys are the strongest form of it, and whoever holds one should sign in to it only for admin work and use a separate ordinary account the rest of the time. There should also be more than one. A company with a single super admin can be locked out of its own email by one lost phone, and only a super admin can generate backup verification codes for another admin, which is exactly the help you need on the day it happens.
Recovery information. Recovery phone numbers and addresses that belong to people who no longer work there.
Organizational units and groups. Whether access is granted to groups or to individuals one at a time. Access granted name by name is what turns an offboarding into a week of work.
Drive sharing. How much is shared with anyone who has the link, and whether critical files live in shared drives the company owns or in somebody's personal My Drive.
Third-party app access. This is the finding that surprises people most. Under Security, then Access and data control, then API controls, the console lists the apps that have been configured with an access setting and the apps your users have actually connected to their accounts. Each one can be set to trusted, limited to unrestricted services, restricted to specific data, or blocked outright, and an unconfigured third-party app is blocked by default, with the user's request landing in a list for an admin to allow or block. The details of a newly authorized app can take a day or two to appear, so a tool connected this morning will not show up this afternoon.
Devices. Whether the phones carrying company mail are enrolled at all, and whether a remote wipe is actually possible.
Licences. Which seats are assigned, which are suspended and still being paid for, and which plan the subscription sits on.
Mail authentication. SPF, DKIM and DMARC for the domain, and every outside system that sends as it: the invoicing platform, the CRM, the online store, the helpdesk, the scanner in the corner that emails PDFs.

That last item is where a Workspace audit and a deliverability audit meet, and it is the one a business feels first, because it puts invoices in the spam folder. You can run that part on your own domain right now.

What we fix, and what we hand back

A consultant worth hiring is trying to become unnecessary for the routine work. The split we aim for: we take what needs judgement and a one-time hand, your people keep what has to happen every week.

What we take on: the migration and the cutover, the super admin structure and the delegation of admin roles so that not everyone who needs to reset a password needs full control, groups and organizational units rebuilt so access follows a role instead of a name, sharing defaults, the third-party app review, device enrollment, and the full SPF, DKIM and DMARC setup including the outside senders nobody listed. Anything that needs a rollback plan attached to it.

What we hand back, with a written procedure short enough that someone will actually use it: creating and offboarding a person, adding someone to a group, approving or blocking a new app request, reading the monthly DMARC summary, and a quarterly licence check. If a consultant wants to keep those five in their own hands, ask why.

Offboarding, the part most companies get wrong

Offboarding deserves its own section, because the expensive mistakes are made in the first ten minutes by someone in a hurry.

The order matters. For a departing employee, Google's guidance is to reset the person's sign-in cookies so open sessions stop working, revoke their security keys, and wipe company data from their mobile devices, and to treat the transfer of what they own, Drive files and calendar events, as its own deliberate step before anything is removed.

The costly mistake is deleting the account the same day. A deleted user can be restored, but only within twenty days, and the Drive files that user owned are held for that same window and are reachable only if you restore the account first. After that the recovery conversation is over. Suspending blocks the person's access while leaving every file and message in place, which is why it is the right first move for almost every departure. If the mailbox has to be kept for accounting or legal reasons, an archived user licence keeps that data available in Vault without holding an active seat.

The pattern we install is boring on purpose: suspend on the last day, transfer ownership within the week, keep or archive by a rule the company agreed in advance rather than in the moment, delete only when that rule says to.

What it should cost next to your licences

The honest answer to what this should cost is a ratio, not a number. Judge a proposal against what you already pay for licences: an audit with a fix list is a small multiple of one month of your subscription, and a migration with a real cutover is more, but it is a one-time cost against a bill you pay every month for years. The thing to push back on is not the rate, it is an open-ended hourly engagement with no defined finish.

Licensing is also where the work often pays for itself, and what you can recover depends on your plan. On the Flexible Plan you are billed for the accounts you have that month, so deleting a user lowers the licence count and the payment right away. On the Annual Plan you committed to a seat count for the term, and you can reduce it only at renewal, by setting the subscription to auto-renew with fewer licences before the term ends. Companies that learn this in month two of a twelve-month term pay for the lesson. Our own terms and how we scope an engagement are on how we work.

How to check that a consultant is independent and certified

Three questions separate a practitioner from a slide deck.

Ask what they are certified in and when they passed. Google Cloud runs a proctored certification for Workspace administrators, and the preparation it recommends is roughly six months of hands-on super admin experience rather than a weekend of reading. The badge also expires and has to be earned again, so a claim of being certified without a date attached is worth less than it sounds.

Ask whether they resell your licences. A reseller earns a margin on the subscription. An independent consultant does not, which makes it easier to be told to drop a tier when dropping a tier is the right answer. Neither model is disqualifying, but you should know which one is sitting across from you. Google lists partner companies in its public partner directory, and it is worth understanding that a certification belongs to a person while partner status belongs to a company. They answer different questions, and a small independent team can be strong on the first without the second.

Ask what happens when they are finished. The answer should include documentation you own, admin access that stays with you rather than with them, and a named person on your side who was taught the weekly tasks.

How Guanacos Tech helps

We are an independent consultancy with Google-certified engineers, working in English and Spanish with companies of roughly ten to fifty people across North America and Latin America, since 2018 and across more than eighty projects. A Workspace engagement with us usually starts with the audit above, delivered as a findings list ranked by what each item would cost you if it went wrong, then the fixes in that order, then a handover short enough that your own team can run the weekly work. Our Google Workspace consultants page describes how the engagement runs, and a first call is thirty minutes to look at your admin console together and work out which of the five situations you are in.

Sources

DMARC for Office 365: the record, the policy ramp, and the reports nobody reads

Guanacos Tech — Mon, 21 Sep 2026 12:00:00 +0000

Say a 25-person freight broker runs on Microsoft 365. Mail works, nobody thinks about it. Then a customer forwards an invoice the company never sent, with the company's own domain in the From line, and in the same week accounting notices that their real invoices are landing in Gmail spam. Two symptoms, one gap. The domain publishes SPF and DKIM, so mail leaving the tenant looks correct, but nothing tells a receiving server what to do with the mail that fails those checks.

That instruction is DMARC, and it is the one record Microsoft does not create for you. SPF and DKIM are set up inside the admin center. DMARC is a TXT record you publish in your own DNS, and it is the only part of the three that both protects the domain from forgery and tells you who is sending as you.

Here is the order we work in on a Microsoft 365 tenant: the record we publish on day one, what the reports show, how we raise the policy, and the traps that belong to Exchange Online.

What DMARC adds on top of the SPF and DKIM Microsoft gives you

SPF answers one question: did this message come from a server the domain authorized? DKIM answers a different one: was this message signed with a key the domain published, and did it arrive unaltered? Both can pass while the message still lies about who sent it, because both check a domain the reader never sees.

SPF checks the envelope sender, the address in the SMTP MAIL FROM command. DKIM checks the domain in the d= tag of the signature. The address your recipient actually reads is the From header, and nothing so far has compared the two.

DMARC is that comparison. It requires the domain in the visible From header to match the domain that passed SPF, or the domain that signed with DKIM. One of the two is enough. That match is called alignment, and DMARC's default is relaxed alignment, which accepts a subdomain of the same organizational domain. You can tighten it with aspf=s and adkim=s, and on a small tenant with third-party senders you usually should not.

Once that comparison exists, two things follow. You can tell receivers to quarantine or reject the mail that fails it, and you can ask for reports listing every source sending mail as your domain. The reports are the part people skip, and the part that makes the policy safe to raise.

There is a floor to this now. Since 1 February 2024 Google has required senders of more than 5,000 messages a day to Gmail to publish a DMARC record, and p=none satisfies that rule. Microsoft applied a comparable requirement to Outlook.com, Hotmail.com and Live.com, announced 30 April 2025 and phased in from 5 May 2025, starting with junk routing and moving to rejection with 550 5.7.515. Both rules ask for the record, not for enforcement. Enforcement is your decision, not theirs.

The exact TXT record at _dmarc, tag by tag

This is the day one record for a domain that has never had DMARC:

Host:  _dmarc
Type:  TXT
TTL:   1 hour
Value: v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1

Reading left to right:

v=DMARC1 is mandatory and has to come first, or the record is ignored.
p= is the policy for the domain itself: none, quarantine or reject. It is an instruction to receiving servers, not a switch inside your tenant.
rua= is where aggregate reports are sent. This tag is what the record is worth on day one. Point it at a shared mailbox or a group that a person opens, not at an individual who might leave.
ruf= requests per-message failure reports. Many large receivers never send them, and those that do may include message content, so treat that mailbox as sensitive or leave the tag out.
sp= sets a separate policy for subdomains. Leave it out and subdomains inherit whatever p= says, which is usually what you want once the root is at reject.
pct= applies the policy to a sample of failing mail. It only means anything at quarantine or reject, which makes it a ramp, not a setting you leave behind.
fo=1 asks for a failure report whenever either check fails to align, rather than only when both do.

Two details catch people inside a DNS panel. The host is _dmarc, not the bare domain, and some panels want _dmarc.example.com spelled out while others append the domain for you. And the whole thing is one TXT record. A second DMARC record on the same host is not additive: receivers that find two treat the domain as having no usable policy at all.

Publishing this changes nothing about delivery. It starts the flow of evidence that every later decision depends on.

What the reports show for a Microsoft 365 tenant

Aggregate reports arrive as gzipped XML, one file per receiving provider per day, usually within 48 hours of publishing the record. Each groups messages by sending IP and says whether SPF and DKIM passed and whether each aligned to your From domain. Give it two weeks, because the monthly senders are the ones that break policy changes.

On a typical M365 tenant, four groups show up:

Exchange Online itself. Normal user mail. If SPF includes spf.protection.outlook.com and DKIM signs with your custom domain, these rows pass aligned. If DKIM is still signing with the tenant's onmicrosoft.com domain, SPF carries the alignment alone, which holds until a message is forwarded.
Third-party senders. The CRM, the invoicing or e-invoicing platform, the helpdesk, the marketing tool, the e-commerce store. These are the rows that decide your timeline. Each one needs its own authentication set up at the vendor end before the policy can move.
On-premises relays and devices. An old Exchange server in a hybrid setup, a multifunction printer, a line-of-business application sending scans and statements.
Forwarders and genuine forgery. A mailing list or an auto-forward will break SPF on perfectly legitimate mail. Everything left after you have accounted for the rest is somebody else using your domain, and it is the reason to keep going.

Read the first file yourself rather than trusting a summary. If the XML is unfamiliar, paste one in here and look at the source rows.

Moving to quarantine, then reject

We do not move the policy on a calendar. We move it when the sender inventory from the reports is complete and every entry in it is either aligned or deliberately retired. The sequence we run:

Confirm the tenant's own mail first. SPF contains the Microsoft include and stays under the 10-lookup limit. DKIM is enabled for the custom domain in the Defender portal, with both selector1._domainkey and selector2._domainkey CNAMEs published, so Microsoft can rotate keys without an outage.
Fix third-party senders one at a time. Each vendor has its own path: a custom return-path or sending subdomain, DKIM CNAMEs, or a delegated subdomain that carries its own SPF. Fix one, wait for it to appear as aligned in the next report, then move to the next. Doing four at once means you cannot tell which change worked.
Deal with the relays. A printer or an application that cannot authenticate does not keep sending as the main domain. Move it to authenticated SMTP submission, a connector with an IP restriction, or a subdomain of its own.
Go to p=quarantine for a week. Failures land in junk instead of the inbox, which is recoverable. Watch the reports and, more importantly, ask the people who send the odd unusual message whether anything bounced.
Go to p=reject. If you want a ramp, pct=25 then pct=50 buys you a slower failure. If the inventory is genuinely complete, the ramp mostly buys time.

Keep the rua tag forever. A policy at reject with nobody reading reports is a configuration that will silently break the first time marketing signs up for a new tool.

The Microsoft traps that are not in the generic guides

The onmicrosoft.com domain. Every tenant has one, and attackers can use it. Microsoft's documentation is explicit that SPF and DKIM are already configured for the *.onmicrosoft.com domain but the DMARC record is not, and that you create it in the Microsoft 365 admin center rather than in public DNS. It is easy to lock the custom domain and leave this one open.

Domains you own and never send from. Microsoft recommends publishing a DMARC record on parked domains that says no mail should ever come from them, in the form v=DMARC1; p=reject; rua=mailto:d@rua.contoso.com; ruf=mailto:d@ruf.contoso.com. The old defensive domain registration from three years ago is a free spoofing channel until you do.

Direct Send. Exchange Online accepts unauthenticated mail on port 25 addressed to your own tenant's mailboxes, which is how printers and scanners have always worked and also how an outsider can drop a message that appears to come from a colleague. Microsoft added an organization-level control for this, RejectDirectSend, set through Set-OrganizationConfig. If you turn it on, inventory the devices that rely on it first and move them to authenticated submission or a restricted connector.

Forwarding. Auto-forward rules and mailing lists break SPF by design, because the forwarding server is not in your SPF record. DKIM survives forwarding as long as the message is not rewritten. That is the practical reason DKIM has to work on the custom domain before you enforce, not just SPF.

Inbound is a separate setting. Publishing DMARC protects other people from forged mail claiming to be you. It does nothing about forged mail arriving at your users. That is governed by your anti-phishing policy, where honoring a sender's p=quarantine and p=reject is controlled separately. Check it while you are in there.

What we watch after the flip

For the first month we read the reports weekly and look for three things: a source that has never appeared before, a known source whose alignment rate has dropped, and a rise in rejected mail from your own IP ranges. The first is usually a tool somebody signed up for. The second is usually a rotated key or a vendor changing infrastructure. The third is worth a phone call.

After that, monthly is enough, as long as somebody still opens that mailbox.

How Guanacos Tech helps

We do this work on Microsoft 365 tenants as often as on Google Workspace ones. A typical engagement is two weeks of reports, a sender inventory, the vendor-by-vendor alignment work, and the walk up to reject with somebody watching while it happens. If you would rather hand it over than learn the XML, our email deliverability consulting for small business covers exactly this. Bring your domain to the call and we will tell you what is published today and how far you are from enforcement.

Sources

The Office 365 SPF record: how to check it, update it, and stay under 10 lookups

Guanacos Tech — Mon, 21 Sep 2026 12:00:00 +0000

A 14-person insurance brokerage calls us on a Monday. Their quotes stopped reaching Gmail addresses on Friday. Nothing changed, they say. Then someone remembers that marketing signed up for a newsletter tool three weeks ago, and whoever set it up pasted a line into DNS because a support article said to.

That is the shape of most SPF problems in a Microsoft 365 tenant. The record was correct the day the domain was connected. Then the business grew, added a sender, and nobody counted what it cost. Here is the check we run first on a client domain, the order we repair it in, and the traps that keep showing up in Microsoft 365 specifically.

Where Microsoft tells you what to publish

Start in the Microsoft 365 admin center. Microsoft's own domain setup documentation sends you to Settings, then Domains, then your domain, then the DNS records view, where the values your tenant expects are listed. That page is useful for one thing: it tells you what Microsoft wants present.

It is not a verdict on your record. The admin center checks that its own value is there. It does not evaluate the rest of the record, it does not count your DNS lookups, and it will happily show a green state on a record that fails at the receiving end. So read the admin center for the required value, then go and look at what the internet actually returns for your domain: query the TXT records of the domain itself, from outside your network.

; what a receiving mail server reads for your domain
example.com.   3600   IN   TXT   "v=spf1 include:spf.protection.outlook.com -all"

That single line is the whole published policy for a tenant that sends only through Exchange Online. Microsoft documents that exact value as the SPF record for Microsoft 365.

What each part of the record is doing

v=spf1 marks the record as SPF. Anything in your TXT set that does not start with this is not an SPF record, whatever it looks like.

include:spf.protection.outlook.com points at the hostname Microsoft maintains, which holds the sending sources for Exchange Online. You never list Microsoft's IP addresses yourself; the include is how you stay current when Microsoft changes them.

-all is the qualifier for everything else. Microsoft's SPF guidance for Microsoft 365, in the version of that page dated 3 July 2026 and checked on 21 September 2026, recommends hard fail: "For Microsoft 365 domains, we recommend -all (hard fail) because we also recommend DKIM and DMARC for the domain." The softer ~all asks receivers to accept but mark the message, which is a reasonable place to sit for a week while you are still discovering senders, and a bad place to live permanently.

Two structural rules matter more than the syntax. First, in Microsoft's words, "only one SPF record is allowed per domain or subdomain." Second, SPF authorises the envelope sender, the address used in the SMTP conversation, not the From address your recipients read in their mail client. Microsoft's documentation is blunt about the gap: SPF makes no attempt to match the envelope domain and the From domain. DMARC is the piece that requires them to line up. A domain can pass SPF and still fail DMARC, which is why an SPF fix alone sometimes changes nothing.

Adding a second sender without breaking the record

This is where the brokerage went wrong, and it is the single most common self-inflicted wound we see. Their DNS ended up holding two separate SPF records:

; broken: two SPF records on the same name
example.com.   TXT   "v=spf1 include:spf.protection.outlook.com -all"
example.com.   TXT   "v=spf1 include:_spf.newslettertool.com ~all"

A receiver that finds two records cannot choose between them, so the evaluation ends in a permanent error and both senders lose the benefit. Microsoft's guidance for domains that already have a record is to add the Microsoft value to the existing record rather than publish a second one. The repaired version is one record with both senders in it:

; correct: one record, both senders
example.com.   TXT   "v=spf1 include:spf.protection.outlook.com include:_spf.newslettertool.com -all"

Before you add anything, get the include string from the vendor's own documentation. Support forum answers go stale, and an include pointing at a hostname the vendor retired is a lookup you are paying for with nothing in return.

Counting lookups, and why flattening is the last resort

SPF has a hard ceiling. RFC 7208 section 4.6.4 limits an evaluation to ten terms that require a DNS query, and an implementation that goes past it must return a permanent error. Microsoft states the consequence plainly: "If the number of DNS lookups is greater than 10, the message fails SPF with a permanent error."

The terms that cost a lookup are include, a, mx, ptr, exists and the redirect modifier. The ones that are free are ip4, ip6 and all, because the answer is already in the record.

The trap is that an include is not one lookup. It costs one query for itself plus every query the record it points to performs, all the way down. Microsoft's include resolves to a record that contains further includes, and several marketing and CRM platforms do the same. Do not assume a number for any vendor. Measure your own record as published, because your total is the only one that matters.

Paste your domain in and see what a receiver sees before you touch DNS:

When the count comes back over ten, work in this order. Each step is safer than the one after it.

Delete includes for services you no longer use. On a domain that has been running since 2018 this alone usually clears the overage. The old CRM, the trial of a helpdesk, the invoicing tool that was replaced two years ago.
Remove leftover a and mx mechanisms. These are often a souvenir of the shared hosting the domain lived on before the move to Microsoft 365. If that host no longer sends your mail, they are two free lookups back.
Move a noisy sender to a subdomain. Let invoicing send as bills.example.com with its own SPF record and its own lookup budget. This costs you a conversation with the vendor about the envelope domain, and it is the most durable fix on this list.
Replace an include with published IP ranges, and only where the vendor commits to stable addresses in writing. ip4 entries are free of lookups and they are also frozen in time, so this step comes with a calendar reminder to re-check, not without one.
Lean on DKIM for what is left. A sender that signs with DKIM aligned to your domain passes DMARC without being in the SPF record at all. For a marketing platform that is usually the cleaner answer.

Automated flattening services, which expand every include into a list of addresses and keep it updated, sit outside that list on purpose. They work until the vendor moves an IP address and the refresh does not happen, and then mail fails on a Saturday with no obvious cause. We use them only where a client has no other route, and never without monitoring.

Verify with a real message, not only with a checker

A syntax checker tells you the record parses. It does not tell you that your invoicing app passes. So send a real message from every system that uses your domain, to a Gmail address and to an Outlook.com address, and read the headers of what arrives.

In the Authentication-Results header you want three things: spf=pass with an smtp.mailfrom that belongs to your domain, dkim=pass, and dmarc=pass. If SPF passes but DMARC does not, the envelope domain is the vendor's and the From domain is yours, and no amount of SPF editing will fix it. Our header analyzer will break a pasted header down if you would rather not read it by eye, and the long version of that skill is in our guide to reading email headers to find why a message went to spam.

Both large receivers now expect this. Google's sender guidelines require every sender to set up SPF or DKIM, and require SPF, DKIM and DMARC together from anyone sending more than 5,000 messages a day to personal Gmail accounts, alongside a spam complaint rate under 0.3 percent and one-click unsubscribe on marketing mail. Microsoft published matching requirements for high-volume senders to Outlook.com, Hotmail.com and Live.com, enforced from 5 May 2025, with non-compliant mail routed to Junk first. Neither rule is new, and both are worth checking against before you decide your record is done.

The traps we hit most often in Microsoft 365 tenants

The record on the wrong name. SPF belongs on the domain that appears in the envelope sender. We regularly find it published at spf.example.com or _spf.example.com, where no receiver will look.
Subdomains with no record of their own. If a subdomain sends mail and publishes nothing, receivers do not inherit the parent's SPF record. Each sending subdomain needs its own.
Scan-to-email and line-of-business apps. The multifunction printer and the practice management system relay into Exchange Online using your domain, and they are invisible until a DMARC report shows them failing. Inventory them before you tighten anything.
The record split badly across strings. A DNS TXT record holds strings of up to 255 characters each. Long SPF records have to be split, and some DNS panels do it in a way that inserts a space or drops a character. Always re-read the published value after saving.
~all with no DMARC behind it. Soft fail without a DMARC policy is close to no policy at all. If you are staying on ~all, publish DMARC and read the reports, then tighten both.

If you are working on a Microsoft 365 domain from scratch rather than repairing one, our Microsoft 365 SPF, DKIM and DMARC setup checklist covers all three records in order, and the DMARC record for Office 365 guide handles the policy ramp afterwards. If the lookup count is the whole problem, the deeper version lives in fixing SPF too many DNS lookups.

How Guanacos Tech helps

We do this for small and mid-sized companies in North America and Latin America, usually in a single session: inventory every system that sends as your domain, rebuild the record into one line that passes and stays under the limit, confirm alignment with real messages at Gmail and Outlook, then watch the DMARC reports for a month to catch the sender nobody mentioned. If you would rather hand it over, our email deliverability consulting for small business starts with a short call to look at your current record and tell you what is actually broken.

Sources

DMARC subdomains: why a locked root domain can still be spoofed

Guanacos Tech — Fri, 18 Sep 2026 12:00:00 +0000

Say a 30-person distributor has done DMARC properly. SPF passes, DKIM signs every message, the record at the root domain sits at p=reject, and aggregate reports land in a mailbox every morning. Then customers start forwarding them fake invoices. The From address reads accounts@billing.example.com, a subdomain the company never created and does not use. The root domain is locked, and the forgery is happening one label to the left of it.

This is the most common hole we find on domains whose owners consider DMARC finished. The policy worked exactly as specified. It was simply never asked the question the owner assumed it was asked.

How a receiver finds the policy for a subdomain

DMARC does not evaluate the domain you configured. It evaluates the domain in the From header of the message in front of it, which the specification calls the Author Domain. Everything about subdomains follows from that one fact.

When a message arrives claiming to be from billing.example.com, the receiver queries _dmarc.billing.example.com first. If a valid record is there, that record decides the outcome and nothing at the root is consulted. If nothing is there, the receiver climbs upward to find the Organizational Domain, the name you actually registered, and applies the record it finds at that level.

The climb itself changed in May 2026, when DMARC became a Standards Track protocol as RFC 9989, obsoleting the informational RFC 7489 from 2015. RFC 7489 worked out the Organizational Domain from the Public Suffix List and queried exactly two names: the Author Domain, then the Organizational Domain. Intermediate levels were skipped entirely, so a record published at _dmarc.eu.example.com was invisible to a message from mail.eu.example.com. RFC 9989 replaces the list with a DNS tree walk, climbing one label at a time and bounded at eight lookups, until it finds the record that marks the boundary. If you have ever published a policy on a middle layer of a deep name and watched it do nothing at all, that is the behaviour that changed.

Either way, the practical rule is the same, and it is the one people get wrong: a subdomain with its own DMARC record ignores the parent completely. Publish v=DMARC1; p=none on a subdomain and it stays in monitoring no matter how strict the root domain is.

The sp tag, and the gap underneath it

When the record that ends up applying was found at the Organizational Domain rather than at the subdomain itself, the receiver does not use p. It looks for sp, the subdomain policy, and falls back to p only when sp is absent. That default is a safe one. A bare p=reject with no sp tag does protect every subdomain that has no record of its own.

The trouble starts because sp=none is genuinely useful during a rollout. It is how you enforce on the root while an invoicing system or a marketing platform on a subdomain is still being sorted out, and we recommend it for exactly that. It is also what plenty of copy-pasted records carry for no reason at all.

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

Under RFC 7489 that record was all or nothing. The sp value covered every subdomain, whether it was a real one you were nursing through a migration or a name an attacker invented five minutes ago. To keep one real subdomain in monitoring, you had to leave every imaginary subdomain in monitoring with it. That is the gap our hypothetical distributor fell into.

RFC 9989 adds np, a policy that applies only when the Author Domain does not exist. The specification ties existence to DNS itself: if a query for the name returns NXDOMAIN, then that name and any subdomain of it do not exist. Valid values are the familiar three, none, quarantine and reject, and np takes precedence over sp for any name that fails the existence test.

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

Read that record as a sentence: enforce on the root, hold the real subdomains in monitoring while we finish the work, and reject anything claiming to come from a name that was never created. Few domains have a good reason to be missing that third clause.

One distinction decides which tag covers what. Existence is a DNS question, not a mail question. A name like app.example.com with an A record pointing at a web application exists. It has never sent mail and never will, but it answers in DNS, so it falls under sp and not under np. Receiver support for np is also not universal yet, so treat it as a layer you add rather than as the only thing standing between you and a forged subdomain.

What we check first on a client domain

Before touching a single record we build the list, because every decision below depends on knowing which subdomains are real and which of them send.

Every name under the domain that resolves, read from the DNS zone rather than from memory. Web apps, staging, VPN endpoints, a printer someone named years ago.
Which of those actually send mail, taken from aggregate reports rather than from what anyone believes.
Whether each sending subdomain has its own _dmarc record, and what it says. A forgotten p=none on a subdomain is a silent override of a strict root.
Whether each sending subdomain has its own SPF record.

That last item is the asymmetry that surprises even experienced administrators. DMARC climbs the tree. SPF does not. SPF is evaluated against the exact domain in the envelope sender, and when there is no TXT record at that exact name the result is none. The record at the root is never consulted and does not help. So a billing system sending as billing.example.com with no SPF record published there fails SPF on every message, and the only thing keeping those invoices deliverable is an aligned DKIM signature. Enforce DMARC without checking that first and the thing you break is your own invoicing.

Subdomains that should never send

For every name on the list with no business sending mail, we publish three records. Order matters less than all three being present.

app.example.com.        MX   0 .
app.example.com.        TXT  "v=spf1 -all"
_dmarc.app.example.com. TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

The first is a null MX, defined in RFC 7505 as a single MX record with preference 0 and a zero length exchange written as a dot, announcing that the name accepts no mail at all. A domain advertising a null MX must not advertise any other MX record, so clear out anything stale before you add it. The second says no host is authorised to send as that name. The third stops the name depending on sp at all, which is what makes the pattern worth the effort on the handful of names that matter, even once np is in place.

In a large zone we cover only the names that look plausible in a forged From address: billing, invoices, pay, hr, payroll, secure, and the name of whatever finance system the company runs.

Delegating a subdomain to a marketing platform

The opposite case is a subdomain that exists precisely so somebody else can send from it. When a company runs campaigns through an email platform, moving that traffic to news.example.com instead of the root domain buys two things worth having.

The first is reputation separation. A campaign that collects complaints damages the reputation of the name that sent it, so keeping bulk mail off the name your quotes and invoices go out on means one bad send does not follow your sales team into the inbox.

The second is the SPF lookup budget. SPF allows ten DNS lookups during evaluation, and a record that exceeds it returns permerror, which fails SPF outright. Platform include mechanisms are the usual reason a domain runs out of room. Because SPF is evaluated per name, an include living on news.example.com costs the root domain nothing. Delegating your two or three heaviest senders to their own subdomains is often a cleaner fix than flattening records that then quietly go stale. We covered the counting and the alternatives in the guide to getting under the ten lookup limit.

On a delegated subdomain we set up the platform's SPF and DKIM records at that name, its own _dmarc record so the subdomain can sit at a different policy from the root while it is warming, and a check that the platform signs with a domain that aligns. Alignment is where these arrangements usually come apart. In the default relaxed mode, SPF and DKIM align when the authenticated domain and the From domain share the same Organizational Domain, so a DKIM signature carrying d=example.com aligns with a From address at news.example.com. In strict mode, set with adkim=s or aspf=s, the names must match exactly, and that same pairing fails. Turning on strict alignment without auditing subdomain senders first is a reliable way to break a campaign. The platform-specific records for the common senders are in our post on Mailchimp, HubSpot and Klaviyo alignment.

Reading the subdomain rows in your reports

Aggregate reports, which RFC 9990 specifies in its own document, are where you learn which subdomains exist in practice rather than on paper. Two habits make them useful for this.

Read the header From domain in each record block, not only the policy you published. Reports group by the domain the messages claimed, so subdomain traffic shows up as its own rows, easy to skim past when you are scanning for volume. A row for a subdomain you do not recognise is the entire reason to look.

Then check what the report says was actually applied. The published policy block gives you your record as the receiver read it, sp included, so you can confirm your subdomain policy is being seen the way you intended instead of assuming it from your own DNS. When a subdomain shows failures that were delivered anyway, the usual answer is a forgotten _dmarc record on that subdomain quietly overriding the root, and the report is where that becomes visible. Our walkthrough of the XML is in how to read a DMARC aggregate report, and you can paste one into our DMARC analyzer to see the rows decoded.

How Guanacos Tech helps

Subdomain work is inventory before it is DNS. We pull the zone, reconcile it against what the reports show is really sending, and then decide name by name which subdomains get a proper delegated sending setup, which get locked down, and which can simply inherit from the root. If your root domain is already at p=reject and you want to know whether that protection reaches one level down, run your record through the analyzer or book a call and we will walk your zone with you.

Sources

Gemini 2.5 retires on 16 October. What breaks, and what we check first

Guanacos Tech — Fri, 18 Sep 2026 12:00:00 +0000

Picture a small accounting firm calling in late October because the quoting assistant on its website has stopped answering. Nothing was deployed that week. Nobody touched the code. The logs show the same request going out and a 404 coming back, over and over, from a model that answered fine the previous Friday.

That is what an AI model retirement looks like from inside a small business. There is no status page, no red banner, no outage anyone else is tweeting about. A feature simply stops working, and the person who built it left months ago.

There is one of these on the calendar right now, and it is close.

What changed, and the date that matters

On 14 September 2026, Google published updated retirement and deprecation dates for a group of Gemini models in the Google Cloud release notes. The entry that affects the most working software: Gemini 2.5 Pro, Gemini 2.5 Flash and Gemini 2.5 Flash-Lite carry a retirement date of 16 October 2026, as listed in Google's model lifecycle documentation, checked on 18 September 2026.

Two details in that lifecycle documentation matter more than the headline date, and they are the ones people miss.

The first: a retirement date is the last day the model is available. After it, Google's documentation states the model is permanently deactivated and no longer accessible or supported, and API requests that reference a retired model ID typically return a 404 error. Not a warning, not a slower fallback. A 404, which most code written in a hurry treats as a generic failure.

The second detail is the one that catches people out. Google's model versions and lifecycle page states that one month before the retirement date, new access to the model is blocked for online inference, batch inference and tuning. For a 16 October retirement, that window closed around the middle of September. If a project has never called Gemini 2.5 before, it may already be unable to start, which makes "we will test it on the old model first and migrate later" a plan that no longer works.

Who this actually affects

Not everyone who uses Gemini needs to do anything. The distinction is whether a model name is written down somewhere in your systems.

If your team uses Gemini inside Google Workspace, in the side panel in Gmail or Docs, you are not choosing a model version and you do not have a migration to run. Google manages what is behind that experience.

You are exposed if a model ID such as gemini-2.5-flash appears anywhere your business depends on. In a company of ten to sixty people, it usually lives in one of a handful of places:

An Apps Script bound to a spreadsheet that classifies incoming leads or drafts replies.
A website chat widget or quote form, usually a Cloud Function or a small backend service.
An automation platform step, where the model name sits in a dropdown or a JSON field inside a workflow nobody has opened in a year.
A mobile or web app built on Firebase.
A reporting or summarising script running on a schedule, whose output somebody pastes into a client deck every month.
A prototype that quietly became production because it worked.

The last one causes the most damage, because it is the one with no owner, no tests and no error handling.

What we check on a client project first

When a client asks us to handle one of these deadlines, we do not start by changing model names. We start by finding all of them.

1. Inventory every call site. Search the whole estate, not just the main repository, for the model family rather than one exact string. Version suffixes vary, so the loose match is the point:

grep -rn "gemini-2\.5" . --include="*.js" --include="*.ts" --include="*.py" --include="*.gs" --include="*.json" --include="*.yaml" --include="*.env*"

Then repeat that by hand in the places grep cannot reach: Apps Script projects attached to spreadsheets and forms, automation platform workflows, environment variables set in a console rather than in a file, and any configuration a previous contractor set up.

2. Separate pinned versions from aliases. Google publishes stable model versions alongside auto-updated aliases. Code that pins an exact version is predictable and will break on a known date. Code that follows an alias moves on its own, which is convenient until a model generation changes behaviour under a prompt that was tuned for the old one. Both need review. They need different reviews.

3. Test whether access is already blocked. Because of the one-month rule above, we check early whether the project can still reach the old model at all. It changes the plan. If it cannot, there is no gradual cutover to design, only a migration.

4. Trace what consumes the output. A model call that fails is one problem. A model call whose answer is written to a database, emailed to a customer, or used to decide which queue a ticket lands in is a much bigger one. We follow the output to its last stop before deciding how careful to be.

5. Read the error handling. This is where we find the real risk. Plenty of small integrations wrap the API call in a try block that swallows the exception and returns an empty string. On retirement day that code does not crash. It keeps running, and it quietly sends blank or truncated content to real customers, which nobody notices for a week.

The migration, in the order we do it

Read the current model list for your own project. Not a blog post, including this one. Dates and availability differ by region and by surface, and Google's own model pages are the only place they are authoritative for your account.

Choose a generally available model, not a preview. Preview models carry their own, often shorter, lifecycle and are not a place to land production work that you do not want to move again in six months. If the only replacement that fits your use case is in preview, that is worth knowing before you plan the work, not after.

Move the model ID into configuration. If the string is hard-coded, the first change is to pull it into an environment variable or a single constant. That is the fix that makes this deadline the last painful one, because the next retirement becomes a config change and a test run.

Re-test the prompts, do not just swap the name. A newer model generation is not a drop-in replacement. Output length, tone, formatting and how strictly it follows instructions all shift, and parameter names sometimes change between generations, so check Google's migration guidance for the pair you are moving between. If your prompt asks for JSON, test that it still returns parseable JSON. Run the twenty most common real inputs and read the answers side by side.

Fix the error handling while you are in there. Any call that can fail should fail loudly: log the model ID, log the status code, and alert a human. Ten minutes of work here converts every future deprecation from a mystery into a notification.

Ship, then watch. Deploy before the deadline, not on it, and keep the old value in configuration until you have seen a full week of normal traffic on the new model.

Cost and risk notes

Three things worth setting expectations on.

Pricing is per model, so verify it. Rates differ between model families and tiers, and a newer or larger model is not automatically the cheaper or the more expensive option. Check the current rate for the specific model you are moving to against your real monthly volume before you commit, rather than assuming the swap is cost neutral.

These dates move, in both directions. They are not always brought forward. In the same set of September 2026 updates, Gemini 2.5 Flash Image was given a retirement date of 15 March 2027, extended from 2 October 2026, and Gemini 3.1 Flash-Lite Image was listed with a retirement date scheduled for 28 June 2027 or later. An extension is a gift, not a plan. The correct response to a moved date is to keep the migration scheduled and enjoy the extra room.

The real risk is inventory, not engineering. Changing a model name is a small task. Being certain you found every place it appears is the whole job, and the first search through a codebase is rarely the one that finds everything.

How Guanacos Tech helps

We do this as a short, contained piece of work: inventory every place a Gemini model is called across your code, scripts, automations and consoles, tell you which ones break on 16 October and which ones are fine, migrate the ones that matter, and leave the model ID in configuration with error handling that speaks up next time. We are an independent consultancy with Google-certified engineers, and we work in English and Spanish across North America and Latin America.

If you are not sure whether anything in your business calls Gemini 2.5, that uncertainty is the answer, and it is worth an hour before October. You can see what we do on Google Cloud, or book a call and we will go through it with you.

Sources

Moving email from cPanel or shared hosting to Google Workspace without losing a message

Guanacos Tech — Thu, 17 Sep 2026 12:00:00 +0000

Say a 14-person import business in San Salvador. Its mail has lived on shared hosting since 2016: eleven cPanel mailboxes, a webmail nobody enjoys, a 2 GB quota per account that accounting hit two years ago, and invoices that started landing in clients' spam folders this quarter. They want Google Workspace. Before anything else, they want to hear that nobody is going to lose eight years of email.

That is the real objection, and it is a reasonable one. The migration itself is routine work. The fear is not, because mail does get lost in these projects, almost always for one of two reasons: DNS moved before the mailboxes were copied, or nobody wrote down what the old host was sending on the company's behalf.

This is the order we work in when the starting point is cPanel or any other shared hosting mail, what the Google tooling actually copies, and where things quietly break.

Shared hosting mail is two systems, and only one of them migrates

The mailboxes are one system. The configuration around them is another: forwarders, autoresponders, filters, aliases, mailing lists, the catch-all address. Google's data migration service reaches the first over IMAP and cannot see the second at all. When the source is an IMAP server, the service moves email and label data only. Calendar events, contacts, Drive files and Sites are not part of an IMAP migration. Everything in cPanel that is configuration rather than a message gets rebuilt by hand in the Admin console, which is fine as long as somebody wrote it down first.

Three limits are worth knowing before you promise anything. The IMAP path in the data migration service supports up to 100 source users. Messages larger than 25 MB including attachments are not migrated. Shared and public IMAP folders are not supported. For a small company the first two rarely bite, but the 25 MB ceiling does, on exactly the mailbox you would expect, the one that receives scanned contracts.

The inventory, before anything is created

We open a sheet and fill it from the control panel itself, not from memory:

Every mailbox, its current size and its quota. The size tells you how long the copy will run. The quota tells you which accounts have been silently rejecting mail.
Every alias, forwarder and mailing list, with its destination.
Every filter and autoresponder, including the ones a user set from webmail years ago and then left the company.
The catch-all setting. On shared hosting it is often switched on, which means mistyped addresses have been landing somewhere for years.
Every application that sends as the domain: the invoicing or DTE provider, the online store, the CRM, the website contact form, the scanner in the corridor.
The current MX, SPF, DKIM and DMARC records, with their TTL values.
Who actually controls the registrar and the DNS zone. This is the item that delays cutovers.

The application list is the one people skip, and it is the one that produces the "everything works except the invoices" phone call a week later.

Create users the way you will pay for them

Each real person gets a user. Shared addresses such as info@ or ventas@ become groups, not accounts with a password three people know. Aliases stay aliases on the user who reads them. A company arriving from shared hosting usually has far more addresses than people, and the difference between modeling that correctly and creating one licensed user per address is most of the first year of licence cost.

Verify the domain with the TXT record Workspace gives you, create the users, and stop there. MX stays where it is.

Copy the mail while the old system is still live

The data migration service connects to the hosting server over IMAP and copies into the new mailboxes while mail keeps flowing normally to cPanel. Nothing is disrupted, so there is no reason to rush this stage. You need the mail server hostname, the IMAP over TLS port, and either each mailbox password or an administrative credential your host allows for migrations.

Source server:  mail.example.com
Port:           993 (IMAP over TLS)
Per mailbox:    address + password from the hosting control panel

Run the full copy days ahead of the cutover. Then run the service again afterwards against the same source. That second pass is a delta: it picks up everything that arrived at the old host in between, and it is the mechanism that makes the whole project safe. A source mailbox carrying more than 6,000 labels or folders also needs a delta pass to finish.

One check before you start. An account cannot receive more mail than its Workspace storage allows. If a 40 GB cPanel mailbox is heading into a plan with less storage than that, the import stops partway, and the fix is a plan change rather than a retry.

Lower the TTL two days early, not on the morning

This step decides whether your cutover window is measured in minutes or in a day. A record's TTL tells resolvers how many seconds to cache it, and a shorter TTL only starts applying once the previous value has expired. If the MX record has been sitting at 86400, lowering it this afternoon does not help this afternoon: resolvers that already cached the old record can hold it for another 24 hours before they start honoring the new, shorter value. Lower it at least two days ahead. Google recommends 3600 as a working value, and a shorter one such as 300 when you want to be able to reverse a change quickly, which is exactly the situation on cutover day.

; typical shared hosting default
example.com.   86400   IN   MX   0 mail.example.com.

; two days before the cutover: same target, shorter TTL
example.com.   300     IN   MX   0 mail.example.com.

The cutover, in order

Confirm the bulk migration has finished and that users can see their old mail in Gmail.
Replace the MX record with the Google Workspace value and delete the hosting MX. Do not leave the old one behind as a lower priority backup, because that is how mail keeps arriving somewhere nobody is watching.
Send a test message from an outside address and confirm it lands in Gmail.
Leave the cPanel mailboxes in place, still receiving whatever reaches them.
Run the delta migration the next day, and once more about a week later.
Raise the MX TTL back to 3600 when you are confident.

example.com.   300   IN   MX   1 smtp.google.com.

Google Workspace uses a single MX value, smtp.google.com. Registrars disagree about how it should be typed: some require a trailing period, and some expect the priority and the destination together in one field as 1 smtp.google.com. Domains that started on Workspace before 2023 may still carry the older set of aspmx records, and those are still supported, so there is no need to change them as part of this project. New MX records can take up to 72 hours to be recognized everywhere, although with a 300 second TTL already in place most senders follow within minutes.

The days after the switch are the double delivery window: some senders still resolve the cached old record and deliver to cPanel. That is expected, and it is harmless as long as the old mailboxes still exist. Deleting them on cutover day is the single most common way to genuinely lose mail in this migration. Two weeks is a reasonable holding period, with the hosting account cancelled only after the final delta run.

The senders that keep using the old server

After the MX change, mail.example.com usually still resolves and still accepts SMTP. Every application configured with that hostname and an old mailbox password keeps working, in the sense that it keeps sending. Those messages now leave through a server the domain no longer authorizes, and the copies land in a mailbox nobody opens. Work down the application list from your inventory and repoint each one: the store, the CRM, the contact form, the scanner, the invoicing platform. In El Salvador the DTE provider belongs on that list too, and we wrote up why electronic invoices land in spam separately.

Authenticate the same day

A domain leaving shared hosting is also leaving a shared sending reputation, which is usually one of the reasons for the move in the first place. Publish the new authentication on cutover day rather than next month:

example.com.         300  IN  TXT  "v=spf1 include:_spf.google.com ~all"
google._domainkey    300  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBg..."
_dmarc               300  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

SPF is one record per domain. The hosting SPF record is replaced, not stacked next to the new one, because two SPF TXT records is a permanent failure. DKIM is generated in the Admin console under Gmail, Authenticate email: choose a 2048 bit key if your DNS provider supports it, keep the default google selector prefix, publish the TXT record, then return to the console and start authentication. A 2048 bit key does not fit in a single 255 character DNS string, so it goes in as several quoted strings inside the same TXT record, something some registrar interfaces handle for you and some do not. DMARC starts at p=none with a reporting address, and enforcement comes after you have read a couple of weeks of reports, which is the subject of moving DMARC from p=none to p=reject.

Leave the old host's DKIM selector and SPF include in DNS until you have confirmed that nothing sends through that server any more, then remove them.

What usually goes wrong

The old mailboxes were deleted on cutover day, so anything delivered during the cached DNS window is gone for good.
The catch-all was never recreated, and addresses that used to be quietly accepted now bounce.
Filters and forwarders were assumed to migrate. They do not, and they are rebuilt in Gmail settings and in the Admin console.
Someone expected contacts and calendars to arrive with an IMAP migration. Those are exported and imported separately.
The TTL was lowered on the morning of the change, so the old record stayed cached for the rest of the day.

How Guanacos Tech helps

We are an independent consultancy with Google-certified engineers, working in English and Spanish across North America and Latin America. We run the inventory, do the IMAP copy, sit on the cutover hour, rebuild the forwarders and filters, and publish SPF, DKIM and DMARC the same day, so the domain arrives authenticated instead of being repaired later. If you want to see where your domain stands before touching DNS, the email troubleshooter is free, a Workspace engagement sets out the scope, how we work covers scoping, and you can book a call at calendar.app.google.