Outlook joins the sender requirements club

Microsoft said in April that high-volume senders to its consumer domains would need SPF, DKIM and DMARC in place, with enforcement beginning on 5 May. Mail that fails is treated less favourably rather than rejected outright, at least to begin with, which means the junk folder rather than a bounce.

This is the same direction of travel Gmail and Yahoo set out the year before, applied to Outlook.com, Hotmail and Live addresses. There is no new standard here and nothing to buy. The three records have been the baseline for years; what changed is that a fourth large mailbox provider now checks them at the door.

If you did the 2024 work properly this is an afternoon with a DNS console, not a project. If you did the 2024 work partially, which is more common, this is the week it becomes visible.

What the check actually covers

Three things, all of which should already be true.

SPF says which servers are allowed to send for your domain. It must list every service that sends on your behalf, and the record has to resolve within the lookup limit that receivers enforce.

DKIM signs the message cryptographically so the receiver can confirm it was not altered and that the signing domain vouches for it. Every sending platform needs its own key published, and keys need to be long enough to be taken seriously.

DMARC ties the two together by telling receivers what to do when alignment fails, and where to send reports. A policy of none satisfies the minimum requirement while telling receivers to do nothing, which is why it is the most common state and the least useful one.

The requirement is presence and alignment, not a particular policy strength. A sender at p=none passes the check. That is the floor, and treating the floor as the goal is how programmes end up here again at the next announcement.

If you did the 2024 work, this is a checklist

The compliance programme we described in the deliverability year-two piece covers everything Microsoft is asking for. Work down it once and move on.

1. Confirm SPF, DKIM and DMARC exist for every domain and subdomain that sends mail, including the ones engineering owns.
2. Check alignment for real traffic rather than for a test send. The visible from-domain must align with either the SPF or DKIM domain, and at least one must pass.
3. Confirm one-click unsubscribe is present in marketing mail, and that it actually unsubscribes people within two days.
4. Pull complaint rates for Microsoft domains specifically, not as part of a blended average.
5. Check the DMARC report mailbox is monitored by a person, or that the reports go into a tool somebody reads.

That is the whole exercise for a well-run programme. The value of the announcement is that it gives you a dated reason to make somebody finish the last twenty per cent.

Where teams actually fail the check

Almost nobody fails because they have no records at all. They fail at the edges, in four recurring places.

Subdomains that were never included. Marketing mail is authenticated and the notifications subdomain that engineering set up two years ago is not. The DMARC policy at the organisational domain applies to it, and nobody has looked at its reports.

Third-party senders nobody inventoried. The survey tool, the helpdesk, the booking confirmation service, the events platform. Each was configured by a different team, and half of them are sending as your domain with no DKIM key of their own.

SPF records over the lookup limit. Every new tool adds an include, and the record quietly stops evaluating at the limit. It looks fine in a text editor and fails at the receiver.

Alignment that passes for the template and fails for the send. A platform signing with its own shared domain, a from-address that was changed for one campaign, a forwarding path in the middle. The only way to see this is in aggregate reports covering real volume.

Work these in order of volume. Pull a DMARC aggregate report for the last thirty days, sort the sending sources by message count, and start at the top. The sources you cannot identify are the actual finding.

Authentication gets you considered, not delivered

Passing the check is necessary and nowhere near sufficient. Authentication tells a receiver who you are. It says nothing about whether the recipient wants the mail, and that is what decides placement.

Sender reputation is still built from complaint rate, engagement, spam-trap hits, bounce behaviour and consistency of volume. Those inputs have not changed and they still carry the weight. A perfectly authenticated sender with a high complaint rate ends up in the junk folder with excellent paperwork.

Placement is also getting more crowded downstream of the inbox decision. The tab and category sorting we looked at when Apple added mail categories is a reminder that arriving in the inbox and being seen are now different problems, with different fixes.

So treat this month's work as maintenance rather than improvement. The improvement work is list hygiene, frequency, relevance and a sunset policy that actually runs.

Make it hold after this week

The reason this keeps being an emergency is that authentication is treated as a project with an end date rather than a system with an owner.

Three changes prevent a repeat:

• Name one owner for sending domains across the whole company, including transactional and product mail. Without it, the next team to buy a tool will add an SPF include and tell nobody.
• Put DMARC aggregate reports into a tool with alerting, and review the sending-source list monthly. New sources appearing is the signal that matters.
• Add authentication to the intake checklist for any new tool that sends mail. Five minutes at procurement saves the week you just spent.

If your policy is still at none, this is also the moment to plan the move through quarantine to reject. Do it on the back of clean reports, in stages, with a quiet period either side. That is the work that makes the next provider announcement a non-event.

What to do this week

• List every domain and subdomain that sends mail, including ones owned outside marketing, and check all three records for each.
• Pull thirty days of DMARC aggregate reports, sort sending sources by volume, and identify every source you cannot name.
• Check your complaint rate for Microsoft consumer domains on its own, and compare it with your Gmail figure to see whether you have a provider-specific problem.