My Emails Are Going to Spam in Gmail or Outlook: How to Investigate the Cause
Updated 5 days ago
If your emails are landing in Spam or Junk, start with an actual message the recipient received: its headers let you check authentication and the sending server. Then compare whether the problem affects all messages or only one recipient, application, or campaign.
Gmail and Outlook combine signals related to authentication, reputation, content, and recipient behavior. Having SPF, DKIM, and DMARC configured correctly is essential for reliable sending, but it does not guarantee inbox placement.
This guide covers messages you send that the recipient finds in spam. If you want to filter messages you receive in your own inbox, see how to train your incoming mail filter.
Distinguish spam, rejection, and non-delivery
Where the message ended up and the text of any bounce change the diagnosis. A message accepted by the recipient's server can still end up in spam.
What happened
What to investigate
The message is in Spam or Junk
The received message's headers, authentication, reputation, and recipient rules.
You received a bounce
The complete rejection code and text. This is not the same as a message delivered to spam.
It doesn't appear, and there is no bounce
Delivery logs, possible delays, filters, rules, or the recipient's quarantine.
It appears in Gmail Promotions
It has been sorted into an inbox tab; Promotions is not Spam.
Outlook is also the name of an application. Confirm whether the receiving account is Outlook.com/Hotmail, Microsoft 365, or an account with another provider accessed through Outlook: the system that receives and filters the message may be different.
Get a useful example from the recipient
You need the message that landed in spam, with its original headers. The copy in Sent does not necessarily include the results added by the provider when it received the message.
Sender and recipient addresses.
Date and time with time zone, subject, and where the message appeared.
The application or service it was sent from: Webmail, Outlook, WordPress, a billing system, or a campaign platform.
The complete headers of the received message and its Message-ID.
Ask the recipient for the headers or the original message as a file, if their program lets them export it. Forwarding it as a regular email can lose some of the information needed.
In Gmail in a browser
The original shows the authentication results along with the message headers.
Open the received message in Gmail.
Open the message's More menu, next to Reply.
Select Show original.
Copy the headers and keep the SPF, DKIM, and DMARC results shown there.
The location depends on the version. In classic Outlook for Windows, open the email in its own window; in the web version or new Outlook, use the message menu.
Open the received message that was classified as junk.
In new Outlook or on the web, go to More actions > View > View message details. In classic Outlook for Windows, use File > Properties.
Copy the details or the contents of Internet headers, depending on the version.
Headers may include email addresses, IP addresses, and infrastructure details. Share them through the private support channel; don't post them in full on forums or public checkers.
Check which authentication passed and which failed
Look for the results added by the receiving provider, usually in Authentication-Results. A published DNS record does not prove that this specific message passed the check.
You can paste the original headers into the HostingFAQ header analyzer to see what the recipient reported about SPF, DKIM, and DMARC. The analysis runs in your browser, and you can copy a summary for support.
Check
What it means
What to check if it fails
SPF
The server that sent the message is authorized for the domain used in the envelope sender.
Which platform actually sent it, and whether its authorization is included in the correct SPF policy.
DKIM
The message's signature is validated using the signing domain's public key.
Whether that service signs outgoing messages, and whether its selector and public key are published correctly.
DMARC
At least one valid authentication method, SPF or DKIM, aligns with the domain shown in the From field.
The sender's visible domain and the domains that passed SPF or DKIM; a valid result for an unrelated domain is not enough.
A pass result means a check succeeded; fail indicates a failure, and none is not the same as a positive validation. If you're not sure how to interpret the full result, send us the headers so we can review them.
Follow our guide to configuring SPF, DKIM, and DMARC to make the necessary changes. If your DNS is hosted with Cloudflare or another provider, the records must be published there, even if cPanel displays its suggested values.
Don't add a second SPF record to authorize another platform or change DMARC to reject in an attempt to improve delivery. First, make a list of legitimate services that send using your domain and verify that they authenticate correctly.
Investigate the pattern of affected messages
Comparing two controlled sends helps distinguish a domain issue from an application or recipient issue. You don't need to repeat bulk sends to diagnose the problem.
It arrives correctly from Webmail, but goes to spam from WordPress or an application
The application may be using a different sending server or a sender address that doesn't authenticate with your domain. Compare the headers of both messages, not just the address shown in From.
In a form, use an authorized account on your domain as the sender and the visitor's address as the reply-to address, if the tool allows it. Using the visitor as the sender may cause the message to be sent on behalf of a domain you don't control.
For WordPress, see how to configure sending via SMTP. SMTP helps you specify the outgoing service, but that service must also authenticate correctly.
It only happens with one recipient or one company
Ask them to check their rules and blocked senders, and, if it's a corporate account, their organization's policies or quarantine. Compare the same type of message with a test account you control at another provider.
If the email is legitimate and expected, the recipient can use the option to mark it as not spam or add the sender as safe. This may help with their inbox, but it doesn't fix an authentication failure or guarantee delivery to other users.
SPF, DKIM, and DMARC pass, but the message still goes to spam
Check the reputation of the domain and outgoing IP, recipient complaints, and recent changes in sending volume. Valid authentication does not require the recipient to put the message in the inbox.
Make sure recipients expect these messages and that you're not using purchased or outdated lists.
Remove addresses with permanent bounces and honor unsubscribe requests.
Check links, the signature domain, and attachments, especially if the problem only occurs with one template.
If you find sends you don't recognize, investigate compromised accounts and applications before continuing to send.
We can check the outgoing IP and its configuration, including reverse DNS where applicable to the service. The PTR record cannot be fixed by adding a TXT record to the domain's DNS zone.
Only one template, signature, or campaign fails
Compare a representative sample with a simple test message, without the signature, links, or suspicious attachments. Change one element at a time to identify which difference coincides with the classification.
This helps isolate a cause; it is not a way to disguise content or bypass filters. There is no list of words whose replacement guarantees that a message will stop being marked as spam.
Campaigns require consent, unsubscribe management, and a platform suited to the volume. Check your service's sending limits before using a hosting mailbox for bulk sends.
The problem starts after the message is forwarded
Forwarding can change the server that delivers the email and affect SPF. DKIM may still validate if the signed content is preserved, but some message modifications can also affect the signature.
Compare a direct delivery with a forwarded one and send us both originals. Don't change authentication for the entire domain based only on the forwarded message.
No messages are going out, and the bounce comes from our own server
Our anti-spam filter also checks outgoing email and may block legitimate sends as false positives. In that case, the problem is not with your DNS or the recipient's mailbox.
Send the complete bounce text, along with the time and recipient, so we can review and release the blocked messages.
Messages are being sent from my domain that I didn't send
This may be a compromised mailbox. Change that mailbox's password to a randomly generated one, check the devices that use it for malware, and change your cPanel password as a precaution.
Also ask us to temporarily suspend sending from that mailbox while you secure access, so the server stops sending spam from your domain.
Check the result after making the change
The final test should be sent from the same application and use the same type of message that had the problem.
Send a sample to a test account you control or to a recipient who has agreed to help.
Check the delivery log and the folder where it arrived.
Check the new message's headers to confirm the authentication result.
Compare the result with the previous example and keep both timestamps and Message-IDs.
Mail logs help confirm delivery to the next server, but they don't necessarily show the recipient's final folder. There is also no universal timeframe for a reputation improvement.
Contact us with one or two recent examples, their headers, sender, recipient, time with time zone, and sending application. Tell us whether it affects all messages, just one campaign, or a single provider.
If there is a bounce, attach the complete text. We don't need the mailbox password to start reviewing the delivery details.
