The problem is proof, not content
Anyone can send an email claiming to be from your domain. Nothing in the email protocol prevents it — that is how phishing works, and it is why receiving mail servers are suspicious by default.
So a receiving server asks a question before it decides where to put your message: can this domain prove it authorised this email? If the answer is no, the message is not necessarily rejected, but it starts with a heavy penalty. Add anything else slightly unusual and it lands in junk.
Three DNS records answer that question. They are free, they live at your domain registrar or DNS host, and most small businesses have none of them.
SPF: which servers may send for you
SPF is a list, published in your DNS, of the servers allowed to send email using your domain. A receiving server looks up that list, checks whether the message arrived from one of them, and treats it accordingly.
The part people get wrong: the list must include every system that sends as you. Your mailbox provider, yes — but also your website’s contact form, your invoicing software, your newsletter tool and your booking system. Each one that is missing is a source of mail that quietly fails.
Two practical warnings. SPF has a hard limit on how many lookups it may trigger, and stacking up services will silently break the whole record once you exceed it — at which point everything starts failing, including the mail that used to work. And you may only have one SPF record per domain; two records is not additive, it is an error. Adding a service means editing the existing record, never publishing a second one.
DKIM: a signature that proves nothing was altered
DKIM adds a cryptographic signature to each message. Your sending service holds a private key; a matching public key is published in your DNS. The receiving server uses the public key to confirm the message really came from an authorised sender and was not modified along the way.
Where SPF vouches for the route, DKIM vouches for the message. That is why it survives forwarding better: if a mailing list forwards your message, SPF often breaks because the forwarding server is not on your list, while a DKIM signature still validates.
Each sending service gives you its own DKIM record to publish. There is no universal value, no generic string you can copy from an article, and you must take the exact values from the provider you actually use.
DMARC: what to do when the first two fail
SPF and DKIM produce a result. DMARC tells the receiving server what to do with it, and — the genuinely useful part — asks for reports.
A DMARC policy can say “take no action, just tell me”, “treat failures as suspicious”, or “reject failures outright”. You should not start at reject. Start in the monitoring mode, read the reports for a few weeks, and you will discover the systems sending as you that you had forgotten about. That discovery is the point. Only once every legitimate sender passes should you tighten the policy, because turning on reject while a legitimate system still fails means your own invoices stop being delivered.
DMARC also checks alignment: the domain shown in the From field has to relate to the domain that passed SPF or DKIM. This is what stops someone passing SPF for a domain they control while displaying yours in the From line.
The specific problem with website email
This is the one that bites businesses whose ordinary mail is fine.
A website that sends enquiry notifications — the “new enquiry from your contact form” message — usually sends them from the web server, not from your mailbox provider. If it sends as you@yourdomain.com from a server that is not in your SPF record and cannot sign with DKIM, it fails every check, and the messages you most need to receive are the ones most likely to be junked.
There are two honest fixes. Either route the website’s mail through a proper sending service, so it is authenticated like everything else, or accept it and make sure the enquiry is stored on the site regardless of whether the email arrives. The second is worth doing anyway — an enquiry that exists only in an email is an enquiry you can lose. On this site, every submission is stored before any email is attempted, precisely so a mail failure can never lose a lead.
Things that are blamed and are rarely the cause
- Specific “spam trigger words”. Filters have been far more sophisticated than keyword lists for many years. Writing “free” does not send you to junk; failing authentication does.
- Too many images. A sensible ratio of text to images is good practice, but it is a minor signal next to a failing SPF check.
- The subject line. Worth improving for open rates. Not why the message was filtered.
- Sending too often. This matters for bulk marketing where recipients mark you as spam, which genuinely damages reputation. It is not why one invoice to one client was junked.
How to check where you stand
You do not need a tool to start. Send an email from your domain to an address you control at a large free provider, open the received message and use the provider’s “show original” or “view source” option. You will see three lines reporting SPF, DKIM and DMARC as pass or fail. That is the receiving server’s own verdict on your domain, and it is the fastest honest answer available.
If any of them says fail, that is your explanation, and the fix is a DNS change rather than a rewrite of your copy.
A note on the actual values
I have deliberately not printed example records here. SPF entries and DKIM keys are specific to the provider you send through, and copying a record from an article is how people break working email. Your mailbox provider and each sending service publish the exact values for their own system; use those, change one record at a time, and check after each change.
If your enquiry replies are landing in junk and you would like someone to work out which part is failing, send me a message and I will take a look.