Your open rate did not drop because the subject line was weak. A meaningful share of your list never received the message at all, and nothing in your campaign report says so plainly.
For most of email marketing's history, deliverability failure meant the spam folder. The message arrived, it went to the wrong place, and the fix was reputation and content. That model shaped every deliverability habit brands have.
It no longer describes what happens to non-compliant bulk mail. Major providers now refuse the message during the SMTP conversation, which means it is never delivered anywhere and never filtered, because filtering happens after acceptance and there was no acceptance.
The requirements themselves are well documented and not especially difficult, and they sit alongside list hygiene as the two halves of deliverability. What is worth your attention is the failure mode, because it disguises itself as something else entirely.
The Three Records
Three DNS records do the work, and each answers a different question about your mail.
| Record | What It Establishes | Common Failure |
|---|---|---|
| SPF | Which servers are authorised to send for your domain | Exceeding ten DNS lookups, which fails silently. Also multiple SPF records. |
| DKIM | A cryptographic signature proving the message was authorised and unmodified | Missing selectors when using several sending platforms; weak key length. |
| DMARC | What to do when SPF or DKIM fail, and ties both to the visible From domain | No record published at all, or alignment failing while both pass individually. |
The minimum published DMARC policy accepted by the major providers is p=none, which asks for no enforcement action and simply enables reporting. That is a low bar and it is a real one: a domain with no DMARC record at all fails.
DMARC alignment. The requirement that the domain a recipient sees in the From header matches the domain validated by SPF or by the DKIM signature. Both mechanisms can pass on their own while referring to a different domain than the one displayed, in which case DMARC evaluation fails. Alignment is why authentication can appear correct in every individual check and still be rejected, and it is the reason the Return-Path, the visible From domain, and the DKIM signing domain should all point at the same authenticated domain.
Reporting indicates DKIM is also how mailbox providers separate reputation across sending platforms, which means each platform sending on your behalf needs its own selector under your domain. A brand running a marketing platform, a transactional service, and a helpdesk needs three, and missing one produces intermittent failures that are miserable to diagnose.
Rejection Is Not Spam Placement
This is the conceptual change, and everything practical follows from it.
A permanent rejection in the 5xx range means the receiving server refused the message during the SMTP conversation. The mail is not retried, it does not reach the inbox, and it does not reach the junk folder. It bounces back to your sending server.
You cannot check whether the message went to spam, because it was never delivered anywhere. There is no folder to look in.
Every provider has its own code for the failure, which is useful because the code tells you what broke.
- Google: 550 5.7.26 for missing or failing authentication.
- Yahoo: 550 5.7.9.
- Microsoft: 550 5.7.515, described as access denied because the sending domain does not meet the required authentication level.
Because the codes sit in the 5.7.x range they are classified as policy and authentication failures rather than mailbox or syntax problems. Which is also why resending produces an identical rejection every time: nothing about the message changed, and the message was never the problem.
The practical implication is that the traditional deliverability instinct, meaning warm the IP, improve the content, reduce the send volume, does nothing at all here. None of those touch a DNS record.
Why It Looks Like A List Problem
The misdiagnosis is predictable and expensive, and it happens because of how the failure surfaces in reporting.
Your sending platform receives a permanent rejection and records it as a hard bounce, which is technically accurate. In your campaign report it appears alongside genuine hard bounces from dead addresses, indistinguishable at a glance.
So the bounce rate climbs, and the natural conclusion is a list quality problem. The brand runs a validation service, suppresses old subscribers, tightens acquisition, and the bounce rate does not improve, because every one of those actions addresses a cause that was not operating.
A consistent stream of rejections drags your overall bounce rate, and a high bounce rate damages reputation with providers that were accepting your mail perfectly well. An authentication failure at one provider therefore degrades deliverability at others, which makes the misdiagnosis worse over time rather than merely unproductive.
The diagnostic that separates the two takes minutes. Group your bounces by receiving domain and read the actual bounce strings. Genuine list decay is scattered across domains with varied messages. An authentication failure is concentrated at one provider with an identical 5.7.x string repeating.
If you see that concentration, stop cleaning the list. The list is probably fine and the DNS is not.
What Microsoft Requires
Microsoft moved last among the major providers and is worth covering specifically because its threshold and scope differ.
Microsoft's own announcement set out the requirements for domains sending 5,000 or more messages per day to its consumer services, and stated the decision to reject messages failing authentication rather than route them to junk. Microsoft also publishes specific guidance for the resulting bounce, which is the page to work from if you are seeing it.
The code is 550 5.7.515. Some secondary coverage renders it as 550 5.7.15, which appears to be a transcription error that has propagated between articles. If you searched the shorter string and found little, that is why. Microsoft's own support page uses 5.7.515.
Sources also disagree on when enforcement began. Most, consistent with Microsoft's announcement, put it at 5 May 2025. One describes enforcement beginning in September 2025. The disagreement matters little now that both dates are past, and it is worth knowing that published timelines on this topic are not uniformly reliable.
Microsoft's guidance recommends raising the DMARC policy gradually, from p=none to p=quarantine and only then to p=reject, rather than jumping to full enforcement. That is sound advice generally: an aggressive policy on a domain whose sending sources are not fully mapped will reject your own legitimate mail.
Who Is Actually In Scope
Two scoping facts that cut in opposite directions, and both get misread.
The threshold is not a general exemption. Reporting indicates Google and Yahoo expect authentication from all senders rather than only bulk senders, with Google requiring SPF or DKIM and Yahoo requiring both, while Microsoft enforces its requirement above the 5,000 per day threshold. So a small sender is below one provider's bar and not below the others'. Google's sender guidelines and Yahoo's sender best practices are the primary references.
Microsoft's rule covers consumer mailboxes only. Reporting indicates it applies to outlook.com, hotmail.com and live.com addresses and does not extend to corporate Microsoft 365 tenant domains. A business-to-business sender mailing company domains may therefore see no rejections at all.
That second point produces a specific false confidence. A B2B brand concludes authentication is optional because nothing broke, then adds a consumer-facing program later and discovers the problem at the worst moment.
One deliverability vendor estimates Microsoft-hosted addresses at fifteen to thirty percent of a typical business-to-consumer list. Treat that as an illustration of scale rather than a benchmark, since vendors in this space sell tooling, and check your own list composition by domain instead. That takes one query and gives you a real number.
Alignment Is The Hidden Failure
The failure that survives a checklist, because every individual component passes.
SPF can pass. DKIM can pass. DMARC can still fail, because DMARC additionally requires that the authenticated domain aligns with the domain the recipient sees in the From header.
Reporting identifies the practical check: the Return-Path, the visible From domain, and the DKIM signing domain should all point at the same authenticated domain. Where a sending platform uses its own domain for the Return-Path and yours in the From header, alignment fails despite both mechanisms working.
This is why domain authentication inside your sending platform matters rather than merely having records somewhere. Platforms provide DNS records specifically so that mail sends from a subdomain you control, which is what makes alignment possible.
If you use a platform's shared sending domain rather than authenticating your own, you inherit its reputation and you cannot align. Both are reasons to complete the domain setup properly rather than skipping it during onboarding.
The Ten Lookup Limit
The single most common silent failure, and it accumulates rather than appearing at once.
An SPF record may require no more than ten DNS lookups to evaluate. Each include mechanism consumes at least one, and nested includes consume more. Exceed the limit and SPF returns a permanent error, which is treated as a failure rather than as an unknown.
The reason this catches established brands specifically is that it accumulates through ordinary growth. A marketing platform, a transactional service, a helpdesk, a CRM, an invoicing tool, and a survey tool each get added to the record over several years, each addition is individually reasonable, and one of them tips the count past ten.
The record that broke your authentication was fine when it was written. Nothing about your mail changed on the day it stopped working; a chain somewhere expanded. This is why deliverability problems appear without an obvious trigger, and why the investigation should start with the record rather than with recent campaign changes.
Two other SPF failures worth checking while you are in there. Only one SPF record may exist for a domain, and publishing a second silently invalidates both. And a broken include chain, meaning a service that has changed its own record or ceased to exist, produces a permanent error that fails everything.
Check the lookup count with any SPF evaluation tool. If you are near the limit, flattening the record or removing services that no longer send for you is the fix, and it is worth doing before you reach ten rather than after.
DMARC Became A Standard
A development from this year that matters more for the direction it signals than for anything you need to do immediately.
Reporting indicates that in May 2026 the IETF published DMARCbis, replacing the earlier specification and establishing DMARC as an official Internet Standard across a set of new documents including RFC 9989.
For a practising email marketer this changes little today. Your records work the same way and your provider requirements are unchanged. What it signals is that DMARC has moved from a widely adopted convention to a formally standardized one, which historically precedes stricter enforcement rather than looser.
The reasonable planning assumption is that p=none satisfies current requirements and will not satisfy requirements indefinitely. Moving toward p=quarantine and eventually p=reject is work worth starting before it is demanded, because doing it properly requires mapping every source that sends mail using your domain, and that mapping takes time.
The order matters. Publish p=none, collect the aggregate reports it generates for several weeks, use them to find sending sources you had forgotten about, fix or authorise each one, and only then tighten the policy. Skipping the observation period is how brands reject their own invoices.
The Ecom Profit Box
Our collection of ecommerce growth resources, including the lifecycle frameworks behind our email work.
Get It FreeBounce Rate Climbing?
If your bounces are concentrated at one provider with a repeating error string, it is not your list. We can look.
Book A CallOne-Click Unsubscribe
The requirement brands resist and should not, because the resistance is based on a misreading of the economics.
Bulk senders must support one-click unsubscribe, implemented through the List-Unsubscribe and List-Unsubscribe-Post headers defined in RFC 8058, and must process requests promptly. The mechanism lets a recipient unsubscribe from within the mail client without visiting your site.
The instinctive objection is that removing friction from unsubscribing increases unsubscribes. It does, and that is the point, because the alternative behavior is worse for you.
A recipient who cannot easily unsubscribe marks the message as spam instead. An unsubscribe removes one address from your list. A spam complaint damages your reputation with that provider for every other recipient on it. Trading a complaint for an unsubscribe is a good trade at almost any volume.
Verify the headers are actually present rather than assuming your platform adds them. View the raw source of a campaign you sent and look for both headers. Most platforms handle it, and configuration differences and custom sending setups produce exceptions.
Complaint Rates And Reputation
Authentication gets you accepted. Reputation decides where the accepted message lands, and the two are separate problems that get conflated.
Providers monitor the rate at which recipients mark your mail as spam, and the widely referenced target is to stay well below a fraction of a percent, with Google publishing guidance on this in its sender documentation. The precise figure matters less than the trajectory: a complaint rate rising over successive sends is a signal to change something before it becomes a placement problem.
Two Microsoft tooling changes from this year are worth knowing if you use its diagnostics. Reporting indicates the Smart Network Data Services portal moved in June 2026, that complaint feedback reports became header-only with message body content removed, and that exact spam trap counts were removed from data reports in July 2026. Diagnostics are becoming less granular, which raises the value of your own list discipline.
The structural point is that complaint rates are driven by acquisition quality and sending cadence rather than by content quality. A list built through incentivised signups or purchased sources complains at a higher rate regardless of how good the email is, and no amount of subject line testing repairs that.
Which is why the durable fix is upstream. Our guide to customer lifetime value covers valuing subscribers properly, and the honest conclusion is usually that a smaller engaged list outperforms a larger indifferent one on revenue as well as on deliverability.
A Fix Order For A Failing Domain
If mail is being rejected, work in this order. It runs from diagnosis to cause rather than from symptom to guess.
- Group bounces by receiving domain and read the strings. Concentration at one provider with a repeating 5.7.x code is authentication. Scatter across domains is list decay.
- Send a test to a healthy mailbox and read the Authentication-Results header. This tells you which of the three is failing, and whether the failure is alignment.
- Check SPF. One record only, under ten lookups, no broken includes.
- Check DKIM. Signing enabled, a selector for every platform that sends for you, adequate key length.
- Check DMARC exists. A published record at p=none minimum. No record is a failure.
- Check alignment. Return-Path, From domain, and DKIM signing domain all pointing at your authenticated domain.
- Verify unsubscribe headers are present in raw source.
- Only then look at content, cadence and list quality. These matter and they are not what produced a 5.7.x rejection.
Most sending platforms expose domain authentication under sending or domain settings, showing each required DNS record with a verification status. Every record showing verified is the baseline, and it does not confirm alignment, so complete step six regardless of what the dashboard says.
Steps one and two take about twenty minutes together and will usually identify the cause. The temptation is to skip them and start changing records, which risks fixing something that was not broken while the actual failure persists.
What Authentication Cannot Fix
An honest boundary, because authentication is being sold in some quarters as a deliverability solution and it is a deliverability prerequisite.
Correct SPF, DKIM and DMARC get your mail accepted. They do not determine where it lands after acceptance. A perfectly authenticated message from a domain with poor reputation, sent to an indifferent list, still reaches the junk folder, and no DNS record changes that.
The factors that decide placement are the ones that always did: how recipients engage, how often they complain, how consistent your sending volume is, and whether people asked to hear from you. Authentication is the entry requirement rather than the competition.
Which suggests the correct sequence. Fix authentication once, properly, because it is a bounded technical task with a clear finish line. Then spend your ongoing attention on list quality and relevance, which is unbounded work that actually moves revenue.
Brands invert this regularly, treating authentication as an ongoing project and list quality as a settled matter. It is the other way round.
The Twenty-Minute Version
Send yourself a campaign email, view the raw source, and read the Authentication-Results header. If SPF, DKIM and DMARC all pass and align to your own domain, this article does not describe a problem you have, and you can stop here. If any of them fail, you have found something that is costing you delivered mail today.
That check is free and most brands have never run it. We do this work for clients as part of our email marketing services, so weigh that recommendation accordingly, and the header check is something you can do yourself this afternoon without involving anyone.
What To Remember
- Non-compliant bulk mail is rejected at SMTP, not filtered to spam. It reaches neither inbox nor junk folder, so you cannot diagnose it by checking where the message landed.
- Rejections are logged as bounces, which makes an authentication failure look like a list quality problem and sends brands off cleaning lists while a DNS record stays broken.
- Each provider has its own code: Google 550 5.7.26, Yahoo 550 5.7.9, Microsoft 550 5.7.515. Some coverage misprints the Microsoft code as 5.7.15.
- Being under 5,000 per day is not a general exemption. Microsoft enforces above that threshold for consumer mailboxes, while Google and Yahoo expect authentication from all senders.
- Alignment fails while SPF and DKIM both pass. The Return-Path, visible From domain, and DKIM signing domain must all point at the same authenticated domain.
- The ten DNS lookup limit on SPF is the most common silent failure, and it accumulates through ordinary growth as each new tool is added to the record.
- Authentication gets mail accepted; reputation decides placement. Fix authentication once as a bounded task, then spend ongoing attention on list quality.
Where This Came From
- Microsoft, Outlook's requirements for high-volume senders, and Microsoft support guidance on the 550 5.7.515 error.
- Google, email sender guidelines, and Yahoo, sender best practices.
- IETF, RFC 9989, part of the DMARCbis document set reported as published in May 2026, and RFC 8058 defining one-click unsubscribe headers.
- Deliverability industry reporting for the per-provider error codes, the ten DNS lookup limit and its failure behavior, DKIM selector requirements across multiple sending platforms, and the alignment requirement covering Return-Path, From domain and DKIM signing domain.
- Deliverability industry reporting for the scope limitation to Microsoft consumer mailboxes rather than corporate Microsoft 365 tenants, for Google and Yahoo expecting authentication from all senders rather than only bulk senders, and for an estimate that Microsoft-hosted addresses represent fifteen to thirty percent of a typical business-to-consumer list. Sources in this category sell deliverability tooling.
- Sources disagree on when Microsoft enforcement began, with most citing 5 May 2025 consistent with Microsoft's own announcement and one citing September 2025, and on the rendering of the error code, with a minority printing 550 5.7.15 rather than 550 5.7.515.