Email Rejected Due to DMARC Policy (550 5.7.1, 5.7.509): Why It Happens and How to Fix It

The bounce says something like 550 5.7.1 Unauthenticated email from example.com is not accepted due to domain's DMARC policy, or 550 5.7.509 Access denied, sending domain example.com does not pass DMARC verification and has a DMARC policy of reject, or 554 5.7.9 Message not accepted for policy reasons. The wording changes between receivers, but the meaning does not: the domain in the visible From address publishes a DMARC policy of quarantine or reject, and this message failed the DMARC check, so the receiver is doing what the domain owner asked. If you are the domain owner, the policy is working, and the work is to find out why a message you wanted delivered failed. If you are a sender using someone else's domain, you need the domain owner to authorise you. This guide explains how DMARC makes its decision, how to read the evidence in a bounce or a header, the four situations that cause almost every legitimate failure, and how to fix them without lowering your protection.

How DMARC decides

DMARC adds one rule to SPF and DKIM: the domain that passes must be the same as, or related to, the domain the reader sees in the From header. That relationship is called alignment. A message passes DMARC if at least one of these is true: SPF passes and the domain checked by SPF (the envelope sender, or Return-Path) aligns with the From domain; or DKIM passes and the domain in the signature (the d= value) aligns with the From domain. If neither holds, the message fails, and the receiver applies the policy in the p= tag of the DMARC record: none means take no action, quarantine usually means spam folder, and reject means refuse the message during the SMTP conversation. The details of alignment modes are in DMARC alignment explained, and the policies in DMARC policy: none, quarantine, reject.

Read the evidence

You need to know three facts: which domain is in the From header, what the DMARC record says, and what SPF and DKIM showed. For a delivered message, the header block called Authentication-Results shows them. For a bounced message, the bounce includes the diagnostic text, and you can often find the original headers in the returned copy.

Authentication-Results: mx.example.net;
  spf=pass smtp.mailfrom=bounce.vendor.example;
  dkim=pass header.d=vendor.example;
  dmarc=fail (p=reject) header.from=yourdomain.com

In this example SPF passes and DKIM passes, and DMARC still fails. Both checks passed for vendor.example, not for yourdomain.com, so neither aligns with the From domain. That is the classic third-party sender problem, and it is the cause of most legitimate DMARC failures. Our guide on reading email headers shows how to find these lines in any mail client, and the SPF, DKIM and DMARC checker shows the current records for a domain. You can look up the policy yourself with dig TXT _dmarc.yourdomain.com +short.

The four situations behind most failures

1. A third-party service sends as your domain without aligned authentication

Marketing platforms, CRMs, help desks, billing systems and forms often send "from" your address using their own servers. Unless you complete the service's domain setup, it signs with its own domain and uses its own return path, as in the example above. The fix is to add the service as an authorised sender in a way that aligns: publish the DKIM record the service gives you so that it signs with your domain, and where possible set a custom return-path or tracking domain on your own domain so that SPF aligns as well. DKIM alignment alone is enough for DMARC, and it also survives forwarding, so make it your priority. The guide on managing several vendors on one domain explains how to organise this, and custom return paths shows how to align SPF.

2. A forwarded message loses SPF

When a message is forwarded by a mailing list, an alias or a forwarding rule, the forwarding server sends it from a different IP address, so the original SPF no longer passes. If the original message carried an aligned DKIM signature that the forwarder did not break, DMARC still passes. If the forwarder changed the subject or the body, the signature breaks, and DMARC fails. Mailing lists that rewrite the From address avoid the problem; others rely on ARC, which helps some receivers trust the chain. You cannot fully control forwarding, which is one reason to use aligned DKIM for every sender. See email forwarding explained.

3. The sending subdomain or the organisational domain does not match

If you send from news.yourdomain.com, the DMARC record is looked up at that name first and, if it does not exist, at the parent. The sp= tag sets the policy for subdomains. A parent record with p=reject applies to subdomains that have no record of their own. Relaxed alignment allows a subdomain to align with its parent, but strict alignment (adkim=s or aspf=s) does not. Check whether a recent change to the policy or to the alignment mode caused a sender that used to pass to fail.

4. A record is broken or has changed

An SPF record with more than ten DNS lookups returns a permanent error and counts as a fail (see SPF too many lookups). A DKIM key that was rotated or deleted makes signatures fail (see DKIM body hash did not verify for the related failure). A DNS migration may have dropped a TXT record. Check the records today, not what you remember.

Do not "fix" it by weakening the policy

When a business email stops arriving, the instinct is to change p=reject to p=none. That removes the symptom and also removes protection against anyone who spoofs your domain. If it must be done as an emergency step, do it briefly, with a plan to restore the policy, and fix the cause in parallel. A better approach is to find the failing source in your DMARC aggregate reports, which list every IP address and service sending as your domain together with the SPF and DKIM results. Fix each source, watch the pass rate rise and keep the enforcing policy. The process is described in DMARC aggregate reports and moving to reject.

A step-by-step repair

1. Get the bounce or a header from a failed message, and note the From domain and the sending service.
2. Look up the DMARC record and note p=, sp=, adkim and aspf.
3. Check what SPF and DKIM reported and for which domains they passed.
4. If they passed for the vendor's domain, complete the vendor's domain authentication so that DKIM signs with your domain.
5. If SPF failed, check that the sending IP is covered and that the record is under the lookup limit.
6. Send a new test message to a mailbox you control and confirm dmarc=pass.
7. Watch the aggregate reports for a week to confirm there are no other failing sources.

If you are the sender, not the domain owner

If you are sending as a domain you do not manage, for example on behalf of a client, you cannot fix the problem alone. Ask the domain owner to authorise your service and to publish the DKIM record you give them. Until that is done, send from a domain that you control, with your own authentication, and put the client's address in the Reply-To header. Do not try to avoid the policy by changing the From address to look different; the aim is to be clearly authenticated, not to evade the check.

Quarantine and spam placement

If the policy is quarantine, you will not see a bounce. Failing messages land in the spam folder or in an administrator quarantine, and the sender hears nothing. This is why the aggregate reports matter. If recipients report that mail from you goes to spam and you publish p=quarantine, check DMARC first. For other spam-folder causes, work through the spam troubleshooting checklist.

References and further reading

• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 7208: Sender Policy Framework (SPF)
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures