Why your business email goes to spam — and the three records that fix it

You bought a domain, set up [email protected], sent a quote to a customer — and they never saw it. You call, and they find it in spam. Or worse: it isn't in spam either. It simply never arrived.

Nothing is broken. The mailbox works. What's missing is the part almost every setup skips.

The problem: anyone can claim to be you

Email was designed in the 1980s, when the internet ran on trust. Nothing in the original protocol stops a stranger from sending a message that says it comes from your address. That's why phishing works — and why the whole industry had to bolt authentication on afterwards.

So Gmail, Outlook and every other provider face a question on every message: is this really from who it says it's from?

If your domain gives them no way to answer, they guess. And when they guess about a domain that has no history and no proof, they guess conservatively. Your quote goes to spam, or gets dropped silently.

⚠️ Since February 2024, Google and Yahoo made this explicit: bulk senders must authenticate, or their mail is rejected outright. What used to be best practice is now the entry requirement.

The three records that answer the question

They're DNS records — text entries attached to your domain. Together they tell receiving servers what to trust.

SPF — who is allowed to send

SPF (Sender Policy Framework) is a list of the servers permitted to send email using your domain.

v=spf1 include:zoho.com ~all

That says: mail from my domain comes from Zoho's servers; treat anything else as suspicious. If a scammer sends from their own server pretending to be you, SPF fails and the receiver knows.

⚠️ The common mistake: you switch email providers and leave the old SPF record in place, or you add a second one. A domain can only have one SPF record. Two records means neither is valid — and everything starts failing at once, weeks after the change nobody connects it to.

DKIM — proof the message wasn't altered

DKIM (DomainKeys Identified Mail) signs each outgoing message cryptographically. Your provider holds a private key; the matching public key sits in your DNS. The receiving server checks the signature.

If it matches, two things are proven: the message really came from your domain, and nobody edited it in transit.

⚠️ The common mistake: the provider gives you the DKIM record, but it's long and gets pasted in wrong — a truncated key, a broken line, a missing character. It looks configured. It fails silently.

DMARC — what to do when the first two fail

SPF and DKIM detect a forgery. DMARC tells the receiver what to do about it.

v=DMARC1; p=quarantine; rua=mailto:[email protected]

Three policies:

• p=none — do nothing, just send me reports. Where you start.
• p=quarantine — put suspicious mail in spam.
• p=reject — refuse it outright.

⚠️ And this is the one almost nobody gets right: alignment. SPF and DKIM can both technically "pass" while still failing DMARC, because the domain they authenticated isn't the domain in your From: line. Everything looks green in a checker, and your mail still lands in spam. You only see it by reading the raw message headers.

Why "it worked yesterday" is a trap

Deliverability isn't a switch. It's a reputation, and it decays.

• A new domain has no history. No amount of DNS configuration fixes that — receivers need to see you send normal mail, in modest volume, over weeks. Anyone who promises instant inbox placement on a fresh domain is selling something.
• One bad send poisons the well. Mail a purchased list once and the complaints follow your domain for months.
• Providers change the rules. The February 2024 requirements landed on thousands of businesses whose email had "always worked".

What we actually do about it

We're not reselling you a mailbox — you can buy one for about twelve dollars a year, and we'll tell you which one. What we do is the part that decides whether it works:

• Configure SPF, DKIM and DMARC, and verify they pass alignment — not just that the records exist
• Set DMARC to p=none first, read the reports, and tighten it once we can see nothing legitimate is being caught
• Make sure your reply-to address actually receives mail (an address that bounces everything is a negative signal in itself)
• Watch it afterwards, because a DNS change six months from now can undo all of it silently

⛔ What we won't promise: that every message reaches the inbox. Gmail and Microsoft decide that, and nobody can guarantee it. What we can do is remove every reason for them to say no — and tell you honestly when the answer is "your domain is new, this needs a few weeks" rather than billing you to chase it.

See how we handle email as part of managed hosting →