The Login Works and the Mail Goes to Spam: Where to Look
The short answer
A successful login only proves the credentials. Spam placement comes from four other things: whether SPF, DKIM and DMARC align with the visible From address, whether the sending IP has a usable reputation, whether the list was verified, and whether the message reads like bulk mail. Read the received headers first.
This is the most common support question about any SMTP account, and it is usually answered in the wrong order. People rewrite the subject line when the visible From domain has no DMARC record, or buy a new mailbox when the real problem is a list full of addresses that never existed. The headers from one message tell you which it is.
Start with the headers, not the copy
Send one message to a mailbox you control at a major provider and open the original message source. Look for the authentication results line: it records the SPF, DKIM and DMARC verdicts as the receiving server computed them. Three passes mean authentication is not your problem and you should move to reputation.
Look next at the envelope sender and the visible From address. If the envelope is the provider's domain and the From is yours, SPF can pass while DMARC fails on alignment, which is the single most common misconfiguration with a bought mailbox. The message is authentic, just not authentic for the domain the recipient sees.
- spf=pass for a domain you do not control is not alignment: check which domain it names.
- dkim=pass with the provider's selector means the signature does not vouch for your domain.
- dmarc=fail with spf=pass is the signature of a missing or misaligned alignment.
- No authentication-results line at all means you are looking at the wrong message part.
Then the domain, which you can fix in an afternoon
Three DNS records decide whether your domain can be vouched for. SPF lists the servers allowed to send for it, DKIM publishes the public key that matches the signature, and DMARC states the policy and where reports go. All three are text records you can query from any DNS tool, and all three are visible to anyone who receives your mail.
The trap with a provider-supplied mailbox is that the provider's records are usually correct for the provider's own domain, and yours are untouched. Adding an SPF include for the provider, enabling DKIM with a selector published on your domain, and publishing even a monitoring DMARC record changes the verdict from fail to pass without touching the mailbox.
Then the reputation of the address and the list
IP reputation is a property of the address and its recent history, not of your intentions. A brand-new address has no history, which is neutral rather than good; an address previously used for bulk sending may have a history you did not create. Ask the provider which it is, and check whether the address is shared with other customers whose behaviour you cannot see.
The list is the other half. A list that was never verified contains addresses that never existed, which produce hard bounces, and addresses that were abandoned, which produce complaints. Receivers weigh both heavily, so a technically perfect sender with a bad list still lands in spam, and no settings change fixes that.
Last: the message itself, and the volume it arrives in
Content filters look for the patterns of unsolicited bulk mail: a single large image with little text, link shorteners, a mismatch between the link text and the destination, an unsubscribe that is hard to find, or a subject that promises an outcome. None of those are automatic failures, and together they move a borderline message the wrong way.
Volume and shape matter as much. Sixty messages sent within a minute from an address that has never sent anything is a pattern no subject line survives. Spreading the same sixty over a working day, to people who have a reason to recognise the sender, changes the outcome more than any rewrite.
Worked example: sixty messages, four inboxes, one DNS record
A recruitment agency sends sixty first-contact messages from a new mailbox through a provider. Four arrive in inboxes, forty-odd land in spam folders, and the rest never surface. The provider's dashboard reports all sixty as sent, which is technically true and useless.
The headers showed spf=pass for the provider's domain, dkim=pass for the provider's selector, and dmarc=fail for the agency's domain. The mailbox was authorised to send as the provider. Nothing was authorised to send as the agency, so every message arrived vouching for the wrong identity.
They published an SPF record including the provider, enabled DKIM with a selector on their own domain, and added a DMARC record in monitoring mode. Re-sending the same copy to the same four test inboxes produced three inboxes and one spam, and the spam one was a recipient who had marked a previous sender as junk. The copy had never been the problem.
Symptom to cause, in the order to investigate
| What the headers show | What it means | What to change |
|---|---|---|
| spf=pass, dmarc=fail | The envelope domain is not the visible From domain | Add an SPF include for the provider and align the From domain |
| dkim=none | Signing is off, or the selector is not published | Enable signing and publish the selector in DNS |
| spf=pass, dkim=pass, still spam | Authentication is fine; reputation, list or content is the issue | Check the address history, verify the list, reduce volume |
| spf=softfail or fail | The sending server is not in the SPF record | Add the provider to the record, or send through the domain SPF covers |
| Many hard bounces in the log | The list was not verified | Verify before sending; remove hard bounces permanently |
Every verdict above comes from a header line you can read yourself. Nothing here requires trusting a dashboard score.
The diagnosis, in eleven minutes
- 1Send one message to a mailbox you own and open the original source, not the rendered view.
- 2Find authentication-results and note the three verdicts and the domains they name.
- 3Query the domain's SPF TXT record and confirm the sending server is included.
- 4Confirm DKIM signing is enabled and the selector resolves in DNS.
- 5Confirm a DMARC record exists and check its policy.
- 6Ask the provider whether the address is dedicated and what it was used for before.
- 7Sample twenty addresses from the list and verify them before sending again.
- 8Reduce volume and spread it across the day, then watch bounces and complaints.
- 9Remove the link shortener and the single-image layout if either is present.
- 10Re-send the same message to the same mailbox and compare the verdicts.
Where this connects on this site
- If the fault is the address rather than the domain, see mailboxes tested before delivery
- To confirm a server accepts and relays at all, use the SMTP tester
- For the list side of the problem, start with verify a list before sending again
What this will not do
- No configuration guarantees inbox placement. Filters weigh engagement and recipient behaviour, which no sender controls.
- A DMARC record does not stop someone else spoofing your domain at policy quarantine or reject; it tells receivers what to do, and enforcement is theirs.
- This page cannot make an unverified list deliverable. Verification removes the addresses that were never going to work; it does not create permission.
- Warm-up and pacing reduce the odds of a volume spike being treated as abuse. They are not a substitute for a list of people who expect to hear from you.
- Nothing here is legal advice on consent, unsubscribe rules or data protection, which differ by country.
Questions this page gets asked
- The provider says the message was delivered. Why is it in spam?
- Delivered means a receiving server accepted it. Where it was filed afterwards is that server's decision, and it is invisible to the sending provider. The only way to see it is to test against mailboxes you control and read the headers and folder.
- Do I need a new domain to fix this?
- Usually not, but sometimes yes. If a domain has a long history of complaints, its reputation can be hard to recover. Publishing correct SPF, DKIM and DMARC and sending a clean, low-volume, engaged list is the test; if that fails after weeks, a separate sending subdomain is cheaper than a new brand.
- How many messages per day should a new mailbox send?
- Start with a volume small enough that every recipient would notice a poor message, and increase only while hard bounces and complaints stay near zero. The number matters far less than the shape: a gradual rise over days, not a cliff on the first morning.
Last reviewed 2026-10-26. Written for readers in the United States and elsewhere; rules about access, email and consent differ by country, and nothing on this page is legal advice.