A 550 5.7.1 bounce that says "Email rejected per DMARC policy" means the receiving mail server ran a DMARC check on your message, the message failed, and your own published policy told the receiver to reject it. This is not the receiver being strict. It is your p=reject (or p=quarantine) instruction working exactly as written. The fix is almost never to weaken the policy. It is to find the sending source that is not aligned and authorize it properly.
The two questions that decide everything: is the rejected mail coming from a system you control, or from a third-party tool (CRM, invoicing, help desk, marketing platform) that you forgot to authorize? Answer that first and the fix becomes obvious.
Reads public DNS only. Nothing is stored unless you save the domain to an account.
What the 550 5.7.1 DMARC bounce actually means
DMARC (RFC 7489) only passes when a message satisfies two conditions at once: it authenticates with SPF or DKIM, and the domain that passed is aligned with the domain in the visible From: header. When neither SPF nor DKIM produces an aligned pass, DMARC fails, and the receiver looks up your policy in DNS.
If your record says p=reject, a compliant receiver refuses the message at the SMTP transaction and returns something like this:
550 5.7.1 Unauthenticated email from example.com is not accepted due to domain's DMARC policy
or, from Microsoft and others:
550 5.7.1 Email rejected per DMARC policy for example.com
The key phrase is "per DMARC policy" and the domain named is yours, the From: domain. That tells you the receiver is enforcing your instruction, not its own. Compare this to a rejection that names the receiver's inbound rules or a blocklist, which is a different problem. If you are seeing the closely related Gmail variant, our guide on the 550 5.7.26 unauthenticated sender error covers that specific wording.
Step 1: read the bounce and identify the sending IP
Open the full bounce message, also called a non-delivery report. You are looking for three things:
- The
From:domain the receiver evaluated (this should be your domain). - The sending IP address or hostname that delivered the message.
- Any
Authentication-Resultsline if the receiver included one.
The sending IP is the single most useful clue. If it belongs to your normal mail platform (Google Workspace, Microsoft 365, your own server), you have an alignment or configuration problem on a known source. If the IP belongs to a service you half-remember signing up for (a scheduling tool, an e-signature vendor, a payroll system), you have found an unauthorized sending source. That is the most common cause of a sudden wave of DMARC rejects: a department connected a SaaS tool that sends "from" your domain, and it was never added to SPF or given a DKIM key.
If the bounce includes an Authentication-Results header, read it carefully. Our walkthrough on how to read the Authentication-Results header explains each field. You want to see whether spf= and dkim= passed, and critically, whether they aligned.
Step 2: separate an alignment failure from an authentication failure
This distinction trips up most people. There are two different ways to fail DMARC.
SPF or DKIM failed outright
The message was not authenticated at all. SPF returned fail or softfail, and there was no valid DKIM signature. This usually means the sending source is not in your SPF record and has no DKIM key on your domain. Typical for a newly added third-party tool.
SPF or DKIM passed but did not align
This is subtler and easy to miss. The tool authenticated, but against its own domain, not yours. SPF can pass for the vendor's envelope domain (the Return-Path) while your From: domain is different, so SPF alignment fails. DKIM can be signed with the vendor's d= domain instead of yours, so DKIM alignment fails. DMARC ignores authentication that is not aligned. Our guide on relaxed vs strict alignment explains why a subdomain or an organizational-domain mismatch still counts as a failure, and why DKIM can fail while SPF passes covers a very common version of this.
You need at least one of the two, SPF or DKIM, to both pass and align. You do not need both.
Step 3: confirm the real state with a checker
Guessing wastes hours. Run your domain through the scanner above and read what it reports for the sending source in question. It shows your live SPF record, every include: in it, your DKIM selectors, and your DMARC policy exactly as the receivers see them. Confirm three things:
- Does your SPF record contain the vendor's
include:mechanism, and does it stay under the 10 DNS-lookup limit? If SPF is silently broken by too many lookups you will see a PermError, which fails alignment for everyone. Our fix for too many SPF DNS lookups handles that case. - Is there a DKIM key published at the selector the vendor uses, signing with your domain in the
d=tag? - What is your DMARC policy, and is it
rejectorquarantine?
A minimal aligned setup for a domain that sends through one platform looks like this in DNS:
v=spf1 include:_spf.google.com ~all
with a DKIM TXT record at google._domainkey.example.com and a DMARC record such as:
v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=r; aspf=r
Step 4: authorize the source, do not weaken the policy
Once you know which source is failing, fix that source. The wrong move, and a tempting one when mail is bouncing, is to drop your policy back to p=none. That reopens your domain to spoofing and undoes the protection you built. Fix the alignment instead.
If the source is a third-party tool
Log into the vendor console and find its email authentication or "sending domain" setup. Almost every reputable platform gives you two things: an SPF include: to add to your record, and one or more DKIM keys (usually CNAME records) to publish so it signs as your domain. Add the include: to your existing SPF record rather than creating a second SPF record, because two SPF records is itself a PermError. Publish the DKIM CNAMEs, then verify inside the vendor console until it reports the domain as authenticated. We have provider-specific walkthroughs for common culprits like HubSpot, Mailchimp, SendGrid, and Amazon SES.
If the source is your own mail platform
Then something is misconfigured on a system you own. Check that Google Workspace or Microsoft 365 DKIM is actually enabled and switched on (enabling in the admin console and publishing the DNS record are two separate steps, and mail fails until both are done). For Microsoft tenants, our DMARC for Microsoft 365 guide covers the exact toggles.
If the source is forwarding
A message forwarded through a mailing list or a "forward to my other address" rule breaks SPF, because the forwarder's IP is not in your SPF record. DKIM usually survives forwarding, which is why DKIM alignment matters so much. If you rely only on SPF, forwarded mail will fail DMARC and bounce. Our explainer on why forwarding breaks SPF shows why DKIM is the durable fix.
Step 5: verify the fix and monitor
DNS changes take time to propagate, from minutes to a few hours depending on your record's TTL. After you add the include: or DKIM key, send a test message from the affected source to an address you control, then read the Authentication-Results header on the received copy. You want to see an aligned pass, for example dkim=pass header.d=example.com where example.com matches your From: domain.
Do not consider the job done after one good test. DMARC aggregate reports (the rua= address in your record) list every source sending as your domain and whether each one passes. Reading them is how you catch the next unauthorized tool before it generates a pile of bounces. Our guide on reading DMARC aggregate reports walks through the XML.
Frequently asked questions
Should I change my DMARC policy to none to stop the bounces?
No. Setting p=none stops enforcement, which means spoofed and unauthenticated mail flows again and your legitimate deliverability protection is gone. The bounce is telling you a specific source is not authorized. Fix that source with an SPF include or DKIM key. If you genuinely rolled out p=reject too fast and cannot fix every source immediately, use the pct tag to enforce on a fraction of mail while you clean up, as described in our DMARC pct tag guide, rather than disabling enforcement entirely.
The email passed SPF, so why did DMARC still reject it?
Because SPF passing is not the same as SPF aligning. DMARC requires the domain that SPF authenticated (the Return-Path domain) to match your From: domain. Many platforms pass SPF against their own bounce domain, which does not align with yours, so DMARC fails. Get an aligned DKIM signature (d= your domain) and the message will pass DMARC regardless of the SPF alignment result.
How do I find which tool is sending unauthorized mail as my domain?
Read the sending IP or hostname in the bounce, and cross-reference it with the sources listed in your DMARC aggregate reports. The report groups traffic by sending IP and tells you the pass or fail result for SPF and DKIM. An IP that fails both, sending volume you did not expect, is almost always a SaaS tool someone connected without telling IT.
Is 550 5.7.1 always a DMARC problem?
No. The 550 5.7.1 code is a general "delivery not authorized" response and is used for several policy rejections, including relay denials and content rules. It is a DMARC rejection only when the text names DMARC and cites your From: domain's policy. If the wording points at SPF specifically, see our guide on 550 5.7.23 SPF validation failed instead.