Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Your self-hosted email can reach a mail provider and still land in spam because inbox placement is decided by the recipient’s filtering systems. Those systems evaluate authentication and DNS alongside the sending IP and domain’s reputation, recipient complaints, message content, sending patterns, and local recipient rules. Passing SPF, DKIM, or DMARC does not guarantee inbox delivery.

Why is my self-hosted email going to spam?

The most common causes are a missing or invalid authentication record, incorrect reverse DNS for the outbound IP, weak or damaged sender reputation, unwanted or complaint-prone recipients, message characteristics that trigger filtering, or rules on the recipient’s mail system. A server can be configured correctly for receiving mail and still have problems sending it: inbound MX records do not establish the reverse-DNS identity of its outbound IP.

Google’s guidance says authenticated messages are less likely to be rejected or marked as spam, not guaranteed to reach the inbox. Microsoft likewise recognizes that legitimate mail can be incorrectly flagged. Treat authentication as a foundation, then use the affected message’s headers, SMTP response, and provider-specific diagnostics to narrow down what happened.

Check whether authentication passes—and aligns

Do not rely on the fact that DNS records exist. Inspect the full headers of a message that reached the recipient and read its Authentication-Results field. Check which identities were actually evaluated: SPF authenticates the envelope sender, DKIM validates a signing domain, and DMARC checks whether SPF or DKIM aligns with the domain shown in the visible From address.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

SPF and DKIM must describe the real sender

Ensure the SPF record authorizes every system that sends mail for your domain, including any legitimate third-party service. A message may fail SPF if it leaves through an IP or service the record does not cover. Confirm that DKIM signing is enabled and that the signature validates for the intended domain. Google’s personal Gmail guidance specifies a DKIM key of at least 1024 bits and recommends 2048 bits where supported. Avoid publishing conflicting SPF records.

DMARC passing depends on alignment

An SPF pass alone does not prove DMARC alignment. The authenticated SPF or DKIM domain must align with the visible From domain under DMARC rules. For mail to personal Gmail accounts, Google requires senders sending more than 5,000 messages per day to Gmail accounts to publish DMARC and align the From domain with SPF or DKIM. Google says the DMARC policy can be p=none. These are Google-specific requirements, not a universal volume threshold for all mail providers.

Google’s guidance, whose requirements apply to mail sent to Gmail accounts from February 1, 2024, requires all senders to use SPF or DKIM; it recommends configuring SPF, DKIM, and DMARC for all domains. For current details, consult Google’s Email sender guidelines and its sender guidelines FAQ.

How do I check whether my mail server’s PTR record is correct?

Check the public IP that actually sent the message, not just the hostname you use to access webmail or your mail server. Google requires a sending IP to have a PTR record that resolves to a hostname, and that hostname’s A or AAAA record must resolve back to the same sending IP. This is forward-confirmed reverse DNS.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
  1. Find the outbound public IP in the message headers or your mail server’s logs for the affected message.
  2. Look up the PTR record for that IP and note the hostname it returns.
  3. Look up that hostname’s A and, if present, AAAA records. Confirm the address corresponding to the sending connection points back to the same public IP.
  4. If the PTR is missing or the records do not match, contact the company that controls the IP address—often your hosting provider, ISP, or IP owner—to request a correction.

A missing PTR or a hostname that does not resolve back to the sending IP can lead to Gmail rate limits or blocking errors. Google documents the requirement and related diagnostic responses in its sender guidelines and FAQ.

Reputation and recipient complaints can outweigh correct DNS

Filters use a history of sending behavior as well as individual-message authentication. Google says frequent spam reports lower a domain’s reputation and make future mail more likely to be classified as spam. Microsoft lists historical complaints, blocklist entries, and low sending volume among factors that can contribute to poor IP or domain reputation. Owning a domain or server does not, by itself, establish a good reputation; investigate the actual IP and domain rather than assuming a residential or VPS address is automatically blocked.

Google recommends keeping the reported spam rate below 0.1% where possible and avoiding 0.3% or higher. It says rates above 0.1% can negatively affect bulk-sender inbox delivery, with greater negative impact at 0.3% or higher. These figures are Gmail guidance, not universal thresholds. For bulk mail to Gmail, the stated threshold is more than 5,000 messages per day to Gmail accounts; Google’s additional rules include SPF, DKIM, DMARC, alignment, and one-click unsubscribe for marketing and subscribed messages.

  • Send to people who opted in, and remove invalid addresses.
  • Honor opt-outs and make it easy for recipients to unsubscribe.
  • Avoid sudden volume spikes; send consistently, begin with engaged recipients, and increase volume gradually while monitoring feedback.
  • Use Google Postmaster Tools to review available Gmail authentication, spam-feedback, and domain/IP reputation information.

Google’s Email sender guidelines explain its reputation and sending practices, while its FAQ clarifies spam-rate guidance.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Message content and sending patterns can trigger filtering

Correct DNS and authentication do not make every message look wanted. Microsoft identifies characteristics associated with false positives, including excessive links, URL shorteners, form tags, embedded scripts, and image-only content. Google also requires RFC 5322 formatting and recommends consistent sending rather than bursts.

Review the message that was actually filtered, including its links, formatting, and recipient context. Do not assume that removing a particular word or link will solve delivery: content is one signal among several, and the same message may be treated differently by different providers.

The recipient’s mail system may be responsible

If your message reaches some providers but is flagged by one company or one recipient, the filtering decision may be local to that destination. Microsoft says an organization’s transport rules, antispam policies, or a user’s blocked-sender list can classify legitimate mail as spam. A non-Microsoft security service placed in front of Microsoft 365 can also obscure the original source IP and contribute to authentication failures if the environment is not configured to preserve it.

For a Microsoft 365 recipient, inspect the message’s Authentication-Results and X-Forefront-Antispam-Report headers and ask the administrator to review message trace, relevant policies, and block-list overrides. Microsoft’s Anti-spam protection FAQ describes these recipient-side causes and investigation steps.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

A practical troubleshooting order

  1. Identify the exact failure. Record the recipient’s provider, whether the message was rejected or delivered to spam, the sending IP, and the time. Save the full message headers and any SMTP response or error code.
  2. Read the authentication results. Check SPF, DKIM, and DMARC in Authentication-Results. Verify SPF covers the actual outbound sender, DKIM validates for the intended domain, and DMARC alignment matches the visible From identity where required.
  3. Verify outbound DNS identity. Check the sending IP’s PTR and confirm its hostname’s A or AAAA record resolves back to that IP. If it does not, ask the IP provider to fix reverse DNS.
  4. Check provider diagnostics and reputation. Review the SMTP response for useful error details. For Gmail, use Postmaster Tools where available to examine authentication, spam feedback, and reputation. Also check the sending IP and domain for reputation or blocklist problems.
  5. Review who receives the mail and how it is sent. Stop sending to unconsented or invalid recipients, honor opt-outs, remove recipients who do not engage, avoid abrupt volume spikes, and inspect the filtered message’s format and content.
  6. Investigate the recipient’s filtering path. For Microsoft 365, use the headers and message trace and ask the recipient’s administrator to check local policies, rules, and overrides.

Google documents its Gmail requirements and diagnostics in the Email sender guidelines and FAQ. Microsoft’s investigation guidance is in its Anti-spam protection FAQ.

What if SPF, DKIM, and DMARC pass but the email still goes to spam?

Passing authentication confirms identity checks, not inbox placement. Continue by checking PTR and forward DNS, sender reputation, complaint and engagement history, the content and format of the message, and recipient-side policies. A provider may also use filtering signals that are not visible in the headers. Google explicitly says it cannot guarantee that messages from email providers will pass Gmail spam filters.

If the recipient confirms the message is legitimate, they can mark it as not spam where appropriate. Keep monitoring actual delivery and complaint data rather than expecting a single DNS change to fix every recipient’s filtering decision.

When does a managed outbound relay make sense?

Consider a managed relay if you cannot maintain an appropriate outbound IP, forward-confirmed reverse DNS, authentication, and ongoing complaint and reputation monitoring. Compare the options by control over configuration, availability of a stable sending IP and valid PTR, reporting access, volume and complaint controls, operational workload, and whether the provider’s practices meet the destination providers’ current rules. A relay does not remove the need to configure SPF, DKIM, and DMARC correctly or to send wanted mail.

Free tools Windows power users keep installed

One-click scans. No signup required.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.