Why emails suddenly start failing Gmail, Yahoo, or Outlook

Delivery problems rarely arrive with a clean label.

Someone says a password reset did not arrive. A customer says invoices are going to spam. A campaign report shows more deferrals than usual. Then someone opens the headers and finds the words nobody wanted to see: SPF fail, DKIM fail, DMARC fail, unauthenticated, not aligned.

Gmail, Yahoo, and Outlook have all become less forgiving for senders that skip the basics. The exact handling depends on sender type, volume, reputation, and message category, but the direction is clear: authentication problems now turn into visible delivery problems faster than they used to.

Check the receiver rules first

For bulk senders, Gmail’s sender FAQ points to failures or spam placement for missing or broken SPF, DKIM, DMARC, PTR, TLS, and message-format requirements. Gmail also calls out one-click unsubscribe for promotional mail and spam-rate thresholds.

Yahoo’s sender requirements say all senders should authenticate with at least SPF or DKIM. Bulk senders need both SPF and DKIM, a valid DMARC policy of at least p=none, and DMARC alignment with either SPF or DKIM.

Microsoft has also published Outlook.com requirements for high volume senders. If Outlook traffic matters to you, do not assume yesterday’s setup is still enough.

Those pages change over time. Treat them as operating docs, not launch docs.

Then check what changed

Most sudden failures come from a recent change that felt unrelated.

A vendor migration can change sending IPs. A DNS cleanup can remove an SPF include nobody recognized. A new marketing tool can send from the main domain before DKIM is configured. A domain can move between DNS hosts and lose a TXT record. A help desk can switch its bounce domain and break alignment.

Start with a short question: “What changed in the last week?”

Then scan the domain as it exists now. Do not rely on the setup guide you followed months ago.

SPF problems

SPF fails when the sending IP is not authorized by the domain’s SPF record. It also fails in less obvious ways:

• more than one SPF record exists
• the SPF record has too many DNS lookups
• a vendor include was removed
• the sender uses a different envelope domain than expected
• the record ends with a permissive mechanism such as +all

The fix is not always “add more to SPF.” Bloated SPF records become their own failure. Sometimes the cleaner answer is to move a sender to DKIM alignment instead.

DKIM problems

DKIM fails when the message is not signed, the public key is missing, the selector is wrong, or the message was changed after signing.

The common business version is simpler: someone enabled a sender but skipped the DNS step. The vendor says “add this TXT record.” The record never lands in DNS, lands in the wrong zone, or gets deleted during cleanup.

If one mail stream passes DKIM and another fails, check the selector. DKIM is per sender and often per selector. A valid Google Workspace DKIM record does not prove your billing tool is signing correctly.

DMARC alignment problems

DMARC passes when SPF or DKIM passes and aligns with the visible From domain. This is where a lot of “but SPF passed” arguments fall apart.

If SPF passes for a vendor’s bounce domain, but the From address uses your domain, DMARC may still fail. If DKIM signs with the vendor’s domain, but the From address uses yours, DMARC may still fail.

Alignment is the difference between “some authentication happened” and “this mail is authenticated for the domain the recipient sees.”

Do the boring checks

When mail starts failing, check these before guessing:

• SPF: one record, valid syntax, lookup count under the limit, no unsafe all mechanism
• DKIM: expected selectors exist and use acceptable key sizes
• DMARC: record exists, policy is valid, report address still works
• MX: receiving records still exist for the domain
• PTR and forward DNS: especially for senders using dedicated IPs
• TLS and unsubscribe headers: for bulk and promotional streams

You may still have a reputation problem after all of that. Authentication is not the whole delivery story. It is just the part you can usually verify and fix quickly.

That is why it belongs at the front of the incident checklist.