العربية Talk to us

Why your business email goes to spam, and the four records that fix it

Published 21 August 2026

Why do my emails go to spam?

Almost always because the receiving provider cannot verify that your domain authorised the message. Google, Yahoo and Microsoft now require SPF, DKIM and DMARC on bulk mail, and require the visible From domain to match the authenticated one. Mail that fails those checks is increasingly rejected at the server rather than delivered to a spam folder.

Why your business email goes to spam, and the four records that fix it

There is a belief that spam placement is a content problem, and that the fix is writing differently, using fewer images, or avoiding certain words. For most business senders in 2026 that is not what is happening.

What is happening is authentication, and the consequence has changed. Non-compliant mail is now rejected at the SMTP level rather than filed in spam. It bounces. The sender sees a failure code, the recipient never sees anything at all.

The gap is measurable. Compliant senders average around 89% inbox placement. Non-compliant senders see 22 to 34% of their mail routed to spam, which is a three to sevenfold penalty on the same content.

The four records, in the order they matter

SPF lists which servers are allowed to send for your domain. Publish one, and keep it accurate: every service that sends on your behalf, and nothing that does not.

DKIM signs each message with a private key so the receiver can verify with your published public key that the message was not altered. SPF says who may send; DKIM proves who did.

DMARC ties the first two to the domain the recipient actually sees, and tells receivers what to do when the check fails. This is where most setups quietly fail. You can hold a valid SPF record and a valid DKIM signature and still fail DMARC, because DMARC also requires alignment: the domain in the visible From header has to match the domain that SPF or DKIM authenticated. Misalignment is what produces 421-4.7.32 from Gmail and 550 5.7.515 from Microsoft.

MTA-STS is the one almost nobody publishes. It tells sending servers that mail to your domain must travel over TLS, and refuses the delivery if it cannot. It protects mail arriving at you rather than mail leaving you, which is why it is skipped, and it is also the difference between encryption you hope for and encryption you require.

The thresholds you are actually measured against

If your domain sends 5,000 or more messages a day to Gmail, Yahoo or Outlook users, all three require the full set. Beyond authentication, two numbers matter:

  • Spam complaint rate below 0.3%. Exceeding it triggers throttling immediately, not eventually.
  • One-click unsubscribe that works, and that removes the address promptly.

Below 5,000 a day you are not formally in scope, and the checks still run. The difference is how quickly you find out.

The order to fix it in

  1. Publish SPF, and list every sender. Marketing platform, CRM, invoicing system, the lot.
  2. Sign with DKIM on every one of those senders, not only the main mail server.
  3. Publish DMARC at p=none first and read the reports for a fortnight. They will name senders you had forgotten.
  4. Fix alignment on anything the reports show failing.
  5. Move DMARC to p=quarantine, then to p=reject once the reports are clean.
  6. Publish MTA-STS, in testing mode first, then enforce.

The step people skip is the fortnight at p=none. It is the only step that tells you the truth about what is sending as you, and it costs nothing but patience.

Why we write about this

We run our own mail infrastructure, with all four records in place and MTA-STS in enforce mode. Not because it is interesting, but because a client whose invoices bounce has a problem no amount of good copy will solve.

Sources

Questions we get asked

We send fewer than 5,000 a day. Do these rules apply to us?

You are outside the formal bulk sender threshold, and the authentication checks still run on every message. What changes below the threshold is enforcement, not evaluation: problems show up as gradual, unexplained drops in delivery rather than as an immediate block. That is harder to notice, not easier to survive.

Our SPF and DKIM are set up but mail still fails. Why?

Almost certainly alignment. DMARC does not only ask whether SPF or DKIM passed, it asks whether the domain they authenticated matches the domain in the From header your recipient sees. A marketing platform sending as you but authenticating as itself passes SPF and fails DMARC, which is exactly the case that looks fine in every individual check.

Is MTA-STS worth publishing?

It is the smallest of the four and the one with the clearest answer: it turns TLS on mail arriving at your domain from something you hope for into something you require. Publish it in testing mode first. Moving straight to enforce means any sender that cannot negotiate TLS stops reaching you, and you want to find those in a report rather than in a complaint.

Start with the problem.

A short conversation is usually enough to tell whether this is something we should be doing for you.

Talk to us