Why emails from your website land in spam: SPF, DKIM, DMARC and MX in plain English

A customer pays for an order and waits for the confirmation. It never arrives. Neither does the invoice. A week later they find it in spam, or they never find it and call you to ask whether the order went through. Your website works perfectly. The problem is the email, or more precisely four records in your domain settings that most website owners have never heard of: MX, SPF, DKIM and DMARC.

This article explains them without jargon, shows what we found in them on websites and online shops we look after, and gives you a simple way to check your own domain.

Signs that your website's emails are not getting through

The website itself reports no error. The order is saved, the payment goes through, the form says thank you. Only the email gets lost, and it happens silently. Typical signs:

• Customers write or call because the order confirmation or invoice never arrived. Often they later find it in spam.
• A customer says they replied to your email, but there is nothing in your inbox.
• Messages from the contact form arrive only sometimes, or the customer never gets the automatic reply.
• Someone received an email “from you” that you never sent, typically a fake invoice with a different bank account number.

The last one is the most dangerous. Without the right domain setup, anyone can send an email with your address as the sender, and the receiving server has no way to tell it is forged.

MX, SPF, DKIM and DMARC in plain English

All four are short lines of text in your domain's DNS. DNS is the public directory the rest of the internet uses to look up where your website and your email live. They are not settings in your mailbox or your shop, which is why nobody tends to deal with them when a website goes live.

MX: where email for your domain is delivered

The MX record tells other mail servers where to deliver email sent to your address. When a customer replies to info@yourcompany.com, their server looks up your MX record first and sends the message there. If MX points to a server where your mailbox does not live, the reply goes somewhere else and you never hear about it.

SPF: who may send email for your domain

SPF is a list of servers allowed to send email using your domain. The receiving server compares where the message came from with that list. If the service your shop, invoicing software or newsletter sends through is missing from it, those messages look suspicious.

DKIM: a signature that proves the message is genuine

DKIM is a digital signature the sending server attaches to every message. The receiving server finds the public half of the key in your domain's DNS and uses it to confirm that the message came from someone in control of your domain and that nobody changed it on the way. The signature usually survives forwarding too, which is why it carries the most weight.

DMARC: what to do with a message that fails

DMARC ties SPF and DKIM together and adds a rule. It tells receiving servers: treat an email with my domain in the From address as genuine only if it passed SPF or DKIM for my domain. If it did not, here is what to do with it: nothing, just let me know (p=none), put it in spam (p=quarantine), or reject it outright (p=reject). Servers also send you summary reports showing everyone who sends email in your domain's name.

Why you can no longer skip this

Google and Yahoo tightened their rules for senders from February 2024. Anyone sending to Gmail must have at least SPF or DKIM set up. Anyone sending more than 5,000 messages a day to Gmail needs SPF, DKIM and DMARC. Gmail may send messages that break the rules to spam or reject them outright.

A small online shop will not reach 5,000 messages a day, but the first rule applies to it too. And an order confirmation is exactly the kind of email a customer is waiting for and notices at once when it goes missing.

What we found on websites we look after

The four situations below are not made-up examples. We recently found and fixed them on our own hosting, on websites and shops we take care of. The domain names are left out because they would not change the point.

Replies to info@ went somewhere else

The website and the mailbox both ran on our server, but the domain's MX record still pointed to the hosting provider's shared mail server. Sending from the website worked, so nobody noticed. Customers' replies to info@, however, never reached the mailbox the owner actually read. The fix was one line in DNS.

A shop sent confirmations and invoices unsigned

Order confirmations with the terms and conditions attached as a PDF, and invoices sent after payment, all went out without a DKIM signature. The server tried to sign them, but the key it needed had never been created. We created the key in the hosting control panel, and the panel wrote the DKIM record straight into the hosting provider's DNS. That was not the end of it. The domain actually used DNS at Cloudflare, so nobody in the world ever read the record at the hosting provider. The signature only started to count once we copied the same record to Cloudflare.

That is the most important lesson in this article: a record only counts in the DNS your domain really points to, not in whichever control panel happens to be at hand.

DMARC was missing almost everywhere

Most domains had no DMARC at all. The domain told nobody what to do with forged messages, and the owner never learned that someone was impersonating them. The safe start is p=none: email flows as before and receiving servers send reports. Once the reports show that all genuine messages pass, the domain moves to p=quarantine and later to p=reject.

Why fixing SPF alone is not enough

Every email has two senders. One is the address you see in your inbox. The other is written on the envelope, and undeliverable messages bounce back to it. For emails sent by websites, our mail server rewrites that envelope address to its own (the technique is called SRS). SPF checks the envelope, so for these messages it verifies the server's domain, not yours. DMARC can then pass only through your domain's DKIM signature. That is why fixing SPF alone does not help: without the signature, emails from your website will not pass DMARC.

How to check your domain yourself

You do not need access to the server. A Gmail account and a few minutes are enough.

1. Send yourself a test email from the website. Place a test order, register an account or submit the form, using your Gmail address.
2. Open the original message. In Gmail, open the email, click the three dots in the top right corner and choose Show original.
3. Check the three lines at the top. You want PASS for SPF, DKIM and DMARC. For DKIM, also look at the domain the signature passed with. It should be your domain, not the domain of your hosting provider or platform.
4. Find out where your DNS really is. The domain's name servers (the NS record) decide this. You can see them at your domain registrar or in any online DNS lookup tool. If they end in cloudflare.com, every record belongs in Cloudflare, whatever your hosting control panel shows.
5. Check MX. In the same tool, make sure MX points to the server holding the mailbox you actually read. Then send an email to info@ from another address and see whether it arrives.
6. Look for DMARC. Look for a TXT record at _dmarc.yourcompany.com. If there is none, you have no DMARC.

When to get help

The check takes a few minutes, the fix needs more care. One wrong line in SPF, or a strict DMARC policy set too early, can stop email that works today. The records also have to match across your hosting, your DNS and every service that sends email on your behalf, from the shop to your invoicing software to your newsletter.

If Gmail does not show you PASS three times, or you are not sure where your DNS lives, get in touch. When we take a website into our website maintenance, we go through the domain and email as well: MX, SPF, DKIM, DMARC and where the domain really points. If the website was built by a supplier who no longer looks after it, we start with a website takeover.