For years, bulk email that failed authentication checks landed in spam. The largest mailbox providers issued warnings, then grace periods, then enforcement notices, while the practical consequence remained the same: your email arrived somewhere, even if not in the inbox. That era is over.

Google moved first, with Gmail beginning to reject non-compliant bulk mail outright in late 2024. Yahoo followed a similar trajectory. Microsoft announced its requirements in April 2025 and began active enforcement in May 2025, with the rejection rate escalating through late 2025 and into 2026. As of today, all three providers permanently reject bulk email that fails to meet their authentication requirements. The messages are not delivered anywhere. They do not appear in any folder. They return a hard bounce.

What each provider now requires

The core requirement is the same across all three platforms, and it builds on standards that have existed for years: SPF, DKIM, and DMARC must all be in place and correctly aligned.

SPF (Sender Policy Framework) is a DNS record that specifies which mail servers are authorised to send email on behalf of your domain. A misconfigured or missing SPF record means receiving servers cannot verify that your sending IP is authorised.

DKIM (DomainKeys Identified Mail) signs each outgoing message with a private key. The corresponding public key is published in DNS. Receiving servers verify the signature to confirm the message has not been altered in transit and that the signing domain matches the sender.

DMARC (Domain-based Message Authentication, Reporting and Conformance) ties SPF and DKIM together by specifying what should happen when messages fail authentication. Even a DMARC policy of p=none, the most permissive setting that takes no enforcement action, is now required by Gmail and Microsoft for bulk senders. A missing DMARC record is itself a rejection trigger for some providers.

Microsoft’s specific requirements apply to organisations sending 5,000 or more messages per day to Outlook.com, Hotmail.com, and Live.com addresses. Google’s Gmail threshold is the same. These providers define bulk volume by what reaches their infrastructure, not by what you think you send. If you run a SaaS platform, an e-commerce operation, or any service with automated email, you likely cross this threshold without realising it.

Microsoft’s 550 5.7.515 error

Microsoft returns the error code 550 5.7.515 when it rejects mail for authentication failure. The full bounce message reads: “Access denied, sending domain does not meet the required authentication level.” Unlike a 4xx temporary error that causes the sending server to retry, a 550 error is permanent. Your mail transfer agent marks the message as undeliverable and stops attempting delivery. No retry will succeed until the underlying DNS configuration is corrected.

The practical impact for organisations with misconfigured authentication is a bounce storm that is silent from the recipient side. Your system sends the message. Microsoft rejects it. You get a non-delivery report if your email infrastructure is configured to surface them. The recipient gets nothing and has no way of knowing they were expected to receive something.

This is meaningfully worse than the previous behaviour where non-compliant mail went to spam. A message in spam can be retrieved. A hard-rejected message is gone, and the sender’s bounce rate increases in ways that can trigger additional deliverability penalties down the line.

Authentication alone does not guarantee inbox placement

Passing SPF, DKIM, and DMARC is now the floor, not the ceiling. Analysis from deliverability researchers has found that fully authenticated mail, with valid SPF, DKIM, and DMARC records, still experiences spam placement rates above 30 percent in some sender categories. This is because mailbox providers layer engagement signals on top of authentication checks.

After authentication confirms you are who you claim to be, providers evaluate whether the people you email actually want what you send. Engagement metrics including open rate, click rate, reply rate, delete-without-read, and spam complaint rate all feed into placement decisions. The practical ceiling on spam complaint rate for Gmail is 0.3 percent before enforcement begins, with 0.1 percent as the recommended operational target.

One-click unsubscribe, formally defined in RFC 8058, is now a mandatory requirement for bulk senders at Gmail and Microsoft. Gmail surfaces this as a native button above the email header. The intent is to give recipients an alternative to the spam button, because spam complaints damage sender reputation in ways that processed unsubscribes do not. Bulk senders without a compliant List-Unsubscribe header face a structural disadvantage in engagement scoring independent of their authentication status.

What European organisations are getting wrong

The most common authentication failures seen in European organisations sending bulk email fall into a few repeating patterns.

SPF record bloat. SPF has a hard limit of 10 DNS lookups. Records that include multiple third-party mail service providers, each of which adds further lookups through their own includes, routinely exceed this limit without the sender realising it. An SPF record that exceeds 10 lookups is treated as a permerror, which is effectively a failed authentication check.

DKIM missing from transactional email. Marketing email sent through a dedicated platform such as Mailchimp, Klaviyo, or Brevo is usually DKIM-signed by the platform. Transactional email sent through a separate SMTP relay or directly from application infrastructure is frequently not. Password reset emails, order confirmations, and notification alerts sent without DKIM often come from domains that have correctly configured DKIM for marketing but not for transactional flows.

DMARC at p=none with no monitoring. A p=none policy takes no action when authentication fails, which means it meets the minimum requirement but provides no enforcement and generates aggregate reports that are being sent somewhere and ignored. Organisations that set DMARC to p=none and never reviewed the reports may be unaware that third parties are sending mail that appears to come from their domain, or that their own authentication is failing in ways the reports would reveal.

Subdomains left uncovered. DMARC policy inheritance from the organisational domain to subdomains is not universal. A DMARC record on example.com does not automatically protect mail.example.com or notifications.example.com. Sending infrastructure that uses subdomains needs explicit authentication configuration for each sending subdomain.

The business case for getting this right

For businesses that rely on email as an operational channel, authentication failure is not primarily a deliverability problem. It is a revenue problem. An e-commerce order confirmation that bounces means a customer who assumes something went wrong with their purchase. A password reset that never arrives means a lost login and a support ticket. A contract or invoice that hits a 550 error means a payment delay or a customer who assumes the communication was never sent.

European organisations also face a GDPR dimension. Sending email to individuals who have not consented, or to lists that include contacts from data sources that cannot demonstrate valid legal basis, compounds deliverability problems with regulatory exposure. DMARC reporting can reveal unexpected sending sources that may include third-party tools sending personal data without appropriate authorisation.

Getting email authentication right in 2026 means: correctly configured SPF with lookups within the limit, DKIM signed for every sending source including transactional flows, DMARC at a policy level that matches your risk tolerance, active monitoring of aggregate reports, and compliant unsubscribe handling. None of these are technically complex in isolation. They do require a systematic audit of every service that sends email on behalf of your domain.

If your organisation is experiencing email delivery failures, wants to audit its current SPF, DKIM, and DMARC configuration, or needs help building a compliant sending setup across marketing and transactional email, contact Excello Digital. We help European organisations get their email authentication right and keep it right as sending infrastructure evolves.