My messages to clients land as "phishing" or don't arrive at all — why?

You send an offer, an invoice or a booking confirmation — and the client tells you they never got it. Or, worse, they say it landed straight in Spam with a red "phishing" warning. It's frustrating, especially when it's your own name and your own business on the line.

The good news: it's almost never your fault or the client's. It's a technical email-authentication problem, and Gmail, Yahoo and Outlook have become much stricter about it. In short, if their servers can't verify who's really sending the message, they treat it as suspicious. In this article I'll explain clearly, without needless jargon, what's happening and how to fix it with three settings: SPF, DKIM and DMARC.

Why legitimate emails end up in Spam

When you send an email, the recipient's server (Gmail, say) quietly asks three questions: "Is this server actually allowed to send on behalf of this domain? Was the message altered in transit? What does the domain owner want me to do if something doesn't check out?"

If your domain has no answers configured, the server hears silence. And in the world of email, silence means suspicion.

The most common reasons you land in Spam or get blocked:

• You send from your own domain (name@company.com) but through another service (site form, newsletter, CRM) that isn't authorized.
• You have no SPF, DKIM or DMARC set up at all.
• Your address sits on cheap hosting with a bad reputation, shared with spammers.
• The message text resembles phishing patterns (shortened link, "urgent", odd attachment).

SPF, DKIM, DMARC — in plain language

Think of the three as your email's ID papers. You don't need to understand them technically, but it helps to know what each does:

• SPF (Sender Policy Framework) is the list of servers allowed to send on behalf of your domain. It's like a guest list at the door: if the server isn't on it, it's suspect.

• DKIM (DomainKeys Identified Mail) is a digital signature attached to every message. It proves the email really comes from you and that nobody tampered with it in transit — like a seal on an envelope.

• DMARC is the rule that tells servers what to do if SPF or DKIM fail: let the message through, send it to Spam, or reject it. DMARC can also send you reports so you can see who's sending in your name — including any impostors.

All three are added as DNS records on your domain. Nothing gets installed on your computer.

How to check whether you have a problem

Before changing anything, it's worth seeing exactly what's broken. You can do this yourself in a few minutes:

• Send an email from your address to a personal Gmail account. Open the message, click the three dots and choose "Show original." There you'll see in black and white whether SPF, DKIM and DMARC show "PASS" or "FAIL."

• Search online for a free "DMARC checker," enter your domain, and see what records you already have.

If you see "FAIL" or "none" on any of them, that's your problem. The most common scenario for local businesses: email from your own account (Google Workspace, for example) is fine, but messages sent through the website or the booking platform fail — because that service isn't listed in SPF.

How to fix it, step by step

The fix happens at the DNS level, at the company where you bought your domain (or your hosting). The order matters:

• SPF first: add a single TXT record that lists every service allowed to send for you (your mailbox, the website, the newsletter). Note: a domain is allowed only one SPF record — you combine everything into it.

• DKIM next: enable it from your email provider's panel (Google, Microsoft, Zoho), which gives you a key to add to DNS.

• DMARC last: start gently with a "none" policy, just to receive reports and confirm everything is green. Once you're sure, move gradually to "quarantine" and then "reject."

DNS changes can propagate within a few hours. Don't rush DMARC to "reject" — if you still have an unconfigured service, you can block your own real emails.

When it's worth asking for help

If you look at DNS records and it reads like a foreign language, that's completely normal — a single misplaced comma in SPF can break sending for the entire domain. This isn't where you want to experiment blindly, especially if invoices and offers go out from that inbox.

At MPO Web Studio we configure SPF, DKIM and DMARC as part of delivering a website, fully remotely — you don't have to hand us passwords anywhere; we tell you exactly which records to add, or we add them together on a call. We also check what's already sending in your name, so nothing is left out.

If you'd like a hand, or just a quick diagnosis, message us on WhatsApp. We'll tell you honestly whether there's something to fix or whether you're already in good shape.