ES EN
Log in Start free
Blog · Email

Seven SPF, DKIM and DMARC mistakes that send your email to spam

Gmail and Outlook now reject badly authenticated email. These are the seven most common mistakes in a domain's records, how to spot them and how to fix them.

4 min read Leer en español

"My emails land in spam" is almost never about the content. It is almost always a badly set DNS record that nobody looks at because the email "goes out". It does go out. It just does not reach the inbox.

And since 2024 this matters more. Gmail and Yahoo have required authentication from high-volume senders since February 2024. Outlook has done the same since 5 May 2025. And Gmail started tightening rejections in November 2025. Email going out is no longer enough.

Three records, one sentence each

  • SPF says which servers may send email on behalf of your domain.
  • DKIM signs every message with a key whose public half is in your DNS. It proves nobody changed the message on the way.
  • DMARC says what to do when SPF and DKIM fail, and requires at least one of them to match the domain the recipient sees in "From:".

1. Two SPF records

It happens when a new service is signed up and its guide says "add this SPF record". Someone adds it without noticing there was one already. A domain can only have one record starting with v=spf1. With two, the result is a permanent error and SPF stops counting.

Fix: one single record that combines everything. For example:

v=spf1 include:_spf.google.com include:sending-service.com ~all

2. More than ten lookups

Every include:, a, mx or redirect makes the receiving server run a DNS lookup. And every include can have its own includes inside. The standard sets a limit of ten. Go over it and SPF returns a permanent error, even if the record looks perfect at a glance.

Fix: remove the services you no longer use, which is usually most of the problem. If it still does not fit, send bulk email from a subdomain with its own SPF.

3. Ending in +all

The end of the record says what to do with servers that are not on the list. ~all marks them as suspicious, -all rejects them. +all accepts them all: anyone on the internet can send in your name and pass SPF. It is often left that way "to make it work" during a test, and it stays forever.

Fix: ~all while you check nobody is missing, -all once you are sure.

4. Forgetting who actually sends

Office email goes out through Google Workspace or Microsoft 365, and that one is in SPF. But the website's contact form (from the hosting server), the e-invoicing system, the CRM and the newsletter tool also send email with your domain. If one of them is neither in SPF nor signing with DKIM, its email fails.

Fix: list everything that sends with your domain. DMARC reports (point 7) tell you exactly who sends and from where.

5. DKIM never turned on

Google Workspace and Microsoft 365 sign your email even if you set nothing up, but with their domain, not yours. That signature is valid, but it does not match your "From:", so it does not count for DMARC. You have to turn DKIM on in their admin panel and publish the key in your DNS.

Fix: in Google Workspace, under email authentication in the admin console; in Microsoft 365, in the Defender portal. Both give you the record to publish.

6. 1024-bit DKIM keys

They work, but they are short by now. Google recommends 2048-bit keys if your DNS provider supports them. And if the key has not changed in years, this is a good time to rotate it.

Fix: generate a new 2048-bit key with a new selector, publish it, switch signing to it and retire the old one a few days later.

7. No DMARC, or p=none forever

Without DMARC, large providers are missing the last piece and your domain is easy to spoof. With p=none you meet the minimum Gmail and Outlook require, but you protect nothing: it is a "watch only" policy. The problem is staying there without watching.

The record lives at _dmarc.yourdomain.com and looks like this:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

The rua part is the important one: it is where providers send you a daily report of who sends with your domain and whether it passes.

Fix: start at p=none with rua, read the reports for a couple of weeks, fix what fails (points 4 and 5) and move up to p=quarantine and then p=reject.

What Gmail and Outlook require today

From anyone sending around 5,000 emails a day or more to their users:

  • SPF and DKIM set up.
  • DMARC published, at least with p=none.
  • The "From:" domain aligned with the SPF or the DKIM domain.
  • One-click unsubscribe for marketing email.
  • Gmail also asks to keep spam complaints below 0.3%.

Even if you send far less, Gmail requires at least SPF or DKIM from everyone. And what is mandatory for the big senders is what ends up separating email that arrives from email that does not.

Sources

Check it on your site now, free and without an account.

Open the tool

Keep reading

Agencies

What we learned watching 287 client websites

MonitoraWeb was born inside an agency. These are the real numbers from our portfolio, the half that was dead without anyone knowing, and the rules we set so we stop paying for alerts about sites that no longer exist.

 Domains

.pe domains don't say when they expire. How to watch them anyway

NIC.PE does not publish the expiry date of .pe domains through any channel. We checked on its own WHOIS server. This is what you can watch instead.

 Certificates

200, 100 and 47-day certificates. What changes for your site

Since 15 March 2026 no public certificate lasts more than 200 days, and in 2029 it will be 47. If any of yours is renewed by hand, here is the schedule and what is going to break.