Why cold email lands in spam, and how SPF, DKIM and DMARC fix it
What the three email records actually prove to Gmail and Outlook, how to tell which one you are missing, and why a good record still cannot save a bad list.
Most cold email that lands in spam was never read by a spam filter's idea of a person. It was judged before anyone opened it, on two questions: can this sender prove it is who it says it is, and do people who get mail from it seem to want it. The first question is answered by three records in your domain's settings. The second is answered by your list and your writing.
What does a mail server check before it shows your email?
When your message arrives at Gmail or Outlook, the receiving server looks up your domain and asks it a series of questions. Is the server that handed over this message one the domain says it uses? Does the message carry a signature that only the domain's real key could have made? Has the domain published a policy for what to do when those answers come back wrong? Only after that does it look at the content, the links and the history of how people have treated your mail before.
Google and Yahoo now require bulk senders to pass these checks and to offer a one-click unsubscribe, and Microsoft has followed. A domain that skips them is not breaking a law. It is simply asking to be trusted without showing any identification, and the inbox treats it the way a bouncer treats a guest with no name on the list.
What is SPF, in plain words?
SPF, the Sender Policy Framework, is a single text record on your domain that lists the services allowed to send mail as you: your Google Workspace or Microsoft account, your newsletter tool, your outreach tool. If a message claims to come from your domain but arrives from a server not on the list, it fails.
The common mistakes are small. A domain ends up with two SPF records instead of one, which counts as broken. A new sending tool is added without being added to the record. Or the record lists so many services, each of which lists more, that it passes the lookup limit receiving servers will follow. Each of those fails quietly. Nothing bounces. Your mail just starts arriving in junk.
What is DKIM, and why is it the one people miss?
DKIM, DomainKeys Identified Mail, signs every message with a private key your mail provider holds, and publishes the matching public key on your domain. The receiving server checks the signature against the key. If it matches, the message really came through your provider and was not altered on the way.
It is the one people miss because nothing forces you to switch it on. Google Workspace sends mail perfectly well without it. You have to generate the key in the admin console, add it to your domain as a text record, and then press the button that starts signing. We found exactly this on our own main domain in October: the SPF record was right, a DMARC policy was in place and asking servers to quarantine anything that failed, and there was no DKIM key at all. So our own policy was telling Gmail to put our own mail in junk. We added the key the same day and the admin console now reports that it is authenticating.
What does DMARC add?
DMARC, Domain-based Message Authentication, Reporting and Conformance, is the rule that ties the other two together. It says what a receiving server should do when a message fails: nothing, send it to junk, or reject it. It also asks that the domain in the visible From line matches the domain that passed SPF or DKIM, which is what stops someone sending as you from a lookalike setup. And it names an address where servers send reports of what they saw.
Start with the policy set to none and read the reports for a couple of weeks. They will show you every service sending as your domain, including ones you forgot. Move to quarantine once your own mail passes, and to reject when you are sure. Point the reports at an inbox someone actually reads. Ours were going to an address at the old domain registrar that nobody checked, which is how a missing signature went unnoticed.
| Record | What it proves | What breaks it |
|---|---|---|
| SPF | The sending server is allowed to send for you | Two records, a missing tool, too many lookups |
| DKIM | The message was signed by your provider and not altered | Never switched on, key not published, tool signs with its own domain |
| DMARC | The From line matches a passing check, and what to do if not | No record, reports going nowhere, policy too strict too soon |
How do you check which records you have?
- Send a message from your domain to a Gmail address you control.
- Open it, choose Show original from the message menu, and read the three lines at the top: SPF, DKIM and DMARC, each marked pass or fail.
- For any fail, look up your domain in a free record checker such as MXToolbox or Google's own Admin Toolbox, which will show the record or its absence.
- Fix the record with your domain registrar, wait for it to spread, and send the test again.
Why can mail still land in spam with all three set?
Because the records prove identity, not welcome. Once Gmail knows who you are, it judges you by how its users treat your mail: whether they open it, reply, move it out of spam, or mark it as spam. A cold list bought from a broker, a first email with three links and an image, or a sudden jump from nothing to hundreds of sends a day will sink a perfectly authenticated domain.
This is why we send our own outreach from a separate domain, hellodrifted.com, at https://hellodrifted.com, rather than from driftedmarketing.com. If cold outreach ever earns a bad reputation, it earns it for the outreach domain, and the domain our clients and invoices come from stays clean. The outreach domain gets its own records and its own warm-up, which is the subject of the next piece.
When is this not worth paying an agency for?
Setting the three records is an afternoon's work for anyone comfortable in a domain registrar, and the steps above are the whole job. You do not need us for it. Where it is worth help is when mail is landing in spam and the records already pass, because then the problem is the list, the copy or the sending pattern, and that takes judgement rather than settings. Our email work is described at /services/email-marketing.
Questions we get asked
Yes. The records cost nothing, and without them even a handful of messages can be judged as unverified. A small sender with no records is easier to junk, not harder.
No. DMARC is a policy about the other two checks. With no DKIM and a strict DMARC policy, it can make things worse, which is what happened on our own domain.
We would not. Use a separate, similar domain for outreach, set its records, warm it up, and keep your main domain for customers and invoices.
Usually minutes to a few hours, depending on your registrar. Test again the same day, and if it still fails, check for a second conflicting record.