Your Emails Land in Spam: Gmail, Outlook and Yahoo Sender Requirements

You send an invoice and the client says nothing arrived. Later it turns out the message is sitting in their Gmail spam folder, or it was rejected outright. This happens far more often now, because Gmail, Yahoo and Outlook have introduced strict technical requirements for senders, and unauthenticated mail is simply refused. Here is what those requirements are, how to diagnose the problem, and how to put your company mail in order.

What the problem looks like

The typical symptom is that messages reach corporate addresses without trouble, while recipients on Gmail or Hotmail find them in spam. Sometimes you get a bounce with a code starting with 550, or Gmail shows a warning that the sender could not be verified. If such cases suddenly multiplied over the last few months, the cause is almost certainly your domain's authentication setup.

What Gmail, Yahoo and Outlook require

Since February 2024 Gmail and Yahoo require every sender to have SPF or DKIM, valid forward and reverse DNS (PTR) for the sending IP, TLS for transmission and RFC 5322 compliant formatting. The share of messages marked as spam must stay below 0.3%, and in practice you should aim for under 0.1%.

Bulk senders delivering more than 5,000 messages a day to Gmail need both SPF and DKIM, a DMARC record with at least p=none, and alignment between the From domain and the authenticated domain. Marketing mail must support one-click unsubscribe under RFC 8058 (the List-Unsubscribe-Post header), and unsubscribe requests must be honoured within two days. In November 2025 Gmail moved to stricter enforcement and began rejecting non-compliant traffic. Microsoft followed on 5 May 2025 for Outlook.com, Hotmail and Live senders above 5,000 messages a day, returning non-compliant mail with error 550 5.7.515.

How to check message headers

Send a test message to a Gmail address, open it and choose "Show original" from the three-dot menu. The top of the page shows SPF, DKIM and DMARC results, followed by the full Authentication-Results header. All three should read pass, and any fail, softfail or none points to where the problem is.

Authentication-Results: mx.google.com;
  dkim=pass header.d=kompaniya.uz header.s=dkim;
  spf=pass smtp.mailfrom=info@kompaniya.uz;
  dmarc=pass (p=NONE) header.from=kompaniya.uz

What the DNS records look like

SPF lists the servers allowed to send on your behalf, DKIM signs each message with a key published in DNS under a selector name, and DMARC tells receivers what to do when checks fail while sending aggregate reports to the rua address. A domain must have only one SPF record, so extra services are added with include rather than a second record.

kompaniya.uz.              TXT  "v=spf1 a mx ip4:203.0.113.10 ~all"
dkim._domainkey.kompaniya.uz.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
_dmarc.kompaniya.uz.       TXT  "v=DMARC1; p=none; rua=mailto:dmarc@kompaniya.uz; adkim=r; aspf=r"

For mail domains hosted on sayt.uz servers, SPF and DKIM are configured automatically, but if your DNS is managed elsewhere you need to copy these records there.

Tightening DMARC step by step

1. p=none — nothing is blocked, reports show who is sending mail as your domain.
2. p=quarantine — failing mail goes to spam, and you can start with pct=25.
3. p=reject — forged mail is refused outright and your domain is protected from spoofing.

A real example: why invoices landed in spam

A wholesale company in Tashkent sent invoices through its website form, and each message went out as "From: client@gmail.com", in the client's own name. The domain had no DKIM. Gmail treated these messages as forgeries of gmail.com. The company switched the form to "From: noreply@kompaniya.uz" with the client in "Reply-To", enabled DKIM, and within a week the invoices were reaching inboxes again.

The classic mistake: forms sending as the visitor

Many CMS plugins put the visitor's address into the From field so that replying is convenient. That means sending as someone else's domain, and domains with strict DMARC will have such mail rejected. Always use your own domain in From, put the visitor in Reply-To, and send through authenticated SMTP.

Keep marketing mail separate

Newsletters attract more complaints, which drags down the reputation of your main domain and your business mail with it. Use a subdomain such as news.kompaniya.uz or a dedicated mailing service.

Blocklists, forwarding and Microsoft blocks

A server IP can end up on blocklists such as Spamhaus, so check it regularly. Forwarded mail breaks SPF, which the server fixes with SRS. Microsoft sometimes blocks a whole server IP, returning error S3140, and that is resolved at the server level.

Reading the error message

550 5.7.515 Access denied, sending domain kompaniya.uz does not meet the required authentication level.
550-5.7.26 This mail has been blocked because the sender is unauthenticated.

Code 550 means a permanent rejection and 5.7.x points to a security policy. The first line comes from Outlook, the second from Gmail, and in both cases the fix starts with your DNS records.

Testing and warming up

After changes, run a test through a service like mail-tester. From a new domain, increase volume gradually over several weeks. If you cannot find the cause, contact sayt.uz support and the team will check your records and bounce codes.