VisibilityRoom_EP05_Deliverability_featured_1200x628

When Your Leads Land in Spam: SPF, DKIM, DMARC and the Form-to-Inbox Black Hole

What you'll take away

  • Website forms send mail "as" your domain from your web host's server. Without authentication records, that looks exactly like a scam.
  • SPF is a permission list of servers. DKIM is a signature proving the message is authentic and untampered. DMARC sets what happens when those checks fail — and sends you reports.
  • Roll out DMARC in order: none, then quarantine, then reject. Skipping to reject breaks your own mail.
  • Email forwarding breaks authentication on the second hop. Give staff access to a shared mailbox instead of relaying copies out.
  • A lookalike email from your own address is spoofing, not a breach. It needs no access to your systems, and the same three records are the defence.
  • Marketing email and business email share one domain reputation. Send campaigns from a subdomain and clean the list.
  • The Promotions tab is not spam — it's filing. Lead notifications land there because they're formatted like newsletters. Strip the branding.
  • The real fix: form submissions should write to a CRM first and send an email second, so a filtered message doesn't lose the lead.

---

Transcript

Marcus: Welcome to The Visibility Room. I'm Marcus — I work on website and email deliverability at Mediaforce, and this is episode five. Today we're getting into something that quietly costs businesses real money, and almost nobody catches it: when your leads land in spam. The form-to-inbox black hole. My guest is Danielle, who's operations director for a multi-location fitness business in Toronto, and she's been in the industry fifteen years. Danielle, welcome.

Danielle: Thanks, Marcus. Happy to be here.

Marcus: So you found something last month that I think is going to make a few people listening go check their junk folder.

Danielle: Yeah. So — we thought our January was soft. Down on trial sign-ups, nobody could explain it. And then one of our managers is cleaning out her junk folder and there's, I don't know, thirty-some website inquiries sitting in there. Going back weeks.

Marcus: Real people.

Danielle: Real people. With phone numbers. Who had asked us to contact them, and we just — didn't.

Marcus: And the marketing looked fine the whole time.

Danielle: The marketing looked great! The ads were working. The form was working. The leads were arriving. They were just arriving somewhere nobody was looking.

Marcus: That's the thing that makes this one so nasty. Every dashboard in the chain says success. The failure happens after the last thing anybody measures.

Why do website form submissions go to spam?

Danielle: So why does it even happen? These are emails from my own website, to my own staff. How is that suspicious?

Marcus: Because of how website forms actually send mail, and this is the part nobody explains. When somebody fills out your form, your website builds an email and sends it from your web host's server. But it puts your domain in the "from" line, because that's what looks tidy. So a server that has nothing to do with your email provider is sending mail claiming to be you.

Danielle: And the receiving side sees that and goes—

Marcus: And goes, hang on. Somebody's claiming to be this company, from a machine that isn't theirs. That's the exact pattern a scammer uses. So unless you've published records that say "this server is allowed to send on my behalf," the safest thing for the receiver to do is quarantine it.

Danielle: Which is the "unverified" thing we were seeing.

Marcus: That's the label some providers put on it, yeah.

What are SPF, DKIM and DMARC?

Danielle: Okay. So the records. Somebody said SPF, DKIM, DMARC at me once and I nodded and did nothing about it.

Marcus: Universal experience. They're three text records that live with your domain, and each one answers a different question. Take them one at a time.

Danielle: Please.

Marcus: SPF answers: which servers am I allowing to send email using my domain name? It's a list. Your email provider, your website host, your booking software, whatever sends on your behalf. If a message shows up from a server that isn't on the list, that's a flag.

Danielle: That's a permission list.

Marcus: Permission list. DKIM answers a different question: was this message actually sent by an authorized system, and did anybody tamper with it on the way? It works by adding an invisible signature to every message, which the receiver checks against a key published with your domain. If the signature matches, the message is authentic and untouched.

Danielle: So one's a guest list and one's a signature.

Marcus: That's a good way to hold it. And DMARC is the third piece — it answers: what should a receiver do when a message fails those checks? Reject it? Put it in junk? Let it through and just tell me about it? DMARC is where you set the policy, and it's also where you get reports back about who's sending mail as you.

Danielle: Wait, you get reports?

Marcus: You do, and almost nobody reads them. Once DMARC's turned on, you start receiving summaries of every system sending mail with your domain on it. That's how you find out your old booking platform is still sending as you, or that somebody actually is impersonating you.

DMARC policy: none, quarantine or reject?

Danielle: Okay, so what should our policy be?

Marcus: There's a proper order, and skipping it is how people break their own email. Start at "none," which means don't block anything, just send me the reports. Run that for a few weeks and read what comes back, because you will find legitimate systems you'd forgotten about.

Danielle: Like our old scheduling tool.

Marcus: Exactly like that. Then once everything legitimate is authorized, move to "quarantine" — failures go to junk. And eventually "reject," which means failures don't get delivered at all.

Danielle: And if we skipped to reject on day one?

Marcus: You'd stop your own class reminders from being delivered and spend a very unpleasant Monday finding out why.

Danielle: Noted.

Marcus: It's a common mistake. Someone reads an article, sets it to reject, and it works fine for the main email system and silently kills everything else.

How do you check if your domain has SPF, DKIM and DMARC?

Danielle: Can I check whether we've got any of this without calling a developer?

Marcus: Yeah, two ways, both free. There are checker tools online where you type your domain and it shows you which records exist and whether they're valid. Or the manual version — take an email your system actually sent, open it, and look at the original message details. Most mail apps will let you view the raw headers, and you'll see pass or fail written next to each check.

Danielle: And if it says fail?

Marcus: Then you've found your January.

Why does email forwarding break SPF and DMARC?

Danielle: Can I throw one more thing at you? Because we do something at every location that I now suspect is a problem.

Marcus: Go.

Danielle: Each location has an info address, and every one of those just forwards to whoever the manager is. Some of them forward to personal accounts.

Marcus: Yeah. Okay, so forwarding is one of the quiet ways this breaks, and almost nobody knows about it.

Danielle: Of course it is.

Marcus: Here's what happens. A message arrives at your info address, passes all its checks, everything's fine. Then your system forwards it on. But now it's being re-sent from your server, while still carrying the original sender's address in the "from" line.

Danielle: So the forwarded copy looks like the thing you described at the start.

Marcus: It looks exactly like the thing I described at the start. The permission check fails on the second hop, because your server was never authorized to send as that original sender. So a perfectly legitimate email gets flagged after you forwarded it to yourself.

Danielle: That's infuriating.

Marcus: It's a genuinely annoying piece of design. There are technical ways around it, but the practical answer for a business your size is to stop forwarding. Give managers real access to a shared mailbox instead of relaying copies out to personal accounts. It's cleaner, it survives staff turnover, and you stop mangling your own mail on the way in.

Danielle: So that's an operations fix, not a technical one.

Marcus: Most of them are, honestly.

Danielle: Yeah. Okay, related thing, and this one scared me more. We got an email that appeared to come from our own domain. Looked like it was from one of our owners. Asking a manager to buy gift cards.

Marcus: Classic.

Is a lookalike email from your own domain a hack?

Danielle: So — were we hacked?

Marcus: Almost certainly not, and this is the myth I'd most want to clear up, because the panic response to it is expensive and unnecessary. Spoofing is not a breach. Anyone can write any name and any address in the "from" field of an email — it's like writing a fake return address on an envelope. It requires no access to your systems, no password, nothing. It looks terrifying and it's happening entirely from the outside.

Danielle: So how do I tell the difference between that and an actual breach?

Marcus: The tell is whether the message is really coming from your systems, and the headers show that — you'd see the authentication checks failing. A genuine compromise looks different: mail actually sent from your account, showing in your sent folder, logins from places nobody's been, rules quietly forwarding messages elsewhere. Different problem, different response.

Danielle: And the fix for the spoofing is the same three records.

Marcus: The same three records. That's why this is worth doing even if your leads are arriving fine. Those records are simultaneously your delivery insurance and your impersonation defence. Same work, two problems.

What is email sender reputation?

Danielle: Alright. Say the records are all correct. Can leads still end up in junk?

Marcus: Yes, and this is where it gets less technical and more behavioural. The records prove you're you. They don't prove you're welcome. There's a second layer, which is your sending reputation.

Danielle: Meaning?

Marcus: Meaning receiving systems keep a running score on your domain. Are people opening your mail or deleting it unread? Are you sending to addresses that don't exist? Is anyone hitting the spam button? That score follows your domain around, and it doesn't care whether a particular message was a class reminder or a genuine lead.

Can marketing email hurt your lead notifications?

Danielle: Oh. So our newsletter could be hurting our lead emails.

Marcus: It absolutely can, and for a business like yours that's the single biggest one. You're sending a lot of marketing — promos, challenges, win-back campaigns to people who cancelled two years ago. If enough of those get marked as spam, your whole domain's reputation drops, and then the email that says "Danielle, someone wants a trial" gets treated with the same suspicion.

Danielle: That is genuinely upsetting.

Marcus: It's fixable, though.

Danielle: How?

Marcus: Separate them. Send your marketing from a subdomain — something like news.yourdomain.com — and keep your real business mail on the main domain. They build separate reputations. If a big campaign goes badly, it doesn't drag your inbox down with it. And clean the list: stop mailing people who haven't opened anything in a year. It feels like giving up on them. It's actually protecting everyone else's delivery.

Danielle: My marketing coordinator will hate that. She measures list size.

Marcus: List size is a vanity number. Fifteen thousand people where a third are dead addresses will deliver worse than eight thousand engaged ones, and the eight thousand will produce more revenue.

Why do emails land in the Promotions tab instead of the inbox?

Danielle: Quick one — Promotions tab. Half our stuff lands there. Is that the same problem?

Marcus: Different problem, and it's worth knowing the difference because people panic about it unnecessarily. The Promotions tab isn't a punishment. It's a sorting decision — the provider has looked at a message and decided it's marketing rather than correspondence. It was delivered. It's in the inbox. It's just been filed.

Danielle: So it's not spam.

Marcus: Not spam. And for an actual promotional email, landing in Promotions is arguably correct — people go to that tab when they're in a buying mood. Fighting it usually isn't worth the effort.

Danielle: But our lead notifications go there too sometimes.

Marcus: That's the part worth fixing, and it's usually the shape of the message rather than anything sinister. Heavy formatting, a lot of images, tracking links, a template that looks like a campaign — all of that reads as marketing. A lead notification should look like a person wrote it. Plain text, short, the person's name and number, one link.

Danielle: Ours has our logo and a header banner on it.

Marcus: Then it looks like a newsletter, and it's being filed like one. Strip it. Nobody on your team needs branding on an internal notification.

What does CASL require for Canadian businesses?

Danielle: What about the anti-spam rules? We're Canadian, and I know there's a law, I just don't know the details.

Marcus: Right, Canada's anti-spam legislation. You'll see it written CASL. And the short version — talk to someone who knows your specific setup for anything serious — is that it's consent-based. You need permission to send commercial messages, either explicit permission somebody gave you, or implied permission from an existing relationship that expires after a period. Every message needs to identify who you are and have a working unsubscribe.

Danielle: And that ties back to the reputation thing?

Marcus: Directly. If people don't remember opting in, they hit spam instead of unsubscribe, and now you've got a legal exposure and a deliverability problem from the same list. Good consent practice and good deliverability are the same practice.

What do filtered leads actually cost?

Danielle: Okay. Give me the arithmetic, because I need to explain this internally.

Marcus: Sure. Say you get two hundred inquiries a month across your locations. If eight per cent are being filtered — and eight is a modest guess for a domain with no authentication — that's sixteen people a month you never see. If one in four of those would have joined, that's four memberships.

Danielle: Four a month.

Marcus: Four a month. At a hundred dollars a month for, say, an average of a year, that's about forty-eight hundred dollars in annual value. Every month, compounding, with nothing in any report telling you it's happening. And the fix is somebody spending an hour with your domain settings.

Danielle: Right.

Marcus: And I'd add one more thing, which is the actual long-term answer.

Danielle: Go on.

Marcus: Stop letting email be the only place a lead exists. A form submission should write into a system — a CRM — first, and send an email second as a notification. Then if the email gets filtered, the lead is still sitting in a list somebody works through. Right now your entire lead pipeline depends on a message not being misfiled, and that's a fragile way to run a business.

Danielle: That's the real fix, isn't it.

Marcus: That's the real fix. The authentication records stop the bleeding. The CRM means the wound doesn't matter as much next time.

What to check first

Danielle: Alright. This week.

Marcus: Three things, and you can do the first one before lunch. Go to your own website on your phone, fill out your own contact form using a personal address — a Gmail or an Outlook one, not a work address — and watch where it lands. Inbox, promotions tab, junk. That's your answer.

Danielle: And if it's junk?

Marcus: Then run your domain through a free record checker and see what's missing. That's number two. Number three — ask every location manager to search their junk folder for the last sixty days and pull out anything real. You may have thirty conversations sitting there right now.

Danielle: I know exactly how many we had.

Marcus: Right. Danielle, thank you — this was a good one.

Danielle: Thanks, Marcus.

Marcus: And that's episode five of The Visibility Room. Thanks for spending some time with us — we'll see you next time.

Read More