Why Do My TrekMail Emails Go to Spam?

Spam placement usually comes from a mix of three things: the recipient cannot verify the message is really from your domain, the sending domain has a poor recent history, or the message and recipient list look unwanted. No provider can promise an inbox placement, but the checks below address the parts you control.

Start with the domain's DNS status and the list you sent to. Those two checks resolve far more problems than changing a subject line.

First, identify the pattern

Test with a small number of recipients who expect your message. Note which providers place it in spam and whether the problem affects all messages or only a particular campaign.

• If the issue is limited to one recipient provider, check the authentication result and delivery response for that provider first.
• If multiple providers place the same mail in spam, review your domain DNS, sending volume, and list quality.
• If only one recipient reports the problem, ask whether they have a personal rule or previously marked your mail as spam.

Different providers use different signals, so there is no reliable provider-by-provider formula to follow.

Check 1: The domain's email authentication is complete

Open the domain's DNS status in TrekMail and compare the required records with the provider that controls your DNS. A domain that receives mail through TrekMail normally needs the following records:

• MX directs incoming mail to TrekMail.
• SPF authorizes TrekMail to send for your domain.
• DKIM lets recipients verify that the message was signed for your domain.
• DMARC tells recipients how to handle mail that fails authentication.

Sending-only domains do not use TrekMail's MX record, so follow the record table for that setup. Start DMARC with a monitoring policy if you are still checking legitimate senders; enforce a stricter policy only after the results are understood. See Checking DNS Status.

Check 2: Keep sending volume within the warmup limits

New domains have a sending warmup limit during their first week:

The limit helps avoid a sudden volume increase from a new sender. It does not guarantee an inbox placement.

Send only to people who expect the message, begin with your most engaged audience, and increase volume gradually. A healthy list and clear consent matter after the warmup period too.

The same warmup applies when a domain moves from another provider.

Full detail: Email Domain Warm-Up Rules.

Check 3: Check the current safety limits

If your account has ever_paid=false (you've never had a successful charge), you're capped at lower safety limits regardless of plan:

• During the trial: 30/mailbox/day, 50/account/day, 10 recipients/message, 15 messages/hour.
• After trial without paying: 50/mailbox/day, 150/account/day, 25 recipients/message, 20 messages/hour.

These limits are lower than the plan maximums. They control sending volume; they do not themselves measure or improve reputation. A plan's effective limits can also be reduced during domain warmup, so use the Dashboard and the sending error message to see the current limit.

Check 4: Send to people who expect your messages

Poor list quality creates bounces, complaints, and low engagement. All of these can harm future delivery. Review whether recipients:

• Asked to receive this type of message.
• Still use the address.
• Have recently interacted with your mail.

Practical steps:

• Choose an engagement period that fits how often you normally write, then stop sending marketing mail to contacts outside it.
• Check an old or imported list with TrekMail's Email Verifier before sending.
• Do not use bought, scraped, or unclear-consent lists.

Check 5: Keep the bounce rate low

Use the domain's Email stats to watch delivery and bounces. TrekMail marks a bounce rate below 2% as good, 2% to under 5% as a warning, and 5% or more as poor. A sustained 10% bounce rate over 24 hours can trigger the service's bounce-rate safeguard when there have been enough messages to measure it.

If the rate rises, pause the affected campaign, remove invalid recipients, and read Bounce Rate Too High before sending another batch.

A bounce rate is not the same as a spam complaint rate. A bounce means the receiving server did not accept the message; a complaint means a recipient marked an accepted message as spam. For mail sent to personal Gmail accounts, Google says to keep the user-reported spam rate below 0.1% and never let it reach 0.3%. Yahoo says bulk senders should remain below 0.3%. Treat 0.1% as the operating ceiling: one complaint in 1,000 messages is already enough to reach it.

Check 6: Make the message easy to recognise

Content cannot compensate for a poor list or failed authentication, but it can make a borderline message less trustworthy. Review these basics:

• Use a clear subject line instead of all caps or excessive punctuation.
• Include readable text, not only a large image.
• Use the same brand and sending domain the recipient expects.
• Link to a destination the recipient can recognise. Avoid unnecessary shortened links.
• For marketing mail, make it clear why the recipient is receiving it and include a visible unsubscribe link in the message.

Send yourself a normal copy before a large campaign so you can inspect the from name, links, formatting, and reply address.

If you send bulk mail to Gmail or Yahoo

Google applies additional requirements when a sender delivers more than 5,000 messages in one day to personal Gmail accounts. Those senders need SPF and DKIM, a valid DMARC record, aligned authentication, TLS, and valid forward and reverse DNS for the sending infrastructure. Marketing and subscribed messages also need one-click unsubscribe headers as well as the visible unsubscribe link in the message. Yahoo publishes similar authentication, complaint-rate, and one-click unsubscribe requirements for bulk senders.

For Managed SMTP, TrekMail operates the sending hosts, TLS, and forward and reverse DNS. You still need to publish the domain records shown in TrekMail, and you control consent, list quality, message type, and unsubscribe handling. If you send through a custom SMTP provider, confirm its authentication and infrastructure setup with that provider.

For API or MCP sending, follow Deliverability and Bounces to add List-Unsubscribe and List-Unsubscribe-Post safely. Do not add one-click unsubscribe to ordinary personal conversations. Google's one-click rule applies to marketing and subscribed messages, not transactional messages, although local laws and the message's purpose may still require a normal unsubscribe method.

These are provider requirements, not a promise of inbox placement. Review the current Google email sender guidelines and Yahoo sender best practices before a high-volume campaign because providers can change their rules.

Check 7: Check for a wider delivery incident

If a delivery problem begins suddenly across many recipients, check the status page for an active platform issue. You can also use a reputable public reputation checker for your own sending domain.

Do not try to remove a shared TrekMail sending IP from a third-party list yourself. Include the affected domain, recipient provider, time of the test, and any delivery response in a support ticket so the issue can be investigated in context.

One listing is not a complete diagnosis. Authentication, recipient consent, and recent bounce history still matter.

Check 8: Send a controlled test

You can send one normal sample message to a service such as mail-tester.com to spot obvious authentication and content issues:

1. Visit mail-tester.com, copy the unique address they show.
2. From your TrekMail mailbox, send a normal message you would actually send to customers.
3. Click "Check your score" on mail-tester.com.

Use the result as a troubleshooting hint, not as a guarantee that a provider will put the message in the inbox. Fix confirmed DNS or message issues first, then send another small test.

If Google provides enough data for your domain, Gmail Postmaster Tools can help you review Google's domain-level signals. Its data is not available for every sender and does not replace the checks in this guide.

Check 9: Confirm the sending route

Paid plans can use TrekMail's Managed SMTP. A domain can also be assigned a saved external SMTP profile. Check the domain's SMTP settings to see which route is selected.

When you use a custom SMTP profile, the external provider is responsible for its own SMTP credentials, authentication, IP reputation, and sending limits. Do not assume TrekMail's DNS records alone configure that provider.

Use the route that matches your email setup, then verify SPF, DKIM, and DMARC for the service that actually sends the message.

Understanding DMARC results

In your TrekMail DMARC reports, not every "failure" is a problem:

• SPF fails and DKIM passes: this can happen when a message is forwarded. DMARC can still pass when the remaining aligned authentication method passes.
• SPF passes and DKIM fails: check the DKIM record and the service that sent the message.
• Both fail: treat this as a configuration or spoofing warning and investigate before enforcing a stricter DMARC policy.

DMARC aggregate reports go to the address in your DMARC record. Their schedule and format are controlled by the reporting mail provider.

When everything looks right and you're still in spam

A few last things to check:

• List source: remove contacts whose consent or source is unclear.
• Sending pattern: avoid sudden volume increases, even when a plan limit permits them.
• Recipient-specific rules: ask the recipient to check their own spam folder and mail rules.
• Inbox categories: a promotions or other non-primary inbox category is different from spam and needs a different expectation, not a DNS change.