My emails are reaching spam in Gmail or Outlook: how to investigate the cause
Updated 3 days ago
If your emails are reaching Spam or Junk Email, start with an actual message the recipient received: its headers let you review 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 from authentication, reputation, content, and recipient behavior. Having SPF, DKIM, and DMARC configured correctly is a necessary foundation for reliable sending, but it does not guarantee inbox placement.
This guide covers messages that you send and the recipient finds in spam. If you want to filter messages you receive in your own mailbox, see how to train the incoming mail filter.
Distinguish spam, rejection, and non-delivery
The message location and the text of any bounce message 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 Email
Received message 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 does not appear and there is no bounce
Delivery logs, possible delays, filters, rules, or recipient quarantine.
It appears in Gmail's Promotions tab
It is classified in 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 a mailbox from another provider opened in Outlook: the system that receives and filters the message may be different.
Get a useful example from the recipient
You need the message that reached spam, with its original headers. The copy in Sent does not necessarily contain 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.
Application or service used to send it: Webmail, Outlook, WordPress, billing system, or campaign platform.
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 allows them to export it. Forwarding it as a regular email may cause some of the necessary information to be lost.
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 data. Share them through the private support channel; do not paste them in full into 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 the specific message passed the check.
Check
What it means
What to review 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 signature is validated using the public key of the signing domain.
Whether that service signs the 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 domain shown to the recipient and the domains that passed SPF or DKIM; a valid result for an unrelated domain is not sufficient.
A pass result means the check succeeded; fail indicates a failure, and none is not equivalent to positive validation. If you are not sure how to interpret the complete result, send us the headers so we can review it.
Follow our guide to configuring SPF, DKIM, and DMARC for the necessary changes. If your DNS is hosted with Cloudflare or another provider, the records must be published there, even if cPanel displays suggested values.
Do not add a second SPF record to authorize another platform or change DMARC to reject as an attempt to improve delivery. First inventory the legitimate services that send using your domain and verify that they authenticate correctly.
Investigate the pattern of the affected messages
Comparing two controlled sends helps separate a domain problem from one involving an application or recipient. You do not need to repeat mass sends to diagnose it.
It arrives correctly from Webmail, but reaches spam from WordPress or an application
The application may be using a different sending server or a sender that does not authenticate with your domain. Compare the headers of both messages, not just the address shown in From.
In a form, use an authorized account from your domain as the sender and the visitor's address as the reply address when the tool allows it. Using the visitor as the sender may cause the message to attempt to send on behalf of a domain you do not control.
For WordPress, review how to configure sending via SMTP. SMTP helps define the outgoing service, but that service must also authenticate correctly.
It only happens to one recipient or one company
Ask them to review their rules and blocked senders and, if it is 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 indicate that it is not spam or add the sender as a safe sender. This may help their mailbox, but it does not fix an authentication failure or guarantee delivery to other users.
SPF, DKIM, and DMARC pass, but it still reaches spam
Review the reputation of the domain and outgoing IP, recipient complaints, and recent changes in sending volume. Valid authentication does not require the recipient to place the message in the inbox.
Check that recipients are expecting these messages and that you are not using purchased or outdated lists.
Remove addresses with permanent bounces and honor unsubscribe requests.
Review links, the signature domain, and attachments, especially if the problem appears only with one template.
If you detect sends you do not recognize, investigate compromised accounts and applications before continuing to send.
We can review the outgoing IP and its configuration, including reverse DNS when applicable to the service. The PTR record is not fixed by adding a TXT record to the domain 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 matches the classification.
This helps isolate a cause, not disguise content or evade filters. There is no list of words whose replacement guarantees that a message will stop being classified as spam.
Campaigns require consent, unsubscribe management, and a platform suitable for the volume. Consult your service's sending limits before using a hosting mailbox for bulk sends.
The problem appears after the message is forwarded
Forwarding can change the server that delivers the email and affect SPF. DKIM may continue to 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. Do not change authentication for the entire domain based solely on the forwarded message.
No message is sent and the bounce comes from our own server
Our anti-spam filter also checks outgoing mail and may block legitimate sends as a false positive. In that case, the problem is not with your DNS or the recipient's mailbox.
Send us the complete bounce text, including the time and recipient, so we can review it and release the blocked sends.
Messages are being sent using my domain that I did not send
This may be a compromised mailbox. Change that mailbox's password to a randomly generated one, check the devices that use it to rule out malware, and also change your cPanel password as a precaution.
Also ask us to temporarily suspend sending from that mailbox while you fix access, so the server stops sending spam using your domain.
Check the result after the adjustment
The final test must come 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.
Review the new message's headers to confirm the authentication result.
Compare the result with the earlier example and keep both timestamps and Message-ID values.
Mail logs help confirm delivery to the next server, but they do not necessarily show the recipient's final folder. An improvement in reputation also has no universal timeframe.
Contact us with one or two recent examples, their headers, sender, recipient, time with time zone, and sending application. Indicate whether it affects all messages, only one campaign, or a single provider.
If there is a bounce, attach the complete text. We do not need the mailbox password to begin reviewing the delivery data.
