“DMARC unauthenticated mail is prohibited”

"DMARC unauthenticated mail is prohibited" is associated with the SMTP rejection code 550 5.7.1, which can appear when mail you send fails the recipient domain's DMARC checks. This article explains the error, what causes it, and how to troubleshoot it.

About the 550 5.7.1 DMARC error

550 5.7.1 is a permanent rejection (a non-delivery report, or NDR) telling the sender that the receiving server rejected the message because it failed DMARC authentication for the From: domain.

The accompanying phrase, "unauthenticated mail is prohibited," means the message could not prove it was authorized to use that domain, so under the domain's DMARC policy (at quarantine or reject) it was not delivered.

In plain terms, the message failed to produce an aligned SPF or DKIM pass. The causes below all reduce to that.

Reason 1: You are sending from a source your domain has not authorized

For mail to pass DMARC, the sending source must either be authorized in your SPF record (and the envelope domain aligned with your From: domain) or the message must carry a valid DKIM signature aligned with your From: domain. If you send from a server or service that you have not set up for either, the mail fails DMARC.

For example, if your mail claims to be from [email protected] but is sent through a provider you have not authorized in SPF and have not configured to DKIM-sign as your domain, a DMARC-enforcing recipient will reject it.

How to troubleshoot: identify every service that sends mail as your domain (your mail platform, marketing tools, ticketing systems, and so on),and make sure each one is authorized in your SPF record and, ideally, set up to apply an aligned DKIM signature.

Reason 2: Your From: domain's authentication is misconfigured

If the From: domain's SPF or DKIM is set up incorrectly, or your DMARC record itself contains errors, mail can fail DMARC.

How to troubleshoot: make sure your From: domain has valid, published SPF and DKIM records and a correctly formed DMARC record. A correct DMARC record uses only valid tag values. For example:

v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; adkim=s; aspf=s

Note that adkim and aspf accept only two values each: r (relaxed) or s (strict). They do not accept any other value. Setting them to strict (s) tightens alignment, so use strict only when all your legitimate mail can meet exact-match alignment, otherwise use relaxed (the default).

Reason 3: Your SPF record does not include all your sending sources

If not all of your legitimate sending sources are reflected in your SPF record, mail from the missing sources can fail SPF and, if DKIM is not aligned either, fail DMARC.

How to troubleshoot: review your SPF record and make sure every authorized sending service is included. For example, if you send through Microsoft 365, your SPF record should include its sending hosts:

v=spf1 include:spf.protection.outlook.com -all

If you use several services, include each one. Keep in mind SPF allows a maximum of 10 DNS lookups, so consolidate where possible. Because SPF breaks under forwarding, also set up aligned DKIM so your mail can still pass DMARC via DKIM when SPF fails.

Reason 4: The sending domain is not correctly configured for DKIM

Mail can also fail when the From: domain has no aligned DKIM signature, or DKIM is set up improperly, leaving SPF as the only mechanism (which is fragile, since SPF breaks on forwarding).

How to troubleshoot:

1. Verify your SPF and DKIM records in DNS.
2. Confirm your sending platform is actually DKIM-signing your mail with a key that aligns with your From: domain.
3. If DKIM is not set up, configure it. Having both SPF and aligned DKIM is the most resilient setup.

Reason 5: A specific legitimate source keeps failing (for example, a forwarder or mailing list)

If a particular flow keeps triggering the error, it is often an indirect one, such as a mailing list or forwarding service that breaks SPF (and sometimes DKIM) alignment.

How to troubleshoot: use your aggregate (RUA) reports to identify exactly which source is failing and why. If it is a legitimate forwarder, the durable fix is to ensure DKIM is aligned (DKIM usually survives plain forwarding),and to rely on ARC-aware forwarders where mailing lists modify the message. If it is your own service, authorize it properly in SPF and DKIM. Note that DMARC governs how a domain's own outbound mail is authenticated, so you cannot fix this by asking the recipient to change their DMARC policy.