Skip to content
Hosting Operations11 min read

How to fix email going to spam check: Practical Guide

Step-by-step guide to diagnose and fix emails going to spam. Configure SPF, DKIM, DMARC records and improve sender reputation with practical testing methods.

Written by Abdul AbrorTechnical Hosting Support Engineer
a blue button with a white envelope on it
On this page

TL;DR — Key takeaways

  • Emails go to spam primarily due to missing or misconfigured authentication records (SPF, DKIM, DMARC), poor sender reputation, or content triggers that match spam filters.
  • You can diagnose spam issues by sending test emails to mail-tester.com or Google Postmaster Tools, which provide actionable scores and identify specific authentication failures.
  • Fixing spam delivery requires configuring SPF records to authorize sending servers, adding DKIM signatures for message integrity, and implementing DMARC policies to prevent spoofing.
  • Sender reputation improves through consistent sending patterns, low complaint rates, proper list hygiene, and avoiding spam trigger words in subject lines and content.
  • Always test configuration changes with small batches before sending to your full list, and monitor bounce rates and spam reports through your mail server logs.

When your emails consistently land in spam folders instead of inboxes, the issue typically stems from authentication problems, reputation signals, or content patterns that trigger spam filters. Email providers use sophisticated filtering systems that evaluate sender authentication records, historical sending behavior, and message characteristics to protect users from unwanted mail.

This guide walks through the technical process of diagnosing why emails go to spam and implementing the authentication infrastructure needed to fix delivery issues. You'll learn how to configure DNS records, test your setup, and monitor ongoing deliverability.

Understanding Why Emails Go to Spam

Email spam filters evaluate three primary signal categories: authentication, reputation, and content. Authentication failures occur when your domain lacks proper SPF, DKIM, or DMARC records, making it impossible for receiving servers to verify that you're authorized to send mail from your domain. Reputation signals include your sending IP address history, domain age, bounce rates, and spam complaint ratios. Content triggers involve specific words, excessive links, misleading subject lines, or formatting patterns commonly found in spam.

Receiving mail servers assign a spam score based on these combined factors. A score above the threshold sends your message to spam. The threshold varies by provider, but Gmail, Outlook, and Yahoo use similar evaluation criteria defined by industry standards.

  • Authentication records prove your identity and prevent spoofing attempts
  • Sender reputation reflects your historical sending behavior and complaint rates
  • Content analysis scans for spam patterns in subject lines, body text, and HTML structure
  • Engagement metrics like open rates and reply rates signal legitimate correspondence

Diagnosing Your Current Email Deliverability

Before making configuration changes, diagnose the specific issues affecting your emails. Send a test message from your domain to mail-tester.com, which provides a detailed spam score and identifies missing authentication records, blacklist status, and content problems. The service returns a score out of 10 and flags specific failures.

For ongoing monitoring, register your domain with Google Postmaster Tools if you send significant volume to Gmail addresses. The dashboard shows your domain reputation, spam rate, authentication success rate, and encryption status. Check your mail server logs for bounce messages containing rejection reasons, which often specify whether the issue is authentication, reputation, or policy-based.

  • Use mail-tester.com for immediate diagnostic feedback on test messages
  • Check MXToolbox or similar services to verify your IP isn't on public blacklists
  • Review mail server logs for SMTP rejection codes and error messages
  • Monitor Google Postmaster Tools for reputation trends if sending to Gmail users

Configuring SPF Records for Sender Authorization

SPF (Sender Policy Framework) is a DNS TXT record that lists which mail servers are authorized to send email from your domain. When a receiving server gets mail claiming to be from your domain, it checks your SPF record to verify the sending IP is listed. Create an SPF record by adding a TXT record to your domain's DNS zone.

A basic SPF record looks like: v=spf1 mx a ip4:192.0.2.1 include:_spf.google.com ~all. This authorizes your MX servers, A record, a specific IPv4 address, and Google's mail servers. The ~all qualifier uses a soft fail, allowing unauthorized sources but marking them as suspicious. Use -all for strict enforcement only after thorough testing. Avoid including more than 10 DNS lookups in your SPF chain, as exceeding this limit causes validation failures.

  • Start with v=spf1 to indicate SPF version 1
  • Add mx to authorize servers listed in your MX records
  • Include ip4: or ip6: directives for specific mail server IPs
  • Use include: for third-party services like Google Workspace or SendGrid
  • End with ~all for soft fail during testing, then -all after verification
  • Test your SPF record with dig TXT yourdomain.com or online validators before going live

Implementing DKIM Signatures for Message Integrity

DKIM (DomainKeys Identified Mail) adds a digital signature to your email headers, allowing receiving servers to verify that the message wasn't altered in transit and came from your domain. Your mail server signs outgoing messages with a private key, and you publish the matching public key in DNS for verification.

Generate a DKIM key pair on your mail server using your mail transfer agent's tools. For Postfix with OpenDKIM, generate keys with opendkim-genkey -s selector -d yourdomain.com. This creates a private key file and a DNS record. Add the public key as a TXT record at selector._domainkey.yourdomain.com. Configure your mail server to sign outgoing messages using the private key. Test by sending an email and checking the headers for a DKIM-Signature field, then verify it with a DKIM validator.

  • Use a descriptive selector name like mail or default for your DKIM record
  • Store private keys securely with restricted file permissions (600 or 400)
  • Rotate DKIM keys annually by generating new keys and updating DNS gradually
  • Verify DKIM signing is active by inspecting outgoing message headers
  • Some hosting providers auto-configure DKIM; check existing setup before creating new keys

Setting Up DMARC Policies for Domain Protection

DMARC (Domain-based Message Authentication, Reporting and Conformance) builds on SPF and DKIM by telling receiving servers what to do when authentication fails and where to send failure reports. A DMARC record is a TXT record published at _dmarc.yourdomain.com that specifies your policy and reporting preferences.

Start with a monitoring-only policy: v=DMARC1; p=none; rua=mailto:[email protected]. This collects reports without affecting delivery, letting you identify legitimate sources that might fail authentication. After reviewing reports for a few weeks, gradually tighten the policy to p=quarantine (send failures to spam) or p=reject (block failures entirely). Add pct=10 to apply the policy to only 10% of messages initially, increasing as confidence grows.

  • Begin with p=none to monitor without impacting delivery
  • Use rua= to receive aggregate reports about authentication results
  • Add ruf= for forensic reports with message samples (use cautiously due to privacy)
  • Set pct= to apply policies gradually during the transition period
  • Ensure SPF and DKIM are working correctly before enforcing strict DMARC policies
  • Review DMARC reports weekly to identify authentication failures from legitimate sources

Improving Sender Reputation and Content Quality

Authentication records are necessary but not sufficient. Sender reputation depends on consistent sending patterns, low bounce rates, minimal spam complaints, and positive engagement. Avoid sudden volume spikes; if you're starting to send to a new list, warm up your IP address by gradually increasing daily volume over 2-4 weeks. Maintain a clean mailing list by removing bounced addresses and honoring unsubscribe requests immediately.

Content quality matters for both spam filters and recipient engagement. Avoid spam trigger words like free, guaranteed, or act now in subject lines. Use a balanced text-to-image ratio and avoid excessive links. Include a physical address and clear unsubscribe link to comply with regulations and signal legitimacy. Test content with spam checkers before sending to large lists, and monitor open rates as a proxy for deliverability.

  • Warm up new sending IPs by gradually increasing volume over several weeks
  • Remove hard bounces immediately and monitor soft bounce patterns
  • Keep spam complaint rates below 0.1% by honoring opt-outs promptly
  • Use double opt-in for mailing lists to ensure recipient consent
  • Maintain consistent sending frequency rather than sporadic bulk sends
  • Include proper footer information with physical address and unsubscribe links
  • Avoid URL shorteners in marketing emails as they're common spam indicators

Testing and Monitoring Email Deliverability

After configuring authentication records, verify the changes propagated correctly before sending to your full list. Use dig or nslookup to query your DNS records directly: dig TXT yourdomain.com for SPF, dig TXT selector._domainkey.yourdomain.com for DKIM, and dig TXT _dmarc.yourdomain.com for DMARC. Allow 24-48 hours for DNS propagation, though changes often appear within a few hours.

Send test emails to multiple providers (Gmail, Outlook, Yahoo) using seed accounts. Check that messages arrive in the inbox, not spam, and inspect full headers to verify SPF, DKIM, and DMARC pass. Monitor your mail server logs for authentication failures or rejections. Set up automated alerts for bounce rate spikes or delivery issues. Review DMARC reports regularly to catch configuration drift or unauthorized sending attempts.

  • Test with seed accounts at major providers before sending production mail
  • Verify DNS changes propagated using dig or online DNS checkers
  • Inspect message headers to confirm SPF pass, DKIM pass, and DMARC pass
  • Monitor bounce logs and set thresholds for automated alerts
  • Use mail-tester.com periodically to catch configuration regressions
  • Document your configuration and set calendar reminders for DKIM key rotation

Quick troubleshooting checklist

  • Run mail-tester.com diagnostic to identify current authentication and content issues
  • Check if your sending IP appears on public blacklists using MXToolbox
  • Create SPF record as DNS TXT record at your domain root
  • Generate DKIM key pair and add public key to DNS at selector._domainkey.yourdomain.com
  • Configure mail server to sign outgoing messages with DKIM private key
  • Add DMARC record at _dmarc.yourdomain.com starting with p=none policy
  • Wait 24-48 hours for DNS propagation and verify records with dig commands
  • Send test emails to Gmail, Outlook, and Yahoo seed accounts
  • Inspect message headers to confirm SPF, DKIM, and DMARC all show pass
  • Review DMARC aggregate reports after one week of monitoring
  • Gradually tighten DMARC policy from p=none to p=quarantine after confirming legitimate mail passes
  • Clean mailing lists by removing bounced addresses
  • Review email content for spam triggers and maintain text-to-image balance
  • Set up bounce rate monitoring and spam complaint tracking
  • Document final configuration and schedule DKIM key rotation reminder

FAQ

How long does it take for SPF, DKIM, and DMARC changes to fix spam delivery issues?

DNS propagation for authentication records typically completes within 24-48 hours, though changes often take effect within a few hours. After DNS propagates, receiving servers will immediately start validating your authentication on new messages. However, sender reputation improvements take longer—typically 2-4 weeks of consistent, authenticated sending with low complaint rates. Test with seed accounts after 24 hours to verify authentication passes, but expect gradual inbox placement improvement over several weeks.

Can I use the same DKIM key for multiple domains on one mail server?

No, each domain requires its own unique DKIM key pair. DKIM signatures are domain-specific because the signature verification process looks up the public key at selector._domainkey.yourdomain.com. Using separate keys per domain provides better security isolation and allows you to rotate keys independently if one is compromised. Generate individual key pairs for each domain you send mail from, even if they share the same physical mail server.

What should I do if legitimate emails still go to spam after configuring authentication records?

First verify your SPF, DKIM, and DMARC records all show pass by inspecting message headers. If authentication passes but delivery fails, the issue is likely sender reputation or content-based. Check if your sending IP is on blacklists using MXToolbox and request delisting if found. Review DMARC aggregate reports to identify volume or pattern anomalies. Reduce sending volume temporarily and remove bounced addresses. Test email content with mail-tester.com to identify spam trigger words or formatting issues. For persistent problems with specific providers, contact their postmaster support with authentication proof.

Should I use SPF hard fail (-all) or soft fail (~all)?

Start with soft fail (~all) during initial testing to avoid blocking legitimate mail from sources you haven't authorized yet. Soft fail marks unauthorized sources as suspicious but doesn't reject them outright. After monitoring DMARC reports for 2-4 weeks and confirming all legitimate sending sources are included in your SPF record, switch to hard fail (-all) for stronger protection against spoofing. Hard fail instructs receiving servers to reject messages from unauthorized sources. The transition prevents accidentally blocking legitimate mail while tightening security incrementally.

How do I interpret DMARC aggregate reports to improve deliverability?

DMARC aggregate reports arrive as XML files showing authentication results for messages claiming to be from your domain. Focus on rows where SPF or DKIM failed, especially if disposition is reject or quarantine. The source IP shows which server sent the message. Legitimate sources that fail authentication need to be added to your SPF record or configured for DKIM signing. High failure counts from unknown IPs indicate spoofing attempts, confirming your DMARC policy is working. Use DMARC report analyzers like dmarcian or Postmark to parse XML into readable tables. Review weekly during the first month, then monthly after stabilizing.

Related articles