Emails landing in spam: the causes and how to fix them
When emails land in spam, the text is rarely to blame. Almost always it is that the receiving server cannot verify the message really came from you. This guide shows how to fix that — with checks you can run yourself.
In short
- The cause almost never lies in the content but in authentication: the receiving server cannot check whether the message really came from your domain.
- Three DNS records solve it: SPF says who may send. DKIM signs the message. DMARC decides what happens on a mismatch.
- The order matters. Enforcing DMARC before SPF and DKIM run cleanly blocks your own email.
- After setup, allow two to four weeks of observation before calling it fixed.
The question comes up in almost every project: why do our emails land in the spam folder? The most common guess — too promotional, too many links, the word "free" — is rarely the reason. Modern spam filters assess something else first: whether the message is genuine at all.
The email protocol dates from a time when nobody expected abuse. In its original state, any machine in the world can send a message carrying your domain as the sender. The three records dealt with here close exactly that gap.
The three records and what they do
SPF, DKIM and DMARC in one sentence each
- SPF – who is allowed to send
- A DNS record listing which servers may send on behalf of your domain. The recipient looks it up: did this message come from one of those servers?
- DKIM – was it altered in transit
- The sending server signs the message cryptographically. The matching public key sits in DNS. The recipient verifies the signature.
- DMARC – what happens on a mismatch
- Your instruction to the recipient: do nothing, move to spam, or reject. The recipient additionally sends reports on what it saw.
Worth knowing
SPF and DKIM alone are not enough. Each checks only one part, and both can pass while the sender address visible to the recipient is still forged.
Only DMARC ties the checks to the address shown in the inbox. That is why it is the record with the actual effect — and why it is also the one you enforce last.
The right order
- Take stock. Who sends in your name? Usually more than expected: the mail provider, the newsletter tool, the CRM, the web server for form confirmations, accounting. Every one of them has to appear in SPF.
- Set SPF. A single record per domain listing all authorised senders. Multiple SPF records are an error and cause the check to fail before it starts.
- Set up DKIM. Activate it at each sending service and enter the key it provides into DNS. Every service gets its own.
- Start DMARC in monitoring mode. First with the instruction "do nothing" and an address for the reports. Let it run for two to four weeks.
- Read the reports. They show which senders are failing. If one is missing from SPF or DKIM, add it now.
- Only then tighten. From "do nothing" to "move to spam" and later to "reject". Observe for two weeks between each step.
How to check the current state
Before any change, it should be clear what currently applies. Two ways, neither needing extra software:
Via a received message. Open a message from your own domain in any mailbox and display the full headers. A line called Authentication-Results shows whether SPF, DKIM and DMARC passed. Three times "pass" means the technical side is right.
Via a DNS query. On any machine with a command line, the records can be queried directly. That shows what is actually published — not what the admin interface says should be there.
# view SPF nslookup -type=TXT your-domain.com # view DMARC nslookup -type=TXT _dmarc.your-domain.com # view DKIM (selector varies by service, example "default") nslookup -type=TXT default._domainkey.your-domain.com
When the technical side is right and it still fails
If authentication is clean and delivery is still poor, four other causes come into play.
A new domain with no sending history
A domain that has never sent is treated as unknown. Send ten thousand messages on day one and you will be throttled — rightly.
What helps: increase volume over two to four weeks, starting with your most engaged recipients.
Recognised by: poor delivery only on large sendsOld, inactive addresses on the list
Recipients who have not opened anything in a year are a negative signal. Some deactivated addresses are even repurposed by providers as traps.
What helps: anyone who has opened nothing in twelve months gets one last message — and is removed afterwards.
Recognised by: open rates declining over monthsSending from a shared address
With cheaper sending services, many customers share the same sending servers. Those servers' reputation then depends on other people's behaviour too.
What helps: a dedicated sending address from a few tens of thousands of messages a month — below that, rarely economical.
Recognised by: sudden drops with no change on your sideNo unsubscribe option in the headers
Large providers expect bulk sends to carry an unsubscribe that works with one click and is registered technically in the headers — not only as a link in the footer.
What helps: enable it in the sending tool; most support it, but not all by default.
Recognised by: problems specifically at large free mail providersSetting up our own sending, we followed the order correctly and still made a mistake: the server could not write its send log at first, because file permissions did not allow it. So we were sending successfully — just without any record.
It only came to light when we wanted to check which address a test message had actually gone to. The lesson: the log is not an accessory. Without it you cannot demonstrate what happened when it matters — and that is exactly what matters when a customer says they received nothing.
mail.your-domain.com. That keeps the reputation of your marketing sends separate from the reputation of your ordinary business correspondence. If something goes wrong on a campaign, your whole company communication is not affected at once.
In closing
Deliverability is not a text problem but a proof problem. Set the three records in the right order and you solve the vast majority of cases — permanently, because it is a one-off setup.
The effort is a few hours spread over four to six weeks, because the observation phases are part of it. Skip them and enforce immediately and you save the weeks — at the risk of important messages quietly disappearing.
Common questions
Why do my emails land in the spam folder?
In the vast majority of cases because the receiving server cannot verify that the message really came from your domain. That requires three DNS records: SPF, DKIM and DMARC. The content is to blame far less often than people assume.
What are SPF, DKIM and DMARC?
SPF lists which servers may send in your name. DKIM signs every message cryptographically so that alterations show up. DMARC ties both checks to the visible sender address and states what the recipient should do on a mismatch.
In what order do you set them up?
SPF first, then DKIM, then DMARC in monitoring mode. After two to four weeks, read the reports, add any missing senders, and only then tighten DMARC step by step. Enforce DMARC first and you block your own email.
How do I check whether the records are correct?
Fastest via the full headers of a received message: the Authentication-Results line has to show "pass" for SPF, DKIM and DMARC. In addition, the records can be inspected directly with a DNS query.
How long does a change take to work?
DNS changes become visible within minutes to 24 hours depending on the settings. A domain's reputation improves more slowly — expect two to four weeks before the delivery rate moves measurably.
Do you need a dedicated subdomain for sending?
Not strictly, but it is sensible. It separates the reputation of your marketing sends from that of your ordinary business correspondence. If something goes wrong on a campaign, your entire company communication is not affected.
Marketing that sets itself up
The Studio Engine beta is live. Claim your spot and help shape it from the start.
Join the beta →