Why is my mail going to spam when my SPF, DKIM and DMARC look correct?

Short answer: because a records check can come back green and still have asked the wrong half of your domain. The most common cause of "my records are fine but my mail goes to spam" is that your domain is pointed at two different sets of nameservers at the same time, and one of those sets is stale — usually a leftover parking or previous-host entry that was never removed. Nameservers are the servers that answer questions about your domain, so whichever set a receiver happens to ask is the answer it believes. Ask the good set and it gets your real SPF, DKIM and DMARC. Ask the stale set and it gets a placeholder instead of a record, decides your mail is unauthenticated, and files it as spam. It is intermittent by nature, which is why it is so hard to spot: every checking tool that happens to ask the good set reports that everything is fine, and you get no bounces at all, because the mail is accepted and then quietly filed away. The second, simpler cause is a domain that has stopped resolving altogether — normally because it expired or is on hold at the registrar — and in that case adding records cannot help, because there is nowhere for them to be published. Both are fixed at your registrar, in the nameserver settings, and both are things WarmySender now tells you about by name.

WarmySender runs your outreach on autopilot with AI agents across Cold Email, Email Warmup, LinkedIn, Instagram and Multichannel sequences — plus real-time email verification. This is a deliverability question, and it sits underneath all of them: your sending domain has to give every receiver the same answer, or some of them will treat your mail as unauthenticated no matter how good your copy and your list are.

The one-minute version

If you recognise this list, read the next two sections and then go straight to your registrar:

• Your mailboxes all read as healthy, and your records read as valid.
• A large share of your mail — not all of it, but a lot — is going to spam.
• Your daily sending volume has come down on its own and stayed down.
• You have no bounces. None. Nothing has been refused.
• Nothing you change about your copy, your list or your sending schedule makes any difference.

That combination — bad placement, low volume, zero bounces, nothing you do helps — is the fingerprint of a fault that is intermittent rather than broken. Something is answering correctly some of the time. A split nameserver setup is the usual reason.

What are nameservers, in plain words?

Think of your domain as having an official address book. When someone's mail server receives an email claiming to come from your domain, it looks your domain up to answer three questions: is this sender allowed to send for you? (that is your SPF record), is this signature really yours? (that is your DKIM record) and what do you want done with mail that fails those checks? (that is your DMARC record).

Your domain does not hold those answers itself. It holds a short list of nameservers — the servers that are authorised to answer on its behalf. That list lives with your registrar, the company you bought the domain from, and it normally has exactly two entries, both from the same DNS host, like this:

ns1.dnshost.example
ns2.dnshost.example

Two entries from one host is not a backup arrangement in the sense of "the second one is used if the first is down". Both are treated as equally authoritative. A receiver picks one and believes what it says. That is completely fine when both entries are pointing at the same place and give the same answers — which is the whole point of listing them together.

How a domain ends up pointed at two sets at once

It happens quietly, and almost always during a move. You buy a domain and the registrar parks it on its own nameservers so the "coming soon" page works. Later you move your DNS to a proper host — a web host, a DNS provider, a cloud service — and you add the two entries that host gave you. What is easy to miss is that the original pair is still sitting in the list. Now your domain has four nameservers instead of two, and only two of them know anything about your mail.

The same thing happens when a web designer moves a site, when a domain is transferred between registrars, when a parking or "for sale" service was used at any point, or when someone adds a second host's nameservers to test a migration and never takes the first pair out. The site keeps working — a website usually only needs one of the two answers to be right — so nothing looks wrong. Email is where it shows up, because email is the part that is checked, on every single message, by a different receiver each time.

And crucially: you cannot see this by checking your records. A records check asks one question and gets one answer. If it happens to reach the good pair, everything is green. Run it again and it may still be green. The problem is not what your records say — your records are fine. The problem is that half of the internet is not being shown them.

A worked example

Say you send from acme.com. You set your DNS up properly two years ago and it has worked ever since. Your nameserver list at the registrar actually reads:

ns1.dnshost.example      <-- correct: your real DNS host
ns2.dnshost.example      <-- correct: your real DNS host
ns1.parkingpages.example <-- stale: left over from before
ns2.parkingpages.example <-- stale: left over from before

Here is what a receiver gets, depending on which pair it happens to ask:

Now add the piece that turns this from "a bit untidy" into "most of my mail goes to spam". If your domain publishes a strict DMARC policy — the setting that tells receivers to come down hard on mail that fails authentication — then you have instructed every receiver that lands on the stale pair to distrust your mail. You did the right thing publishing a strict policy. It is simply being applied to a wrong answer.

In practice most receivers respond to that by filing the message as spam rather than refusing it outright. That is why this shows up as a placement problem with a completely clean bounce report. Nothing was rejected, so there is nothing in your delivery figures pointing at it. The mail was accepted, judged, and put somewhere you cannot see.

And because a receiver's choice of which pair to ask is effectively arbitrary, your outcome is a mix. Some receivers see a perfectly authenticated domain. Others see an unauthenticated one. Same message, same day, same list.

Why "I have zero bounces" is a clue, not reassurance

A lot of people take a clean bounce report as proof that the technical side is fine. It is worth being clear about why it is not.

A bounce means a receiving server refused your message and told you so. Bounces are what you get when an address does not exist, when a mailbox is full, or when a domain is flatly blocked. What a bounce cannot tell you is where an accepted message ended up. Spam filing is not a refusal — the receiver takes the message, decides it does not trust it, and puts it in the spam folder without saying anything to anyone.

So a clean bounce report combined with poor placement is not a contradiction. It is a specific, informative pattern: your mail is reaching the receivers, and the receivers are choosing not to trust it. Authentication is the first thing they check, and a split nameserver setup is the most common way for authentication to fail on a domain whose records are genuinely correct.

How to check your own domain in two minutes

You do not need any technical tooling for this. You need the login for wherever your domain is registered — that is the company you pay each year to keep the domain, which may well not be the same company that hosts your DNS or your email.

1. Log in to your registrar — for example GoDaddy, Namecheap, Cloudflare Registrar, Google Domains or whoever you renew with.
2. Open the domain you send from and find the section called Nameservers, sometimes DNS or Manage DNS. You are looking for the short list of server names, not the long list of individual records.
3. Count the entries. Two is normal. Three or four is worth a very close look. Four is the classic split.
4. Read the names. Every entry should share the same host name — ns1.dnshost.example and ns2.dnshost.example. If you see two entries from one company and two from a different one, that is the problem, in front of you, in plain text.
5. Ask yourself which one you recognise. The pair you set up deliberately is the one to keep. The pair you do not recognise, or that mentions parking, "for sale", a coming-soon page, or a host you stopped using, is the one to remove.

If you would rather see it from the outside, any public "who hosts this domain" or "DNS lookup" tool will list the nameservers a domain is delegated to. Look at the count and the names, exactly as above. Do not rely on a records checker for this — a records checker asks one nameserver and reports what it said, which is precisely the blind spot that lets this fault survive for months.

How to fix a split nameserver setup

The fix is a small edit in one place, and it is the same edit whatever caused it.

1. Confirm which pair is live first. Open your DNS host's control panel — the company whose nameservers you meant to use — and check that your SPF, DKIM, DMARC and mail-server records are all there. That is your confirmation that this pair is the good one. Do not skip this step: removing the wrong pair is the one way to turn a partial problem into a total one.
2. At your registrar, edit the nameserver list so it contains only the pair from that host. Delete the others. Most registrars have you retype the list or untick a "use our default nameservers" option.
3. Save, and give it time. Nameserver changes spread across the internet gradually — usually within a few hours, sometimes up to 48. During that window some receivers will still be using the old answer, which is normal and self-correcting.
4. Re-check your records afterwards. Once the change has spread, every receiver is asking the same pair, so a green records check finally means what you assumed it meant all along.
5. Keep sending. There is nothing to switch off and nothing to restart. Your campaigns and your warmup carry on throughout.

If the nameserver list is managed by whoever built your website, forward them this page and ask them to leave only the pair belonging to your current DNS host. It is a one-line change for them.

The other cause: your domain has stopped resolving at all

This one is simpler and it is worth ruling out first, because the symptom looks similar from inside your account and the fix is completely different.

If a domain expires, or a registrar puts it on hold — an unpaid renewal, a card that failed, an unverified contact address after a registrant change — then the domain stops answering questions entirely. Not "answers wrongly": answers nothing. There are no nameservers to ask, so there is no SPF record, no DKIM record, no DMARC record and no mail-server record, because there is nowhere for any of them to exist.

The reason this matters as a separate case is that the obvious advice is actively wrong here. Being told to "add your records" sends you into your DNS host to add records that cannot be published, and you can lose days to that. The honest answer is: your domain has stopped resolving, and nothing else can be fixed until it resolves again.

What to do:

1. Log in to your registrar and check the domain's status and expiry date. An expired or held domain is usually flagged in bright colours the moment you log in.
2. Renew it, or clear whatever hold is on it. A held domain often just needs a verification email confirmed. Do this quickly — a domain left long enough past expiry can be resold, and the recovery gets harder and more expensive the longer it waits.
3. Check that your nameservers survived. Some registrars strip the nameserver list when a domain lapses, so after renewing you may need to point it back at your DNS host. While you are in there, count the entries — a lapse-and-renew is one of the ways a domain ends up with an extra pair.
4. Then check your records, which will start answering again once the domain does.

A domain that has stopped resolving affects far more than your outreach — your website and your incoming mail are down too — so it is usually welcome news that this is what it turned out to be. It is one renewal away from fixed.

What WarmySender tells you now

Until recently a domain with any of these faults got the same generic suggestion to check your records — which was unhelpful in the split case and simply wrong in the expired case. Your mailboxes now carry a notice that says which of the three situations you are actually in, and they are checked in that order, because the earlier ones make the later ones meaningless:

1. Your domain is not resolving. Nothing is answering for it at all. This is the expired-or-held case, and the action is at your registrar, not in your DNS records. Nothing about your records can be assessed while this is true, so we do not pretend to assess it.
2. Your nameservers disagree. Your domain is answering, but it is delegated to more than one set of nameservers and they do not say the same thing. This is the split case. The action is to reduce the list to the pair you actually use.
3. A record was not found. Your domain resolves, its nameservers agree, and a record is genuinely absent. This is the ordinary case, it is worth tidying up, and it is the mildest of the three on purpose — see below.

Three things are true of all three notices, and they will stay true:

• They are warnings, never blocks. A reading of your DNS never stops you sending. It tells you something; the decision stays yours.
• Nothing is paused automatically. Your campaigns keep running and your warmup keeps running. We do not switch off a customer's sending on the strength of a lookup.
• They describe what we found, not what we guess. If we cannot tell whether a record exists, we say we could not check it rather than reporting it as missing.

Why "a record was not found" is worded so mildly

Because the honest reading of our own data does not support alarming you about it. Across sending on the platform, domains with no SPF record on file do not place worse than domains that have one — if anything they place slightly better, once a single unusual workspace is set aside. That is not an argument against publishing your records; a published SPF, DKIM and DMARC set is still the right thing to have, and it is what lets a receiver confirm your mail is yours. It simply means a missing record, on its own, is not the emergency that a red warning would imply.

What is reliably associated with bad placement is a domain that contradicts itself or does not answer — the two cases above. So those are the ones written in stronger language, and the merely-absent case is written as the tidy-up it actually is. Full walkthrough of the records themselves: Email deliverability — SPF, DKIM and DMARC.

Why your daily volume dropped, and what brings it back

This is the part that usually worries people most, so here is exactly what is happening.

Warmup measures where the mail your mailboxes send actually lands in the mailboxes that receive it — inbox or spam folder. When that measurement turns bad, WarmySender reduces how much that mailbox sends each day. It is a protective response, not a penalty: pushing more mail out through a domain that is currently being distrusted is how a sending reputation gets damaged in a way that takes weeks to undo. So the low volume is a symptom of the placement problem, arriving alongside it rather than causing it.

You do not have to do anything to lift it, and there is no switch or setting that overrides it. As placement improves, the daily volume rises again on its own, judged on a rolling week rather than on any single day — one good day is noise, a good week is a signal. Fixing the delegation is what starts that clock: once every receiver is being shown the same correct answer, your mail authenticates for all of them, placement improves, and the volume follows. We will not put a date on it, because the honest answer depends on your domain's history and how receivers respond, and anyone who gives you a number is guessing.

One thing we will not claim: we cannot tell you which tab of an inbox your mail was filed under. Providers do not report that, to us or to anyone else, so no tool can honestly promise you a tab. What we can measure is inbox versus spam folder on your warmup mail, and what you can control is whether your domain gives every receiver the same, correct, authenticated answer. Fixing a split delegation is squarely in that second category. More on the measurement itself: why your spam rate can be high when your spam folder is empty, and how your warmup daily volume is decided.

A short checklist

If your records look right and your mail still goes to spam, work down this list in order. It is ordered so that each step is only meaningful once the one above it is clear.

1. Does the domain resolve at all? Check its status and expiry at your registrar. If it has lapsed, renew it — everything below is unanswerable until you do.
2. How many nameservers is it pointed at? Two from one host is right. Four, or a mixture of two companies, is the fault described on this page. Remove the pair you do not use.
3. Are your records actually on the pair you kept? Check SPF, DKIM, DMARC and your mail-server record in your DNS host's panel, not in a third-party checker.
4. Does your SPF record name the service you really send through? A very common miss is an SPF record that covers whoever handles your incoming mail while your outgoing mail leaves through something else the record never mentions.
5. Is your domain on a public blocklist? Separate problem, separate fix: my sending domain shows on a blocklist.
6. Then look at the ordinary levers — a verified list, a warmed-up mailbox, and copy that reads like a person wrote it. Those matter, but they cannot outrun a domain that fails authentication for half its receivers.

Frequently asked questions

Every SPF and DKIM checker I try says my records are valid. How can they be wrong?

They are not wrong — they are answering a narrower question than you are asking. A records checker asks one nameserver and reports what it said. If your domain is delegated to two sets of nameservers and only one set is stale, a checker that happens to ask the good set reports green, truthfully. Run it ten times and it may report green ten times. What it never tells you is that a receiver asking the other set gets a placeholder instead of your record and treats your mail as unauthenticated. To see that, you have to look at the delegation itself: log in to your registrar and count the nameservers on your domain. Two from one host is right; four, or a mix of two companies, is the fault.

How many nameservers should my domain have?

Normally exactly two, and both from the same DNS host — something like ns1.dnshost.example and ns2.dnshost.example. Some hosts legitimately give you three or four, but in that case they will all be that host's own names, from the same family. What is not normal is a list mixing two different companies, because both companies are treated as equally authoritative and only one of them holds your real records. If you see a pair you do not recognise, or a pair that mentions parking, a "for sale" service or a host you stopped using, that pair is the one to remove.

I have zero bounces. Doesn't that prove my setup is fine?

No, and it is one of the more misleading things about this fault. A bounce means a receiver refused your message and told you. Being filed as spam is not a refusal: the receiver accepts the message, decides it does not trust it, and puts it in the spam folder without notifying anyone. So poor placement with a completely clean bounce report is not a contradiction — it is the expected pattern when mail is being delivered and then distrusted. Authentication is the first thing a receiver checks, which is why a split delegation produces exactly this shape.

My website works perfectly. Surely my DNS is fine?

A website is much more forgiving than email. Visitors arrive in a steady trickle, browsers and networks cache answers heavily, and one working answer out of two is usually enough for a site to look completely normal. Email is checked from scratch, on every single message, by a different receiving server each time — so a fault that a website glides over shows up in your mail placement almost immediately. A working site is genuinely no evidence that your domain is answering consistently.

How do I know which pair of nameservers to remove?

Keep the pair belonging to the DNS host where your records actually live, and confirm that before you change anything. Log in to the DNS host you meant to use and check that your SPF, DKIM, DMARC and mail-server records are all present in its panel. That is your proof that this pair is the live one. Then, at your registrar, edit the nameserver list down to just those entries. If you are not sure which host is which, ask your registrar's support to tell you which nameservers are currently set — they can see the list and it is a routine question.

How long until my placement and volume recover?

We will not give you a number, because we would be guessing. What we can tell you is the mechanism. Nameserver changes usually spread across the internet within a few hours and can take up to 48; from then on every receiver is being shown the same correct answer, so your mail authenticates for all of them instead of some. Placement improves from there, and your daily volume rises again automatically as it does — judged on a rolling week rather than a single day, because one good day is noise. There is nothing to switch back on and no setting to change; the volume follows the measurement.

Will WarmySender pause my sending because of this?

No. A reading of your DNS is a warning, never a block — it never stops you sending, and nothing is paused automatically because of it. Your campaigns and your warmup keep running while you sort the delegation out at your registrar. Your daily volume may well be lower than usual, but that is the placement measurement protecting your domain's reputation, and it lifts on its own as placement improves.

My domain expired. Can I just add the records again?

Not yet — and this is the case where the usual advice sends you the wrong way. While a domain is expired or on hold there are no nameservers answering for it, so there is nowhere for an SPF, DKIM or DMARC record to be published. Renew the domain or clear the hold at your registrar first. Then check that your nameserver list survived the lapse, because some registrars strip it, and count the entries while you are there — a lapse and renewal is one of the ways a domain picks up an extra pair. Your records will start answering again once the domain does.

One of my records shows as not found. How urgent is that?

Worth tidying up, not an emergency — and we word it that way on purpose. Looking at real sending on the platform, domains with no SPF record on file do not place worse than domains that have one; if anything they place slightly better once one unusual workspace is set aside. Publishing a full set of records is still the right thing to do, because it is what lets a receiver confirm your mail is genuinely yours. But a single absent record, on its own, is not what is behind a sudden collapse in placement. A domain that contradicts itself or has stopped resolving is a far better explanation, and those are the two we flag in stronger language.

Does this affect my warmup as well as my campaigns?

Yes, and that is often where you notice it first. Warmup mail is sent from the same mailboxes on the same domain, so it is authenticated by receivers in exactly the same way. A receiver that lands on your stale nameservers treats a warmup email as unauthenticated just as it would a campaign email, and it goes to the spam folder. That is what drags the placement measurement down, and the reduced daily volume follows from it. Fixing the delegation improves both together, because it is one cause with two visible effects.

I send from several domains. Could more than one be affected?

Easily, and it is worth checking every one. Domains bought at the same time, moved by the same person, or set up from the same template tend to share the same history — including the same leftover nameserver pair. Check each sending domain's nameserver list separately at your registrar. It is a thirty-second look per domain, and finding the same extra pair on several of them explains a lot at once.

Related reading

• Email deliverability — SPF, DKIM and DMARC — what each record does and how to publish it
• Why is my spam rate high when my spam folder is empty? — what the placement measurement actually measures
• How your warmup daily volume is decided — every reason today's number is lower than your target
• Why did my warmup volume go down? — the protective reduction, and what lifts it
• My sending domain shows on a blocklist — a separate cause of poor placement, with a separate fix
• Why are my emails being rejected? — the opposite symptom: mail refused rather than filed away
• Why are my emails going to spam? — the wider picture of what receivers weigh up
• Full documentation — Cold Email, Email Warmup, LinkedIn, Instagram and Multichannel guides