On July 30, 2020, GoTo published a security alert. Someone had opened GoTo Webinar trials and used them to send spam from customercare@gotowebinar.com, a real address carrying GoTo's own signature. GoTo paused the trials and said it would harden them.
Years later, the same address landed in a spam folder. Display name: Claude AI Access. The subject pushed locked-in access to Opus, Sonnet and Enterprise before the price jumped to $597 a month. The body thanked the recipient for registering for a webinar called "The $14.95 lifetime Claude deal is ending today." He had never registered. The author of the original account walks through the headers and what they prove, and the full post is worth reading before you draw your own conclusions.
Mailed by g2w.gotowebinar.com. Signed by gotowebinar.com. Every authentication check said GoTo sent it. GoTo did send it. The reply-to gave it away: puby@productfares.com.
Authentication answers one narrow question
SPF, DKIM and DMARC answer whether a domain sent a message. They say nothing about who wrote it, what they wanted, or whether the recipient ever asked to hear from them.
That is not a flaw in the protocols. It is the job they were handed. Authentication is a bouncer checking that the badge is genuine. It is not checking whether the person wearing it should be in the building.
Most deliverability advice treats a passing SPF, DKIM and DMARC setup as the finish line. It is closer to the starting line. Once you are provably who you say you are, the question becomes what your sending identity has been used for, and by whom.
One signature, every sender
GoTo Webinar's setup mails every host from the same shared address under one signature. That means one reputation, shared by every company running a webinar and by whoever signed up this morning. When a fresh trial account gets used for a scam, the cost lands on everyone else in the pool.
This is not unique to webinar platforms. Any shared sending pool works the same way. A single bad actor degrades the reputation that everyone else's legitimate mail depends on, and the damage shows up in inbox placement for companies that did nothing wrong.
GoTo's support staff have advised hosts to ask attendees to whitelist customercare@gotowebinar.com so confirmation emails stop landing in spam. The advice is well intentioned, and it is also the tell. Anyone who followed it can now get a Claude subscription pitch delivered straight to the inbox.
What this means if you run outbound
If you send cold email at volume, you are probably closer to this situation than you think. Shared IPs, shared sending domains, and platforms where the domain in the From line belongs to the vendor rather than to you all create the same structure. Your reputation is a shared account, and you do not control who else holds a key.
Check who else is on your sending identity
Ask your sending platform whether your domain and IP are exclusively yours. If the answer involves a pool, a rotation, or "shared but monitored," you are trusting every other tenant's signup process with your inbox placement.
Keep the sending identity yours
A From address that belongs to your company, on infrastructure dedicated to your account, keeps the blast radius small. When something abusive goes out from a shared address, nobody sorts out which host it belonged to. Everyone's mail gets treated the same way.
Whitelisting is a workaround, not a fix
Asking recipients to whitelist an address patches a reputation problem you did not cause. Fix the sending identity instead.
Mailheight sends from dedicated servers, so the reputation your mail carries is built by your mail alone. That does not make deliverability automatic. You still have to validate lists before you send, keep bounces down, watch where your mail actually lands, and keep your DNS records clean. The rest of the Hamcut Ecosystem covers those jobs with FindValidEmail, InboxSense and DNSPulse. Dedicated infrastructure simply means that when someone else's bad day happens on a shared pool, the fallout does not land in your folder.
The GoTo case is a reminder about order of operations. Authentication proves the domain sent it. It never proves the sender earned the right to be there. Those are two different problems, and only one of them is solved by a DNS record.