A client emailed me last week to say he never got the password reset for his own website. I resent it. He never got that one either.
It was in his junk folder. Both of them were. And the reason is worth understanding, because it was not a mistake by his email provider or ours. His own domain had instructed Gmail to treat that message as suspicious, and Gmail did exactly as it was told.
This is the most common email problem I see with small businesses, and it almost never announces itself. Nothing bounces. Nothing errors. Your messages simply stop arriving, and you find out weeks later when somebody mentions they never heard back.
Your website sends email as you, and that is the problem
Most business websites send mail. Contact form notifications, order confirmations, password resets, appointment reminders. All of it goes out with your domain in the from line.
But it is not sent by your email provider. It is sent by your web server, which is a completely different machine in a completely different place. As far as the receiving mail system is concerned, some server it has never heard of is claiming to be you.
That is exactly what a phishing attack looks like. So the entire system of email authentication exists to answer one question: is this sender actually allowed to use this domain name?
Four records answer it. They build on each other, and the order matters.
SPF: the list of who is allowed to send
SPF is a published list of the servers permitted to send email using your domain. It lives in your DNS, the address book records attached to your domain name, and anyone can read it.
A typical one names your email provider and anything else that legitimately sends on your behalf: your mailing list platform, your invoicing software, your website.
Two things go wrong with SPF regularly.
The first is that somebody adds a new tool and forgets the record. Your new newsletter platform starts sending, is not on the list, and its messages are treated as forgeries.
The second is subtler and catches people who think they have fixed it. Listing your web server’s address in SPF is not enough on its own. Passing the check and passing it in a way that counts are different things, and that difference is what DMARC cares about. More on that shortly.
DKIM: a signature that proves nothing was altered
DKIM adds a cryptographic signature to every message you send. The receiving server checks that signature against a key published in your DNS.
Where SPF says “this server is allowed to send for us,” DKIM says “this specific message genuinely came from us and has not been tampered with in transit.”
Google Workspace and Microsoft 365 both do this for you, but on Workspace it is not always switched on by default. It is worth checking rather than assuming, because it is the stronger of the two signals and the one that survives message forwarding.
Here is the piece almost nobody realises: your website’s mail is usually not signed at all. WordPress sending through the server’s built-in mail function has no DKIM key and no way to sign anything. So your form notifications arrive with one authentication signal missing before they have even been read.
DMARC: the instruction for what to do when the first two fail
SPF and DKIM are checks. DMARC is the policy that says what should happen when a message fails them, and it is the record that turns a quiet warning into a real consequence.
It has three settings. None means take no action, just report. Quarantine means put it in junk. Reject means refuse it entirely.
This is what happened to my client. His domain was set to quarantine. His website sent a password reset. The message could not prove it was authorised, so Gmail put it in junk, precisely as his own domain had asked.
Now the subtle part I promised earlier. DMARC does not simply ask whether SPF passed. It asks whether it passed for your domain specifically. A web server can be listed in your SPF record and still fail, because the technical sender address it uses behind the scenes belongs to the hosting company rather than to you. The check passes. The alignment does not. The message goes to junk anyway.
This is why adding your server’s address to SPF often does not fix the problem, and why people conclude email authentication is black magic.
The actual fix is to stop having your website send mail directly. Route it through your email provider using authenticated sending, or through a dedicated service. Then it is signed, it is aligned, and it arrives.
BIMI: your logo in the inbox, and why you probably should not bother yet
BIMI is the newest of the four. It displays your logo next to your messages in supporting inboxes, which looks great and is a genuine trust signal.
It is also the one I most often talk clients out of, at least for now.
To display anything in Gmail or Apple Mail you need a Verified Mark Certificate, and to get one you generally need a registered trademark for your logo. Registration takes eight to twelve months. There is an alternative certificate for logos without a trademark, but it requires roughly a year of documented prior use. Either route runs about a thousand dollars a year.
Publish the record without a certificate and nothing displays at all.
The logo file itself is fussy too, a specific flavour of SVG with a square canvas and no scripts. Fixable in an afternoon. The certificate is the real gate.
The practical takeaway: BIMI is cosmetic. If your messages are landing in junk, that is functional. Fix the functional problem first, and revisit the logo when your trademark exists anyway.
What to actually do
In order, because each step depends on the one before it.
- Write down every system that sends email with your domain on it. The website, the newsletter tool, the booking system, the invoicing software. Most businesses find more than they expected.
- Check that SPF lists all of them, and DKIM is switched on with your email provider.
- Set DMARC to none first and read the reports for a few weeks. It tells you what is failing before you start rejecting anything.
- Fix what the reports show, then tighten to quarantine.
- Route your website’s mail through authenticated sending rather than letting the server send it raw.
The step people skip is the third one, and it is the one that prevents the disaster. Going straight to quarantine or reject without reading the reports first is how businesses discover, live, that their invoicing system was never in the SPF record.
If you want a five minute version of this: send yourself a message through your own website’s contact form, from an address on a different provider, and see where it lands. If it goes to junk, everything above applies to you.