How to fix “550 5.7.515 Access denied” from Outlook and Hotmail

If you’ve started seeing bounces like this when emailing Outlook, Hotmail or Live addresses, you’re not alone:

550 5.7.515 Access denied, sending domain [yourdomain.co.uk] doesn't meet the required authentication level.

It means Microsoft has rejected your email outright. It hasn’t gone to junk; it hasn’t been delivered at all. The good news is that the fix is almost always a DNS change you can make in under an hour.

Why Microsoft is rejecting your email

Since 5 May 2025, Microsoft has enforced authentication rules for anyone sending more than 5,000 emails a day to its consumer mailboxes (outlook.com, hotmail.com and live.com, including hotmail.co.uk and live.co.uk). Microsoft originally said non-compliant mail would go to junk. Instead, it chose to reject it, and the 5.7.515 error is the result.

To get through, your sending domain needs all three of these:

• SPF must pass: the server sending your email must be listed in your domain’s SPF record.
• DKIM must pass: your email must carry a valid DKIM signature for your domain.
• DMARC must exist: at least p=none, and it must align with SPF or DKIM (ideally both).

The 5,000-a-day threshold is Microsoft’s target, but Microsoft’s own support forums are full of small businesses and individuals hitting this error too. Treat these rules as the minimum for anyone emailing Microsoft customers.

Step 1: Check what’s actually missing

Before you touch DNS, find out which of the three checks is failing. You can do this two ways:

1. Run our free checker. Enter your business email at InboxWizards Free Tools and we’ll check your SPF, DMARC and BIMI records in seconds.
2. Read the headers of a sent email. Send a message to a Gmail or Outlook address you own, open the original message/headers, and look for the Authentication-Results line. You want spf=pass, dkim=pass and dmarc=pass.

Step 2: Fix SPF

Your domain should have one TXT record starting v=spf1, listing every service that sends email as you: your mailbox provider (Microsoft 365 or Google Workspace), your email marketing platform, your CRM, your helpdesk, your invoicing tool and so on.

v=spf1 include:spf.protection.outlook.com include:_spf.your-email-platform.com ~all

(Replace the second include: with the value your email platform gives you. Each provider publishes its own.)

Common mistakes we see:

• Two SPF records. If you have more than one v=spf1 record, SPF fails for everything. Merge them into one.
• Too many lookups. SPF allows a maximum of 10 DNS lookups. Pile up enough include: entries and SPF breaks with a PermError.
• A forgotten sender. A newer tool (a CRM or booking system, say) sending as your domain but not listed in SPF.

Step 3: Fix DKIM

DKIM is set up inside each sending platform, not just in DNS. In Microsoft 365, Google Workspace, Mailchimp, Klaviyo, HubSpot and most others, there’s a “domain authentication” or “DKIM” setting that gives you records (usually CNAMEs) to add to your DNS. Add them, then go back and click verify or enable. That last click is the step most people miss.

The important detail: DKIM must be signed with your domain. If your platform signs with its own domain (for example d=sendingplatform.com), DKIM technically passes but won’t align with DMARC.

Step 4: Add a DMARC record

If you have no DMARC record, add a TXT record at _dmarc.yourdomain.co.uk:

v=DMARC1; p=none; rua=mailto:[email protected]

p=none is enough to satisfy Microsoft (and Google and Yahoo). The rua address receives daily reports showing every service sending as your domain and whether it passes, which is the information you need to move to a stronger policy later. (Our guide to why DMARC matters covers this in more depth.)

Step 5: Retest and resend

DNS changes can take anything from a few minutes to a few hours to take effect. Once they have, send another test email to an Outlook or Hotmail address and check the headers again. When SPF or DKIM passes and aligns with your From domain, and DMARC passes, the 5.7.515 bounces stop.

Still bouncing?

If everything passes and you’re still being rejected, the cause is usually one of these:

• A third-party platform sending as your domain that you didn’t know about (DMARC reports reveal these).
• Alignment: SPF passes for the platform’s bounce domain but not yours, and DKIM is signed with the platform’s domain.
• Forwarding, which can break SPF. DKIM is what survives forwarding, so make sure it’s in place.