Subscribe
Share
Share
Embed
Welcome to our podcast, where we dive into everything Go High Level—from mastering the basics to tackling the most complex tasks. I use GHL daily in my business and rely on Google NotebookLM to stay ahead of the curve, keeping up with all the latest GHL features, tools, and innovations. This podcast is powered by AI, fueled by the research and insights I personally curate to bring you the most valuable and up-to-date content.
Copy this link for a free trial of Go High Level - https://www.gohighlevel.com/highlevel-bootcamp?fp_ref=amplifi-technologies12
Imagine this. You just spent a week building this flawless high-converting funnel for a brand new high paying client. Oh, the dream scenario. Right. The copy is dialed in, the automation is set, you flip the switch, a prospect opts in and the welcome email arrives. But instead of seeing your client's pristine brand name in the inbox. Oh, no. Let me guess. Yeah, they see a sender address that looks like, I mean, a scrambled math equation. Something like test plus go highlevel.com at msg.msg sendr.com. It just screams spam. It really does. The prospect deletes it immediately and your client is furious. Yeah. So today, we are making absolutely sure that nightmare scenario never happens to you. Welcome to the deep dive. Glad to be here for this one. And before we unravel the uh, the mechanics of high level email deliverability, I actually have a massive advantage for you. If you check the show notes right below this deep dive, you will find a link for a completely free 30-day go high level trial. Wow, 30 days. Yeah. That is double the standard trial length. So if you want the runway to architect the exact systems we're about to discuss without, you know, the pressure of a 14-day ticking clock, grab that link and put it to work. That's a huge head start because the scenario you just described, um, it isn't a hypothetical. Really? No, it is the active reality for a lot of agencies right now, particularly those operating sub-accounts created after uh August 26th. Okay, yeah, I noticed that specific date highlighted in the documentation. It's tied to the new um they call the refactoring update, right? Exactly. The sources state that high level is automatically altering shared domain email addresses now. So, if a client configures their sender address as say hello@theirbrand.com, but they are still piggybacking on the platform's default shared infrastructure. High level steps in. They rewrite that address before it even leaves the server. Wow. Okay. But why? Well, it's important to understand the mechanics of why they're doing that. Out of the box, High Level provisions you on their shared mail gun or custom SMTP infrastructure. Which is, I mean, incredibly convenient for a fast start. Oh, totally. But from a routing perspective, when you have thousands of distinct businesses firing off campaigns from a shared IP pool, Right. The risk of a few bad actors burning the sender reputation for the entire server is astronomical. Precisely. So the refactoring that messy plus format string we mentioned earlier, is basically High Level's way of forcing a transparent paper trail. Oh, I see. They are stamping the outgoing email so the receiving mail servers know exactly which shared pipe it came from. It protects their core routing infrastructure. Okay. So it's like um borrowing a friend's car to go to a corporate pitch. Right. But the car has a massive bumper sticker with their name on it. Wait. So if I'm an agency owner, my client's carefully branded emails are always going to look like a weird math equation in the inbox if I stay on the shared domain. That is exactly what the recipients see. They are maintaining the integrity of the shared network. But for an agency owner, the operational reality is that you cannot allow client communications to go out looking like that. No, of course not. It immediately shatters the illusion of a one-to-one professional brand interaction. Exactly, which means relying on the shared domain is no longer a viable long-term strategy for anyone running a serious agency. It essentially forces our hand. Yeah. We have to architect a dedicated sending domain or a DSD for our clients. Setting up a DSD is the only way to bypass that refactoring logic. It tells the platform, hey, I am taking ownership of my sender reputation, route this through my authenticated channels. Okay. So how do we actually do that without blowing up the client's main business domain? Well, when we talk about setting this up, the golden rule in the documentation is that you must use a unique subdomain, not the client's main root domain. Right. So just to clarify the operational strategy there for you listening. We use a subdomain like emails.agencybrand.com or maybe ND.agencybrand.com. Yes, exactly. To compartmentalize the risk. Because if a massive cold outreach campaign goes sideways and triggers a spam filter, we want that reputational damage isolated to the subdomain. Right. You cannot risk having the agency's primary root domain blacklisted. Yeah. That would completely tank our internal day-to-day business communications. But wait, let me push back on that for a second. Sure. If I'm sending from a subdomain like emails.agencybrand.com, won't my client's replies get lost in the void? Why not just use the root domain for everything to keep it simple? That is the immediate push back we usually hear from agency operators. There is a fear that when a prospect hits reply, that response is going to get lost. But that shouldn't be the case if the system is configured correctly. Because the from address and the reply to address serve two completely different functions, right? Exactly. Two completely different mechanical functions. The from address, the subdomain, is just the authenticated vehicle delivering the payload. It's the logistics network. But inside the platform, you simply set the reply to header back to your primary root domain inbox. Ah, okay. So it's a dual layer approach. You leverage the subdomain to satisfy the receiving server's authentication checks. Right. But you dictate the return path for the actual human interaction. You got it. Now, speaking of those authentication checks, the actual implementation requires generating CNAME, SPF and DKE records in High Level and assisting them into your DNS provider. Okay, let's pause on SPF and DKE. Because the documentation throws these acronyms around, but we need to understand what they're actually doing under the hood. They aren't just arbitrary text files you copy and paste, right? Not at all. Let's use a um a physical mail analogy. Think of your email as a letter inside a physical envelope. Okay. SPF or Sender Policy Framework is essentially the return address printed on the outside of that envelope, but it goes a step further. Oh, so. SPF is a public ledger. It's a list published in your DNS that explicitly tells the receiving post office like Gmail or Outlook, which specific IP addresses are legally authorized to send mail on behalf of your domain. So, if an email shows up at Gmail's sorting facility claiming to be from my domain, but the IP address of the server that sent it isn't listed on my SPF record. Gmail immediately flags it as a forgery. Wow. Okay. So it either rejects it or dumps it straight into the spam folder. Exactly. Now, DKIM or Domain Keys Identified Mail acts as a cryptographic wax seal on that envelope. A wax seal. I like that. Yeah. When you send an email, your server uses a private key to sign it. When Gmail receives it, it looks up your public key, which is stored in that DKIM DNS record you set up, and uses it to verify the signature. So, DKIM basically proves two things. First, that the sender actually holds the private key for that domain, and second, that the contents of the email weren't intercepted and tampered with while in transit. Spot on. If the wax seal is broken or doesn't match the public key, the post office rejects the package. That cryptographic mechanism is really the foundation of modern deliverability. But agency owners need to bake the reality of DNS architecture into their standard operating procedures, don't they? Oh, absolutely. When you update these records, you are relying on global DNS propagation. It takes time for every server across the Internet to update their local cache and recognize your new SPF and DKIM records. Yeah, the documentation mentions 24 to 48 hours. Which means from an agency operation standpoint, you cannot promise a new client a same-day launch during onboarding. Definitely not. You have to physically build this 48-hour dark period into your project timelines. Right. So you configure the DNS on Tuesday, but you do not flip the switch on the campaigns until Thursday. It sets proper client expectations and, you know, prevents catastrophic day one bounce rates. And while we are on the topic of compartmentalizing risk, the documentation details a fascinating feature, specifically for calendar emails. Oh, right. High Level allows you to provision up to five dedicated subdomains exclusively for calendar notifications, right? Like your confirmations, reminders, and reschedules. Yes. And mathematically, you can distribute the sending volume across those five domains using percentage based routing. That's wild. Yeah. But um why separate them from the main marketing DSD? I mean, we already isolated the subdomain from the root domain. It comes down to intent and consequence. A marketing email is inherently promotional, right? So it carries a higher baseline risk of user complaints or spam placement. Sure. But a calendar reminder is a purely transactional email. If a marketing email hits the promo tab, you might lose a click. If a calendar reminder hits the spam folder, Your client gets a no show. Exactly. That directly impacts their bottom line. So, by isolating calendar emails on their own dedicated IP and domain infrastructure, you insulate those critical time-sensitive alerts from any reputational damage caused by a cold email blast. It's an operational firewall. And to actually monitor the health of that firewall, the sources heavily push integrating Google Postmaster Tools. Yeah. Google Postmaster Tools or GPT. That seems non-negotiable for serious senders. It really is. High Level's internal reporting will tell you if an email successfully left their servers. But that is only half the journey. Right. GPT, which you verify via a simple TXT record in your DNS, gives you the telemetry from the destination. It tells you how Gmail, which, by the way, likely comprises 60 to 70% of your client's list, is actually evaluating those SPF and DKIM records we just talked about. That's crucial. You get visibility into your domain reputation, your IP reputation, and crucially, your user reported spam rate. Yeah. It shifts you from assuming your emails are landing to knowing exactly how the algorithm is scoring them. Okay. Which brings us to the safety net. You've built the infrastructure, configured the DNS, separated the calendar domains, and you are monitoring the telemetry. But let's be real, agencies are chaotic environments. Oh, incredibly chaotic. You have multiple account managers, new hires, and clients logging into the system every single day. The human error variable. Always. Let's say your authenticated dedicated sending domain is email.agencybrand.com, but an intern logs into a sub-account, builds a new automation workflow, and accidentally sets the from address as sales@totallydifferentdomain.com. Okay, let's trace the mechanics of that mistake. When that email fires, it's going to trigger a DMARC alignment failure. Yes, instantly. Because going back to our physical mail analogy, the envelope's return address, the SPF says email.agencybrand.com and the wax seal, the DKIM, belongs to email.agencybrand.com. Right. But the actual letterhead inside says totallydifferentdomain.com. The receiving server sees that mismatch immediately. DMARC, which stands for Domain-based Message Authentication, Reporting & Conformance, dictates how the receiving server should handle that mismatch. And if DMARC fails, the email is almost guaranteed to be rejected or quarantined. So a single typo by an intern can completely nuke a campaign's deliverability. That's a massive vulnerability for an agency managing hundreds of automations. It was a huge point of friction, which is exactly why High Level developed the default header feature to intercept this exact scenario. And the recent change log highlights a critical shift in how this feature operates. Yeah, I saw that update. Previously, the default header was kind of a blunt instrument, wasn't it? It acted as a primary identity, aggressively overriding the from name and email for almost everything leaving that sub-account. Which caused its own set of routing headaches. It lacked nuance. The new update fundamentally changes the logic. The default header now functions strictly as a fallback mechanism at the server level. Okay. So let's break down the conditional logic. At send time, High Level servers run a pre-flight alignment check. Right. If the from address configured in the workflow perfectly matches the authenticated DSD, the system remains invisible. The email deploys exactly as intended. But if that pre-flight check detects an alignment failure, like our intern using totallydifferentdomain.com, High Level server intercepts the payload before it reaches the wider Internet. Wait, really? So it stops it before it even goes out? Yes. Instead of letting that mismatched email hit Gmail servers and fail DMARC, High Level physically strips the invalid from address out of the email header. And replaces it with the fallback default header you configured. Exactly. It overwrites it with something like support@email.agencybrand.com. That is brilliant. It's like um it's like DMARC is a strict bouncer at a club. If your ID doesn't match the guest list, the bouncer's going to throw you out. Good analogy. But the default header is like having a VIP manager step in at the last second and say, wait, they're with us, handing them a temporary VIP badge. The post office receives a perfectly aligned package, the DMARC check passes, and the email lands in the inbox. It is an elegant fail-safe. And while it saves you from embarrassing campaign failures, it is absolutely paramount for agencies servicing regulated sectors, like healthcare, finance, or legal. Because their compliance frameworks are so rigid. I mean, a financial institution cannot afford to have client communications quarantined in a spam filter due to a DMARC failure. Exactly. It's not just bad marketing, it's an operational and potentially legal liability. The fallback logic guarantees that regardless of user error at the workflow level, the outgoing message remains authenticated and consistently delivered. Now, implementing this requires a strict structural hierarchy, doesn't it? If an agency is managing 50 different brands, the documentation is adamant about segregation. Yes. Default headers and dedicated sending domains must be configured at the sub-account level, never at the global agency level. Because if you try to manage multiple brands from a single agency level domain configuration, you lose that granular control. Agency level setups don't support per sub-account fallback logic. Right. Which means if Brand A makes a workflow mistake, it might accidentally trigger a fallback header that belongs to Brand B. Oh man. Suddenly a plumbing client's customers are receiving emails from a dental practice support alias. It's a cross-contamination nightmare. So by isolating every client into their own sub-account with their own DSD and their own fallback headers, you basically contain the blast radius of any human error. Segregation is key to scaling safely. But, uh, there is a massive operational blind spot regarding those fallback headers that agencies stumble into all the time. We call it the black hole effect. Okay, let's unpack that because it's a critical logic gap in the sources. So, High Level intercepts the mismatched email. It successfully overwrites the sender with your fallback, let's say support, at email.agencybrand.com. Yep. The email successfully navigates the DMARC check, bypasses the spam incinerator, and lands in the prospect's primary inbox. The prospect reads it, they are interested, and they hit reply. Right. And where does that reply go? It goes back to support@email.agencybrand.com. But if you merely type that address into the High Level settings as a, you know, a technical placeholder and never actually provision a real inbox for it, that prospect's response drops straight into the void. You successfully force the delivery of the email, but you completely orphan the reply. Which violates the core purpose of the campaign. You must ensure that whatever fallback address you designate is attached to a monitored mailbox. Or at the bare minimum, an alias that routes to a centralized ticketing system or a live team member. You cannot leave the door open for the customer and then refuse to monitor the hallway. Perfectly said. So moving on to the actual provisioning of these domains, there are two specific technical blockers in the documentation that will stop an agency's onboarding process dead in its tracks, especially if they don't understand the underlying DNS mechanics. Oh, yeah. Troubleshooting these is a daily task. The first is the domain already pointing to email server error. It's a highly common friction point. It usually occurs when an agency takes over a client who previously tried to set up their own infrastructure or maybe they used a legacy marketing tool. Yeah, the error makes it sound like the High Level integration itself is broken, but it's actually a conflict at the DNS level, right? Exactly. The client's DNS host still contains old MX or SPF records pointing to like MailChimp or ActiveCampaign. So, High Level is trying to publish its records, but the DNS host is rejecting the update because it sees a conflicting set of routing instructions. The fix requires a bit of forensic work. You use a public DNS lookup tool, query the domain, isolate those legacy MX or SPF records, and manually delete them from the registrar. You have to demolish the old plumbing before High Level can lay the new pipes. Exactly. Now the second, and arguably more frustrating blocker, involves wildcard DNS records. The documentation highlights this as a major trap. Okay, a wildcard record, that's typically denoted by an asterisk, right? Like asterisk.agencybrand.com. Right. It's a catch-all routing rule. It tells the Internet that regardless of what subdomain someone types in, whether it's real.agencybrand.com or absolutejibberish.agencybrand.com, route that traffic to a single default IP address. So, how does a catch-all routing rule interfere with High Level verifying our new DSD? It interferes with the SSL and TXT verification architecture. When High Level attempts to ping the specific subdomain you just created to verify ownership, the DNS host's wildcard rule intercepts the request. Ah, I see. Yeah, and it responds with a generic yes, a record exists here message, rather than returning the specific cryptographic strings High Level is looking for. Oh, wow. So the platform misinterprets that wildcard response as a pre-existing conflicting record and blocks the verification entirely. That's exactly what happens. So if the wildcard is actively blinding the verification ping, I'm assuming the only path forward is a temporary takedown. Yep. You have to log into the DNS host, delete the wildcard record, and allow High Level to ping the specific unencumbered DSD records. And then, once the platform gives you the green checkmark, you just reinstate the wildcard. That is the exact workaround. It's a temporary lowering of the shields to let the authentication through. Navigating those nuances, you know, understanding why a wildcard breaks an SSL handshake or how DMARC intercepts a mismatched domain, is the line between someone who just uses the platform and an agency operator who actually architects infrastructure. That is an incredibly crucial distinction. As we wrap up this deep dive, I want to pull back from the DNS records and the fallback logic for a second. We've covered a massive amount of technical ground today. How should you, the listener, contextualize all of this within the broader scope of running your agency? I would pose this to everyone listening. In our industry, we have a bad habit of treating email infrastructure as um an annoying IT chore. Oh, for sure. We treat DNS propagation and DKIM alignment as technical check boxes that get in the way of the real work of marketing. But what if we completely inverted that perspective? What do you mean? What if we started viewing DMARC alignment and dedicated sending domains as the absolute highest form of digital customer service? Wow. It reframes the entire purpose of the work. You aren't just configuring servers, you are fiercely protecting your client's ability to be heard. Exactly. If you aren't architecting this infrastructure, you are voluntarily handing your client relationships over to an algorithmic spam filter. You are letting Gmail's incinerator decide if a business gets to speak to its audience. Right. By mastering these protocols, you guarantee that the brand equity your client has built actually translates into inbox placement. You secure the final and most vulnerable mile of the marketing journey. You ensure the envelope arrives intact with the correct return address and the wax seal unbroken. That is the ultimate goal. Well, to everyone listening, thank you for joining us on this deep dive. You now have the operational blueprint to secure your infrastructure. And remember, before you jump into your client accounts to start auditing their DNS records, go check the show notes right below this deep dive. Yeah, don't miss out on that. That link for the free 30-day Go High Level trial is waiting for you. Double the standard length gives you a massive advantage. It provides the necessary breathing room to build out these dedicated subdomains, allow for that 48-hour DNS propagation, and thoroughly test your fallback headers without racing the clock. It's an absolute game-changer. Click the link, claim your 30 days, and stop letting algorithms dictate the success of your campaigns. We'll catch you on the next deep dive.