You send an invoice and the customer says it never arrived. It did arrive; it went to spam. If that keeps happening, your email probably has an authentication problem, and the fix is on your domain, not in the customer’s spam folder settings.
What mail providers actually check
When your message lands at Gmail or Outlook, the receiving server asks three questions about your domain. Each one has a technical name, but the questions themselves are plain.
SPF asks: is the server that sent this message allowed to send for this domain? Your domain publishes a list of approved senders in DNS. If the message came from a server that isn’t on the list, that’s a strike.
DKIM asks: was this message signed by the domain it claims to come from? A signature gets added when the mail is sent and checked against a public key in your DNS. No signature, or a broken one, is another strike.
DMARC ties the first two together. It asks whether the domain in the From line your customer sees actually matches the domain that passed SPF or DKIM, and it tells the receiver what to do when the answer is no: deliver anyway, quarantine, or reject. Without a DMARC record, providers fall back on guesswork, and their guesses have gotten less generous every year.
None of this measures whether your message reads like spam. A perfectly normal invoice from a misconfigured domain scores worse than a newsletter from a correct one.
The usual causes we find
Most of the broken setups we’ve fixed come down to a few patterns.
The most common one: the website sends mail directly from the web server. Contact form notifications, order confirmations, and invoices go out through the server’s own mail function, but the domain’s SPF record only lists the actual mail provider. The web server isn’t on the approved list, nothing signs the message, and every one of those emails starts its life with two strikes.
Second: the From address doesn’t match the account doing the sending. It’s common to send as noreply@yourdomain.com through an account that authenticates as somebody else. Some providers rewrite the From line when that happens; others deliver it with a mismatch that DMARC then flags. Either way the message stops looking like it comes from you.
Third: a setup that worked in one place quietly fails in another. Mail relays are often locked to a specific server’s IP address. Move the sending script to a new machine and the relay refuses you, or the mail goes out unauthenticated. We’ve hit this one in our own infrastructure: the same credentials that worked on the server were rejected from anywhere else, and the fix was switching to authenticated submission that works from any IP and gets signed for the domain.
What fixing it involves
The work is mostly in DNS and in how your site and tools send mail. We check what the domain publishes for SPF, DKIM, and DMARC, then check every place that actually sends mail as your domain: the mail provider, the website, invoicing tools, anything else. Each sender either gets onto the approved list and signed properly, or gets rerouted through one that is.
Then we send real test messages to the major providers and read the authentication results in the headers, because the headers say exactly which check failed and why. It isn’t guesswork, any more than finding out why a site is slow is. The usual outcome is a short list of DNS changes and one or two senders that need reconfiguring.
Deliverability is part of the hosting and site care we run for clients: it gets set up correctly at launch and checked whenever the mail setup changes.