How to Fix Error 550 5.7.509: Access denied in Exchange Online

Error 550 5.7.509 relates to DMARC message authentication and is received as a bounce back when you send an email and the receiver rejects your email due to DMARC failing. The exact error will look like the following:

550 5.7.509: Access denied, sending domain yourdomain.com does not pass DMARC verification and has a DMARC policy of reject

In this tutorial, I am going to show you how you can fix the Exchange Online error with ease.

How does DMARC work?

DMARC stands for Domain-based Message Authentication, Reporting & Conformance and is a method and process for aiding mail servers in determining whether a message is legit. The DMARC policy configured on the sending domain will then aid the receiving mail server in how they should handle incoming mail that fails the DMARC check. 

Below is a diagram which helps to visualise the DMARC authentication process:

How DMARC works
How DMARC works

To summarise the above image:

1. A user first sends a new mail message, the sending mail server will process and send this message to the recipient’s mail server based on the MX record configured on the recipient’s domain in public DNS.

2. The recipient’s mail service will then perform 3 different checks on the domain once it receives the mail:

    • Firstly, the recipient’s server will check if the IP address of the sender server matches that of the authorised servers within the SPF record in public DNS.
    • Secondly, the recipient’s server will match the encrypted DKIM signature in the message header with the DKIM record in public DNS.
    • Lastly, the recipient’s server will check the DMARC record for the sender’s domain in public DNS. This record will determine how to handle the message if ether of the first or second checks fails.

3. Thirdly, if both the SPF and DKIM checks pass, DMARC will result in a pass and the mail message will be sent to the recipient’s mailbox. Should DMARC result in a fail, based on the configured DMARC policy in the sender’s public DNS, the message will either be sent to quarantine or rejected with an NDR sent to the sender, containing error 550 5.7.509.

4. Lastly, if the sender’s DMARC record is configured for aggregated or forensic reporting, a mail will be sent in either XML or plaintext containing information on the mail message to the desired destination (Usually a dedicated mailbox or DMARC analysis platform). 

EasyDMARC have a simple an easy to use tool for DMARC reporting, check them out!

Why did I receive error 550 5.7.509?

The reason you have received error 550 5.7.509 is that you are not properly authenticated to send on behalf of your domain. For example, if your domain is ourcloudnetwork.com and your email address is [email protected]. The mail service you are using, such as Microsoft 365, does not match the DKIM or SPF record configured in your public DNS provider (such as GoDaddy for example) and hence returns as a fail. 

This doesn’t mean it wasn’t once configured correctly, it could mean that something has changed. As such, you should review who has access to make changes to your public DNS records, as often third-party providers will request access (such as web developers) when in reality, this access should be with your trusted IT provider only.

As well as this, you have also received this error message as you have configured your DMARC policy with the Reject setting. This is the strictest approach, where messages will be rejected with error 550 5.7.509 should the policy not pass.

How to fix error 550 5.7.509

To resolve this error I will highlight all the necessary steps you should perform in your environment so email is correctly being marked as legit and passing DMARC checks. Follow the steps below:

Step 1: Identify your sending server

Sometimes, especially if you not were involved in the setup of your organisation’s mail solution, the sending server is not the same as the server you use to access your email. For example, the below diagram depicts a case where the sender is using Exchange Online for their primary email server. In Exchange Online a send connector is configured which directs outbound mail to a 3rd party mail filtering service before it is forwarded to the recipient.

Outbound mail flow
Outbound mail flow

It is then crucial that this mail filtering service is correctly configured for SPF and DKIM, which would allow DMARC to pass. I recommend you turn your mail flow into a diagram, making it simple for whoever else needs to familiarise themselves with it.

Step 2. Review and fix your SPF record

Once you are familiar with your mail flow, the first thing to check is that your SPF record is correctly configured with the mail service that is sending on behalf of your domain. If you want to, you can test if your SPF check currently passes by sending an email to a service which will not reject your mail by default (such as a personal GMail account) and viewing the message properties. Here is an example from a test email I sent myself from a spoofing service:

SPF fail example
SPF fail example

There are a few methods to check how your SPF record is configured. The quickest way is to use the nslookup tool in the command line on your workstation. Try running the following command and change ‘ourcloudnetwork.com’ to your email domain:

nslookup -type=txt ourcloudnetwork.com

Here are my results:

nslookup ourcloudnetwork
nslookup ourcloudnetwork

If this command does not return a result that includes v=spf1, then you know this is part of the problem. SPF records can quickly be overwritten or removed if someone makes a change at your DNS registrar like resetting all records or changing the nameservers.

Ensure you have your SPF record correctly configured. The SPF record should be a txt-based DNS record and start with v=spf1 and end with -all (preferably). An include: section should be present that includes either the public IP of the sending mail server or a specific spf subdomain that is provided by your mail provider, for example, Microsoft 365’s SPF record is spf.protection.outlook.com.

Step 3. Review and fix DKIM for your domain

The goal of DKIM is similar to that of SPF, to validate that the sender is authorised to send on behalf of the sending domain. Although it does work a little differently. DKIM used cryptography to sign an email using a private key from the authorised sending server (in many cases, Microsoft 365), recipients of the mail then will use the public key published by the sending domains’ public DNS servers to verify the message. Providing that signature attached to the email has not been modified in transit, the message will pass DKIM verification. 

In some cases, DKIM may not be (or ever have been) configured. As well as this, if a mail service sends an email without signing DKIM (either legitimately or maliciously) DKIM will return as none (dkim=none). This still may result in the recipient rejecting the email due to a lack of authentication altogether.

dkim not configured
dkim not configured

If a mail service signs an email with DKIM, but the public key does not match to decrypt the signature, then the following error will be found in the header of your email:

dkim=temperror
dkim=temperror

To fix your DKIM record, you should follow the guidance provided by your email provider, as the steps to enable DKIM signing from the email service side are different for each provider. For Microsoft 365, you should follow the below steps:

Log in to the Microsoft Defender Admin Portal > Policies and Rules > Threat Policies > Email authentication settings > DKIM > Select your domain and enable DKIM

At this point you will be provided with the necessary DNS records you need to add to your public DNS provider.

At this point, for most people, if you have correctly configured SPF and DKIM then you should no longer be receiving the bounce-back messages and mail should be delivered successfully. However, if you use other third-party services to send mail, or if you are still receiving NDR messages, continue to the next steps.

Step 4. Revert your DMARC to 'none' and configure DMARC reports

Fundamentally, the 550 5.7.509 error is returned as a bounce-back email when your DMARC policy is configured to reject (dmarc=reject).  So, the simplest solution (short-term) is to set your DMARC policy back to none, while you continue to troubleshoot and resolve any issues. 

At this point, both Step 2 and Step 3 for SPF and DKIM are still most relevant, however, it is likely that you are using a third-party mail service to send emails from your domain. Some examples of this could be expense systems, HR systems or marketing systems.

DMARC also supports reporting when an email fails checks against the DMARC record. This allows you as the administrator to review these report emails to identify configuration issues for the services that send email on behalf of your domain. Unfortunately most email services do not have a built in analysis service, however DMARC reports can be sent to any mails to be read and interpreted, ideally a third-party service should be used for accurate report analysis.

Here is an example DMARC record with the policy set to none:

v=DMARC1; p=none; pct=100; [email protected]; fo=1"

To break down this policy:

  • P=none – This set the DMARC policy to none, recommending that recipients do nothing with emails that fail the DMARC check.
  • pct=100 – This means that the policy will apply to 100% of emails that are received.
  • rua=%email% – This is the destination of where you want to receive aggregate reports on DMARC failures.

Step 5. Set your DMARC policy back to 'reject'

Sometimes, the hardest part of a DMARC deployment is knowing when to change your DMARC policy back to reject (p=reject). Doing so too early could result in emails bouncing and having to be resent, but leaving it too long leaves you further exposed to being spoofed by malicious actors. 

I recommend you allow up to a maximum of 1 month to verify you have captured and actioned all information received through your DMARC reporting. This allows for any services that send emails on a maximum of a one-monthly basis to be captured and resolved.

Daniel Bradley

My name is Daniel Bradley and I work with Microsoft 365 and Azure as an Engineer and Consultant. I enjoy writing technical content for you and engaging with the community. All opinions are my own.

Leave a Reply