The problem in one paragraph
Email was designed without authentication. Anyone can send a message claiming to be from your domain, which is why phishing works. To cope, receiving mail servers now look for cryptographic proof that a message is genuinely authorised by the domain it claims to come from.
That proof comes from three DNS records: SPF, DKIM and DMARC. If they are missing or wrong, your mail is not rejected outright — it is treated with suspicion, which usually means the spam folder. Providers have kept tightening this, and the large mailbox providers now effectively require authentication for bulk senders.
The failure is silent. Nothing bounces. You simply do not hear back, and you conclude the lead went cold.
What each record actually does
You do not need to configure these by hand to understand them, and understanding them makes the difference between fixing this once and fixing it repeatedly.
- SPF — Sender Policy Framework. A list, published in your DNS, of the servers allowed to send mail for your domain. The receiving server checks whether the message came from one of them. The common failure is forgetting a sender: your mail provider is listed but your invoicing tool, CRM or website contact form is not.
- DKIM — DomainKeys Identified Mail. A cryptographic signature added to each outgoing message, verified against a public key in your DNS. This proves the message was authorised by your domain and was not altered in transit. Usually enabled in your mail provider's admin console, which gives you a record to publish.
- DMARC — Domain-based Message Authentication, Reporting and Conformance. Ties the other two together: it tells receiving servers what to do when a message fails SPF and DKIM, and asks them to send you reports about it. Without DMARC, the other two records exist but nothing states a policy.
How to check what you have
Before changing anything, find out what is published. Any DNS lookup tool will show your records — search your domain's TXT records for entries beginning `v=spf1` and `v=DMARC1`.
Three things to look for. Is there an SPF record at all, and does it include every service that sends mail as you? Is there exactly one SPF record — two is a configuration error that causes both to fail? Is there a DMARC record, and what policy does it state?
The other useful test is to send a message to an account on a different provider and inspect the received headers. They will show explicitly whether SPF and DKIM passed. That is the ground truth, and it takes two minutes.
Fixing it without breaking your mail
The order matters, because an aggressive DMARC policy published before the other records are correct will send your legitimate mail straight to the bin.
- Inventory every service that sends mail as your domain — mail provider, CRM, invoicing, marketing tool, website forms, e-commerce notifications. This step is the one people skip and the reason fixes fail.
- Publish one SPF record including all of them. One record, not several.
- Enable DKIM in your mail provider's admin console and publish the key it gives you.
- Publish DMARC starting at `p=none` with a reporting address. This changes nothing about delivery but starts the reports flowing.
- Read the reports for a few weeks. They will show you legitimate senders you missed. Fix those in your SPF and DKIM setup.
- Only then tighten the policy to quarantine, and later to reject. Going straight to reject is how businesses lose a week of invoices.
The things that also matter
Authentication is necessary and not sufficient. A few other habits decide whether authenticated mail is welcome.
Send from your own domain, not a free mailbox. A quote from a gmail.com address is filtered more aggressively and trusted less by the human reading it.
Do not send bulk marketing from the same domain you send quotes from. If a campaign damages your reputation, it takes your invoices down with it. Marketing usually belongs on a subdomain.
Make sure your website's contact form sends from an address that passes authentication. Forms configured to send as the visitor's own address fail SPF by design, which is a common reason enquiry notifications vanish.
Keep the records current. Adding a new tool that sends mail means updating SPF. This is the maintenance nobody remembers, and it is why deliverability quietly degrades over a couple of years.