Why does Outlook.com bounce my email with 550 5.7.515?

Outlook.com refused the message because the domain in its From address did not pass the checks Microsoft asks of large senders. SPF and DKIM must both pass, and DMARC must pass for that domain. The owner of the domain fixes it, together with whoever sends the mail. The recipient cannot change it, because the checks are about your domain.

The bounce

Microsoft's help page for this error gives it as:

550 5.7.515 Access denied, sending domain <domain> does not meet the required authentication level.

In your bounce, <domain> is the domain after the @ in your From address. Microsoft explains that "your message was rejected because the domain in your 5322.From email address (also known as the From address or P2 sender) didn't pass the required email authentication level for senders of large volumes of email to Microsoft consumer email services." Those services are Outlook.com and, in Microsoft's words, "related Microsoft consumer email services (Hotmail, Live.com, MSN, etc.)".

What Outlook.com checked

Microsoft's page says the rule covers a domain when "You send 5,000 or more email messages to Microsoft consumer email services" and "All of the messages use the same domain in the 5322.From address." The page names no time period. Microsoft's announcement says "For domains sending over 5,000 emails per day". From then on, every message from the domain has to meet three requirements:

SPF passes. The server that sent the message is listed in the SPF record of the envelope sender's domain. Microsoft: "Both SPF and DKIM checks must pass."
DKIM passes. The message carries a DKIM signature that verifies.
DMARC passes. The domain has a DMARC record, and SPF or DKIM, at least one, is aligned with the From domain. A policy of p=none is enough: Microsoft's own example is v=DMARC1; p=none.

The first point catches many senders out. DMARC passes as soon as DKIM passes and aligns, but Outlook.com also wants SPF to pass. A service that signs with your domain but is missing from your SPF record passes DMARC everywhere and still bounces here. What Google, Yahoo and Microsoft ask of senders sets out Microsoft's rules beside Gmail's and Yahoo's.

The announcement gave 5 May 2025 as the day rejection with this error would start. The bounce does not say how many messages Microsoft counted for your domain. Whatever your volume, the fix is the same three checks.

Who has to fix it

The owner of the domain in the bounce, usually you. The change happens where the mail is sent from, and in your domain's DNS. Check each place your mail leaves from:

Your email provider, such as Microsoft 365 or Google Workspace, for the mail you write yourself. Turn on DKIM for your domain there, and keep the provider's include in your SPF record.
A sending service, such as a newsletter, invoicing or web shop platform, for mail it sends as you. Microsoft: "Verify the SPF record for your domain includes the IP address or include values required by the service." The service should also sign with your domain, which services call custom DKIM or domain authentication.
Your internet provider's or web host's mail server, when your mail program sends through it. Ask them for the SPF include for their servers, and whether they sign outgoing mail with DKIM, preferably with your domain.

The records

For example.com, sending through Microsoft 365 and one newsletter service, the records could look like this:

example.com                TXT    v=spf1 include:spf.protection.outlook.com include:_spf.newsletter.example -all
s1._domainkey.example.com  CNAME  s1.dkim.newsletter.example
_dmarc.example.com         TXT    v=DMARC1; p=none; rua=mailto:k3x9p2m7q4w8@rep.mailmoni.com

SPF lists every server and service that sends as you, each with its include. A domain has one SPF record, so add to it rather than publishing a second one. Fix your SPF record shows how.
DKIM is the key each service gives you, under the selector it names. Microsoft 365 and Google Workspace each give you their own. Set up DKIM for a sending service has the steps.
DMARC with p=none is enough for Outlook.com. Its rua address receives the reports that show whether the fix worked. Publish your DMARC record has the steps.

What it looks like in your DMARC reports

Aggregate reports show the same checks for every source that sends as you, in a row for each sending address and each set of results its mail got. policy_evaluated holds the DMARC result for your domain, and auth_results holds the plain SPF and DKIM results with the domain each one checked (RFC 9990, section 3.1.1.9). A source that Outlook.com refuses with 5.7.515 can look like this, although it passes DMARC:

<row>
  <source_ip>192.0.2.10</source_ip>
  <count>40</count>
  <policy_evaluated>
    <disposition>none</disposition>
    <dkim>pass</dkim>
    <spf>fail</spf>
  </policy_evaluated>
</row>
<identifiers>
  <header_from>example.com</header_from>
</identifiers>
<auth_results>
  <dkim>
    <domain>example.com</domain>
    <selector>s1</selector>
    <result>pass</result>
  </dkim>
  <spf>
    <domain>example.com</domain>
    <result>fail</result>
  </spf>
</auth_results>

DKIM passes and aligns, so DMARC passes. SPF fails, because the sending address is not in the SPF record. Outlook.com asks for both, so this mail bounces. The other common row fails DMARC outright: dkim and spf are both fail under policy_evaluated, while auth_results shows them passing for the service's own domains. 550 5.7.509 shows that row. For mail you send to Outlook.com directly, a failing SPF means the service is missing from your SPF record: add it.

In Mailmoni, a source like the one above passes DMARC, and its explanation says that SPF fails, which happens when mail is forwarded or when the service is missing from your SPF record.