Cases and lessons

The dashboard says “sent”: why your email campaigns go to spam

A company reached out because their campaigns had stopped working. The problem wasn't the platform or the content: their domain authorized the mailbox provider's servers, but never the campaign system's.

When the dashboard says sent, it only means the platform accepted the email, not that anyone received it. Campaigns go out from a different server than your company email, and if your domain doesn't authorize it with SPF, DKIM and DMARC, the recipient's mailbox sends it to spam without telling anyone.

A client told us their email campaigns had stopped working. The first thing they sent us was an email from Microsoft that had scared them, with words like *DMARC* and *authentication failed*.

That email wasn't the problem. It was an automated report, and in fact it was the tool that ended up explaining everything.

The real problem was something else, and it had been there for years.

Your company email and your campaigns don't come from the same place

This is the part almost nobody knows, and it's where things break.

When you set up your company email, your domain authorizes that provider's servers to send on your behalf. So far, so good.

But the campaign platform —the one you use to send updates to your contact list— sends from completely different servers, even if it's the same provider and even if your own address shows up on the screen.

And those servers weren't authorized. They never had been.

So every campaign went out claiming to come from a company that, technically, didn't recognize it as its own.

Why it broke right now

For years this went unnoticed. The campaigns went out, some arrived, others landed in spam, and nobody connected the dots.

What changed was that we cleaned up the domain's authentication. And publishing that configuration has an effect worth understanding: it tells Gmail, Outlook and Yahoo that the domain authenticates its email, and tells them what to do with anything that isn't authorized. Depending on the policy you publish, that ranges from "just let me know" to "reject it without delivering it" — and the stricter it is, the harder they filter.

We didn't break something that worked. We turned the light on something that had been broken all along.

For the client the effect was the same: it worked, and after we touched it, it stopped working. That's a conversation you have to have head-on, with the data in plain view.

What we forgot to ask

Here's the lesson, and it's uncomfortable because the mistake was ours.

When you clean up a domain's email, the first thing you do is take inventory of who sends on its behalf. We did that right: we reviewed the domain's records, the website's code, the hosting configuration. We found three senders and documented them.

One was missing. And it was missing because that inventory can be built entirely by looking at the technical side, and only the client knew about the fourth sender.

Nobody asked: *do you send campaigns or updates to your customers?*

An inventory built only from technical evidence can't find the sender that lives in someone's head. Since then that question is on the list, and it comes before any record.

How to tell if this is happening to you

Three questions, and you can answer them on your own:

  • Do you send campaigns or updates from a platform? If the answer is yes, keep going.
  • On that platform, does your domain show as verified? It's usually in a domain authentication or senders section. If something is in red, that's it.
  • Are your campaigns getting far fewer opens than before, or almost none? A sharp drop in opens with no change in content is usually deliverability, not interest.

And one direct check, which is the one that counts: send a test campaign to a Gmail account, open it, go to *Show original* and look for the Authentication-Results block. The line that matters is dmarc, and it has to say pass.

Watch out for a very common confusion: all three don't need to pass. DMARC passes if spf or dkim passes, as long as the one that passes is aligned with your domain. An email with spf=fail and dkim=pass can be perfectly fine — that's what happens, for example, every time someone forwards your message.

If dmarc says fail, your campaigns are going out without proving who you are.

What doesn't recover on its own

An honest warning for when you fix it: reputation takes time.

If you'd been sending unauthenticated email for months, providers have already learned to distrust your domain. Fixing the configuration is a matter of hours; getting Gmail to trust you again takes several campaigns.

Don't expect the first one after the fix to take off. Look at the trend in the second and third.

Do you send campaigns and don't know if they arrive?

We'll check it. A short check shows whether your domain is authorizing whoever sends on your behalf, and what's missing for your email to land where it should.

The diagnosis is free. We'll be in touch soon.

We solve this in Your technology department →