Why your emails go to spam, and how to stop it

To stop emails going to spam, work through four things in order: authenticate your sending domain with SPF, DKIM and DMARC, send from a domain you own rather than a free mailbox address, keep complaints and bounces low by only mailing people who expect the message, and make each message plainly what its subject says. Then read the headers of one message that landed in spam to see which check failed. Check authentication before changing the message content.

This guide is written for developers sending sign-up, receipt, reset and alert emails from an application. Marketing email has extra rules, which we point out where they matter.

Before you start

• Access to the DNS for the domain you send from, or someone who can publish records for you.
• One real message that landed in spam, opened in the recipient's mail client so you can view its original headers. Without it you are guessing.
• A Gmail account to test with. Google's published sender guidelines provide a useful authentication and sending checklist.
• About an hour. DNS changes can take longer to show, and a new sending domain needs a few days of normal use before you judge it.

Step 1: read the headers of a message that went to spam

In Gmail, open the message, choose the three-dot menu, then Show original. The summary at the top shows SPF, DKIM and DMARC, each marked PASS or FAIL. If any is FAIL or missing, you have found the first thing to fix. If all three pass, the cause is reputation or content, which steps 4 to 6 cover.

Check the Authentication-Results header too. It names the domain each check passed for. A DKIM pass for your email provider's domain, not yours, means the message is not aligned with your From address, and DMARC can still fail.

Step 2: authenticate the domain you send from

Three DNS records tell receiving servers that your provider may send as your domain.

• SPF lists the servers allowed to send for the domain. It is a TXT record, and a domain should have only one.
• DKIM signs each message with a key published in DNS, so the receiver can tell the message was not altered and came from the signing domain.
• DMARC tells receivers what to do when SPF and DKIM do not line up with the From address, and where to send reports. A policy of none asks receivers to take no action on failures, but it does not turn on reporting. Reports only arrive if the record has a rua tag with an address to send them to, for example rua=mailto:dmarc-reports@example.com. Add one before you rely on reports, then tighten the policy once they show your mail passing.

Google's sender guidelines, checked on 20 October 2026, ask every sender to set up SPF or DKIM. Anyone sending more than 5,000 messages a day to Gmail addresses must set up SPF, DKIM and DMARC, with the From domain aligned to the SPF or DKIM domain. Do all three whatever your volume. It is the cheapest fix on this page.

A common mistake is publishing a second SPF record when you add a new provider. Two SPF records on one name makes SPF fail. Merge them into one.

Step 3: send from a domain you own

Do not send from an address at gmail.com, yahoo.com or another mailbox provider's domain through a third-party transactional service. Use a domain you control, because mail that fails DMARC can be quarantined or rejected. Google's guidelines say not to impersonate Gmail From headers, and that Gmail applies a quarantine policy to those who do.

Use a subdomain of your own domain for application mail, such as mail.example.com. It keeps your transactional reputation separate from the mail your staff send from the main domain, and it means a DNS mistake cannot break your company mailboxes.

Step 4: keep complaints and bounces low

Gmail asks senders to keep the spam rate shown in Postmaster Tools below 0.3%, and recommends staying under 0.10%. A complaint is a recipient pressing Report spam. For transactional mail the usual causes are:

• Mailing someone who never asked for it: an address typed wrong at sign-up, or a list you imported.
• A message the recipient does not recognise. If the From name, the subject and the first line do not say who you are and why they got it, they press the button.
• Product updates and promotions sent as if they were receipts or alerts. Keep them in a separate stream and give them an unsubscribe link.

A hard bounce indicates a permanent delivery failure. Check the bounce subtype and diagnostic code; it does not always mean the address does not exist. Sending to it again tells mailbox providers you do not clean your list. Stop sending to any address that has bounced permanently, and act on every complaint event by suppressing that recipient.

Step 5: make the message look like what it is

• Send a plain text part alongside the HTML.
• Make the subject match the content. A reset email that says Reset your password is more trustworthy than one that says Important notice!!!
• Use links on your own domain, and avoid link shorteners.
• Keep the HTML clean and the image count low. One large image with little text is a classic spam shape.
• Include your company name and a way to reach you.
• For anything that is marketing or a subscription, add a visible unsubscribe link. Google requires one-click unsubscribe, using the List-Unsubscribe-Post header, from senders above 5,000 messages a day.

Step 6: warm up a new domain and watch it

A domain with no sending history has no reputation. Start with real, expected messages such as your own team's test sign-ups, then increase volume over days rather than blasting thousands on day one. Watch your bounce and complaint events as you go, and register the domain in Google Postmaster Tools to see its spam rate.

If it still goes to spam

• Authentication passes but the message is in spam: the cause is reputation or content. Send a plain, expected message such as a sign-in code from the same domain and compare. If that lands in the inbox, the difference is your content or link choice.
• It only goes to spam for one provider: check that provider's postmaster guidance and look for complaints from its users.
• DKIM fails: the key contents are wrong, there are literal extra quotation marks in the value, there is more than one separate TXT record for the selector, or something changed the message after it was signed. Quoted chunks inside a single TXT record are valid, and long keys often need them, so do not remove them. Compare the published value with what your provider showed.
• SPF fails with too many lookups: SPF allows ten DNS lookups. Remove providers you no longer use.
• DMARC passes on one message but not another: the failing one was sent through a different system that is not signing as your domain, such as a CRM or a help desk.
• Lands in spam right after a DNS change: wait for the records to propagate, then send again and read the headers.

How Boundry handles it

When you add a sending domain to a Boundry project, Boundry returns the DNS records to publish, including DKIM, SPF and DMARC records. The DMARC record it gives you starts with a policy of none, so nothing is enforced yet. It does not include a rua reporting address, so add one to your DMARC record if you want aggregate reports. The domain only counts as verified once Boundry observes every required record, and you can ask for verification again after you publish them.

After each send, the delivery events tell you what happened: email.delivered, email.delivery_delayed, email.bounced with its bounce type and the recipient's diagnostic code, and email.complained when a recipient marks a message as spam. Subscribe a webhook to these events and stop sending to addresses that bounce permanently or complain. Boundry does not publish deliverability rates, and no email service can promise inbox placement, which depends on your domain, your list and your content.

The domains guide lists every record Boundry asks for and how to check them. Read the sending domains guide

Webhooks deliver the bounce and complaint events as they happen. Read the webhooks guide

For what to compare before you pick a provider, including domain verification and webhooks, use the checklist. Read the API selection checklist

If sending is new to you, this explains the request and the delivery events that follow. Read what transactional email is