Why Are My Emails Still Going to Spam With SPF, DKIM and DMARC?

Start with the message that actually went to spam, not with a DNS checker

The most common troubleshooting mistake is to prove that SPF, DKIM and DMARC records exist in public DNS and then conclude that authentication is fine. DNS records describe policy and public keys. They do not prove what happened to the message that a recipient actually received. The useful evidence is the full message source or authentication results for a real affected email, ideally from more than one receiving provider.

Look for the receiving system's Authentication-Results header and the DKIM-Signature header. Record whether SPF passed, which domain SPF authenticated, whether DKIM passed, which d= signing domain was used, which s= selector was used, and whether DMARC passed. Also note the visible From address. Those values tell you whether the real production sender followed the identity path you intended.

If the problem is a rejection rather than spam-folder placement, save the complete SMTP response and enhanced status code. Gmail, for example, publishes specific codes for low domain reputation, missing or mismatched PTR records, suspicious SPF records and other delivery problems. A bounce code is often more diagnostic than a generic third-party 'email health' score.

SPF can pass and the message can still fail DMARC

SPF authenticates the domain used in the SMTP envelope path, often called the Return-Path or MAIL FROM domain. It does not directly authenticate the human-visible From address that the recipient sees. DMARC connects those worlds by requiring the visible From domain to align with either a domain that passed SPF or a domain that passed DKIM.

That distinction matters when a business uses CRMs, invoicing platforms, newsletters, ticketing systems, website forms or other third-party senders. A platform may send from its own bounce domain and achieve SPF=pass, while the visible From address uses the business domain. If DKIM is absent or signs with a non-aligned domain, DMARC can still fail even though a scanner reports that SPF 'works.'

SPF also has operational limits. RFC 7208 requires implementations to cap the number of SPF mechanisms and modifiers that trigger DNS lookups at 10 during evaluation. Excessive include chains can therefore produce permerror. A record that looks syntactically normal can fail in production after providers add or change nested includes.

• Check the domain that actually produced SPF=pass, not merely the root domain you expected.
• Map every legitimate sending service before editing the SPF record.
• Count DNS-triggering mechanisms across nested includes and redirects, not just the visible top-level record.
• Do not publish multiple separate SPF records for the same domain; consolidate authorized senders into one valid policy.

DKIM existing in DNS does not mean the message was signed correctly

DKIM works at the message level. The sending system creates a cryptographic signature and places it in the DKIM-Signature header. RFC 6376 defines the d= tag as the signing domain and the s= tag as the selector. The receiving system combines those values to find the public key in DNS and verifies the signature against the message.

A business can therefore have a perfectly valid DKIM TXT or CNAME record that is irrelevant to the message currently being sent. The active platform may be using another selector, may not be signing at all, may sign with a vendor domain, or may be using a stale private key after a DNS change or migration. If multiple systems send on behalf of the same business, each path needs to be checked independently.

Gmail's current sender guidance requires DKIM keys of at least 1024 bits for mail sent to personal Gmail accounts and recommends 2048-bit keys where the provider supports them. That is a useful security baseline, but key length alone does not establish alignment or reputation.

• Read d= and s= from a real outbound message.
• Resolve selector._domainkey.signing-domain and confirm the public key is the one the sender expects.
• Check whether the DKIM signature passes after intermediaries such as gateways, forwarding systems or mailing-list software touch the message.
• During migrations, keep old selectors available until no legitimate traffic depends on them.

DMARC is about alignment, not just whether a _dmarc record exists

DMARC evaluates the visible RFC5322.From domain against authenticated identifiers from SPF and DKIM. Under RFC 7489, a message passes DMARC when at least one underlying authentication mechanism passes and the authenticated identifier aligns with the visible From domain. That is why 'SPF pass, DKIM pass' and 'DMARC pass' are related but not interchangeable statements.

Alignment can be relaxed or strict depending on policy. In relaxed alignment, organizational-domain relationships can be acceptable; strict alignment requires a closer domain match. A business using subdomains, a marketing platform or a separate bounce domain should know exactly which identifier is expected to align rather than assuming all successful authentication contributes equally.

A p=none DMARC policy is primarily a monitoring policy. It lets a domain owner receive aggregate feedback without asking receivers to quarantine or reject mail solely because of DMARC failure. A stronger policy can reduce spoofing exposure, but moving from monitoring to quarantine or reject before every legitimate sender is mapped can block the business's own mail.

• Confirm DMARC pass on real messages from every production sender.
• Use aggregate DMARC reports to discover unknown or forgotten sending sources.
• Do not move to a stricter enforcement policy until legitimate sources are authenticated and aligned.
• Treat forwarding separately because it can break SPF even when the original sender was legitimate.

Authentication is a floor. Reputation decides whether the receiver trusts the stream

Mailbox providers also evaluate reputation. Google Postmaster Tools describes domain and IP reputation as quality ratings influenced by sending behavior, and Yahoo states that it considers multiple factors including IP, URL, domain, sender and ASN reputation along with DKIM and DMARC. There is no universal reputation score shared by every receiver.

This explains a common business complaint: 'Everything passes, but Gmail still sends us to spam.' Authentication can establish that the message is genuinely associated with a domain while reputation tells the receiver whether mail from that identity has historically been wanted, safe and predictable. A fully authenticated unwanted message is still unwanted.

Shared infrastructure complicates the picture. On a shared outbound IP, another customer's behavior can contribute to IP-level reputation problems. On a dedicated IP, the business owns more of the reputation risk itself and must build a stable sending history. Neither model is automatically superior; the right choice depends on volume, operational discipline and the provider's controls.

Complaint rates matter more than many senders realize

Gmail's sender guidelines tell senders to keep the spam rate reported in Postmaster Tools below 0.10% and to avoid ever reaching 0.30% or higher; its baseline requirement states spam rates must remain below 0.3%. Yahoo similarly requires senders to keep spam complaint rates below 0.3%. Those are not targets to operate near. They are warning boundaries.

A complaint problem can exist even when a list was originally legitimate. Recipients change jobs, forget old subscriptions, lose interest, or no longer recognize a brand. Acquired, scraped or poorly permissioned lists are more dangerous because the sender has little evidence that recipients wanted the messages in the first place.

Easy unsubscribe is part of deliverability engineering, not merely a legal footer. Gmail requires one-click unsubscribe for marketing and subscribed messages from bulk senders, and Yahoo imposes similar expectations for bulk promotional traffic. Making it difficult to leave encourages recipients to use the spam button instead, which feeds reputation systems directly.

• Separate transactional messages from promotional campaigns operationally where practical.
• Suppress hard bounces and repeated non-engagers instead of repeatedly retrying bad audiences.
• Do not purchase or scrape mailing lists.
• Monitor complaints by campaign or message stream, not only at the whole-domain level.
• Make unsubscribe visible and functional for promotional traffic.

A sudden increase in volume can look suspicious even when the business is legitimate

Reputation systems learn patterns. A domain that normally sends 100 messages per day and suddenly sends 20,000 is not equivalent to a mature sender that has consistently sent at that level. A newly registered domain, a newly dedicated IP, a migration to a different outbound provider or a campaign launch can all change the historical context receivers use.

There is no universal 'warm-up schedule' that guarantees deliverability. The safer principle is to send wanted mail at a volume supported by real demand, increase gradually when the audience is genuinely engaged, and avoid artificial activity designed merely to manufacture reputation. If the business has a clean historical domain and migrates correctly, preserving identity and predictable traffic can be more valuable than treating every migration as if the brand were completely new.

When an account is compromised, the pattern can change in minutes. Unexpected spikes, high unknown-recipient rates, foreign login activity or large batches of similar messages should be treated as a security incident as well as a deliverability problem.

PTR, forward DNS, HELO identity and TLS are part of the trust chain

Gmail's current sender requirements include valid forward and reverse DNS for sending IPs and the use of TLS. Reverse DNS is often discussed casually as 'having a PTR record,' but the useful configuration is coherent identity: the IP resolves to an expected hostname and that hostname resolves appropriately back to the sending IP. Gmail publishes temporary error codes for sending IPs whose PTR is absent or whose forward lookup does not match.

The SMTP hostname presented in EHLO or HELO should also be intentional and valid. A self-hosted server presenting a generic, stale or non-resolving hostname creates avoidable inconsistency. For businesses operating their own mail infrastructure, these details should be checked alongside Postfix/Exim routing, TLS certificates, outbound source IP and DNS rather than treated as separate projects.

TLS protects the transport path but does not make a sender reputable. Likewise, a valid certificate, rDNS and authentication cannot compensate for abusive sending behavior. Deliverability is the interaction of identity, infrastructure and recipient response.

Content and URL reputation can matter even when the domain itself looks healthy

Receivers evaluate the message as a whole. Yahoo explicitly includes URL reputation among the factors it considers. If an email contains links through a compromised domain, a newly abused redirector, a low-trust tracking host or a destination associated with malware or deceptive behavior, the message can be treated differently from another message sent by the same mailbox.

Content filters also consider patterns that cannot be reduced to a list of 'spam words.' A legitimate invoice, security notification and sales promotion naturally contain different language and formatting. Problems arise when content, links, headers, authentication and sending behavior collectively resemble unwanted or deceptive traffic.

For that reason, endlessly rewriting subject lines while ignoring identity and reputation is usually a poor troubleshooting strategy. Test the entire sending path, including links and redirects, and compare an affected message with a known-good message from the same system.

Forwarding can break SPF without proving the original sender was fraudulent

SPF evaluates the connecting sender against the envelope domain. Traditional forwarding changes the connecting IP while often preserving the original envelope identity, so the forwarded copy can fail SPF even though the message was legitimate when first accepted. DKIM can survive forwarding if the signed headers and body remain intact, but some intermediaries modify messages in ways that invalidate the signature.

DMARC was designed with these realities in mind by allowing either aligned SPF or aligned DKIM to establish a pass. Forwarding environments may also use ARC to preserve authentication information through intermediaries, but ARC is not a substitute for configuring the original sender correctly.

When a deliverability complaint appears only after forwarding, mailing-list redistribution or a security gateway, compare the authentication results before and after the intermediary. Otherwise the business can waste time editing its public DNS for a failure introduced downstream.

The fastest reliable troubleshooting order

A good investigation narrows the problem before making changes. Start by classifying the symptom: spam-folder placement, temporary SMTP deferral, permanent rejection, missing message, or a problem limited to one receiving provider. Then collect a real affected message or bounce.

Next, validate message-level SPF, DKIM and DMARC; confirm the visible From, Return-Path, d= and s= identities; inspect sending IP, PTR, hostname and TLS; compare provider-specific reputation and complaint data where available; and review recent changes in sending systems, audience, volume and links. Only after that evidence is assembled should DNS or infrastructure be changed.

• 1. Identify affected recipient providers and whether the failure is spam, deferral or rejection.
• 2. Save full headers or the complete SMTP bounce response.
• 3. Validate SPF, DKIM and DMARC on the actual message.
• 4. Map the message to the real outbound IP, hostname and sending application.
• 5. Check PTR/forward DNS, TLS and provider-specific delivery errors.
• 6. Review Gmail Postmaster or equivalent provider evidence where volume permits.
• 7. Check complaints, list acquisition, bounce rates, sudden volume changes and compromised accounts.
• 8. Inspect message URLs and redirects.
• 9. Make the smallest evidence-supported change and retest.

How to tell whether the problem is the domain, the IP, the platform or the message stream

If multiple unrelated domains using the same outbound IP deteriorate at the same time, an IP-level or provider-level problem becomes more plausible. If only one domain is affected across several outbound IPs, domain or content reputation deserves more attention. If one application fails while normal person-to-person mail from the same domain remains healthy, investigate that application's authentication, list and content separately.

These are diagnostic clues, not mathematical proof. Modern filters combine signals. A domain and IP can both be weak; a marketing stream can contaminate a business domain; or a compromised mailbox can cause a good domain to deteriorate rapidly. The objective is to isolate the smallest shared component among the failures.

What a business should expect from professional deliverability remediation

A credible deliverability engagement should produce evidence, not just DNS screenshots. The provider should identify all legitimate senders, capture message-level authentication, map DNS and outbound infrastructure, examine SMTP responses, determine whether reputation data is available, and separate configuration failures from audience or behavior problems.

The remediation plan should explain what will change, what could break, how rollback will work, and how success will be measured after the change. If DMARC policy is being tightened, the plan should account for every legitimate sender first. If a self-hosted mail server is involved, the review should include hostname, PTR, TLS, relay configuration and outbound identity.

DSDillon currently lists Email Deliverability & Authentication Remediation from $1,500. The commercial question is not whether a DNS record can be edited cheaply; it is whether the business can identify and correct the actual source of lost or rejected mail without creating a second outage.

Frequently asked: if all three pass, why am I still in spam?

Because authentication and placement answer different questions. SPF, DKIM and DMARC help establish whether the sender is authorized and aligned. The receiver still decides whether the message is wanted and trustworthy using reputation, complaints, historical behavior, traffic patterns, links, content and other signals. Passing all three is essential hygiene, but it is not an inbox-placement certificate.

Frequently asked: should I change my DMARC policy to reject to fix spam placement?

Not as a spam-placement tactic. DMARC enforcement is primarily an anti-spoofing control. Moving to p=reject can protect the domain from unauthorized use when legitimate sources are mapped and aligned, but it does not create positive sending reputation. If legitimate services are still failing alignment, a premature enforcement change can reject the company's own mail.

Frequently asked: can an email provider guarantee inbox placement?

No responsible provider can control the final filtering decision of Gmail, Yahoo, Microsoft or a private receiving system. A provider can improve authentication, infrastructure, sending practices, evidence and reputation management. Be cautious with any service promising a guaranteed inbox percentage without controlling the receiving systems or understanding your actual audience.

Sources and verification

These references support the factual claims used in this guide. DSDillon separates published source material from observations that require investigation of an individual business.

• Google Gmail: Email sender guidelines ↗
• Google Gmail: Postmaster Tools dashboards ↗
• Google Gmail: SMTP errors and codes ↗
• Yahoo Sender Hub: Sender requirements and best practices ↗
• Yahoo Sender Hub: FAQs and reputation factors ↗
• RFC 7208: Sender Policy Framework (SPF) ↗
• RFC 6376: DomainKeys Identified Mail (DKIM) ↗
• RFC 7489: DMARC ↗
• DSDillon: Current service pricing ↗

Related DSDillon resources

• How Do I Check Whether SPF, DKIM and DMARC Are Actually Working? ↗
• How Do I Check My Email Domain Reputation? ↗
• Why Does My Business Email Keep Bouncing? ↗

Continue this investigation

• How do I check my email domain reputation? ↗
• How do I find my DKIM selector? ↗
• Why does business email keep bouncing? ↗