Email Rejected by DMARC Policy: How to Read the Bounce and Fix the Sender

This post contains affiliate links. If you buy something through one of them, Veravix may earn a commission at no extra cost to you.

The bounce arrives within seconds of sending. It says your message was rejected, names a DMARC policy, and gives you a code that looks like it belongs to someone else’s problem. Contact form emails, invoices, and password resets are the usual victims, because a website sends them as your domain without telling anyone.

The fix is almost never on the recipient’s side. A rejection means the receiving server checked your domain’s DMARC record, found p=reject, and could not match the message to an authorised sender. This guide shows how to read the bounce, find which of the two checks failed, and repair it. If DMARC is new to you, the setup order is in How to Set Up SPF, DKIM and DMARC for Microsoft 365 Without Breaking Your Website Email. Facts below were checked against Google’s and Microsoft’s documentation and live DNS on 9 October 2026.

What the bounce actually says

Gmail’s wording, from Google’s own list of SMTP errors, is: “Unauthenticated email from domain-name is not accepted due to domain’s DMARC policy.” A separate Gmail error, 550 5.7.26, says the sender is unauthenticated and shows which of SPF or DKIM did not pass. Those are two different failures, so read the full text before you change anything.

Microsoft 365 is blunter. When the sender’s policy is p=reject and the recipient’s tenant honours it, the message is rejected during the SMTP conversation with 550 5.7.1, and the header records dmarc=fail action=oreject. Be careful with that code alone: a 5.7.1 can also come from a mail flow rule in the recipient’s own tenant, which has nothing to do with your DNS. The DMARC cause is only confirmed when the text or the header names it.

Why a message passes SPF and still gets rejected

DMARC does not ask whether SPF or DKIM passed. It asks whether either one passed and aligned with the domain in the visible From address. Microsoft’s documentation states the rule exactly: a message passes DMARC if one or both aligned checks pass, and fails only when both fail.

That is how you get the confusing header Microsoft documents as its own example: spf=pass, dkim=pass, and dmarc=fail in the same line. SPF passed for the service’s bounce domain, DKIM was signed by the service’s domain, and neither one is your domain. Both checks succeeded, and neither counts.

From address	SPF or DKIM domain	Relaxed alignment	Strict alignment
you@example.com	example.com	Pass	Pass
you@example.com	bounces.example.com	Pass	Fail
you@example.com	example.onmicrosoft.com	Fail	Fail
you@example.com	someservice.net	Fail	Fail

Relaxed alignment is the default, so a subdomain of your own domain is fine. Only aspf=s or adkim=s in your record makes a subdomain fail.

Find the failing sender in under ten minutes

1. Send a test message to a Gmail address you control. Open it, choose Show original, and read the lines for SPF, DKIM and DMARC. Gmail shows the domain each check used next to its result.
2. Compare the domain after smtp.mailfrom and the domain after header.d with the domain after header.from. If neither matches the From domain, you have found the problem.
3. Identify the sender. Mail that goes out of a contact form plugin through the server’s own mailer is a different source from your Google Workspace or Microsoft 365 mailbox, and both differ from a newsletter tool or a shop’s order emails. Check the sending IP in the header against what you expect.
4. If the rejections are intermittent, your DMARC aggregate reports are the better tool: they list every IP that sent as your domain, how many messages, and whether SPF and DKIM aligned.

The fix depends on who sent the message

Choose the row that matches the source you found.

Sender	Why it fails	Fix
Newsletter, CRM or helpdesk tool	It signs DKIM with its own domain and uses its own bounce domain	Set up the service’s custom domain authentication so it signs with your domain
Website server mailer (PHP mail)	No DKIM at all, and the server IP is not in your SPF record	Send through an SMTP plugin connected to your real mailbox or a transactional service, then align that service
Your own Google or Microsoft mailbox	DKIM never switched on for your custom domain	Enable DKIM for the domain; see How to Set Up DKIM in Google Workspace When Your DNS Host Fights the Long Key
Forwarding or a mailing list	Forwarding breaks SPF, and edits to the body break DKIM	Nothing to fix on your side; the final receiver needs to trust the forwarder (ARC)

For the first row, the Microsoft guidance spells out the order: first try to change the sender’s bounce domain to one of yours, and if that is impossible, have the service sign DKIM as your domain. If it can do neither, send that traffic from a subdomain with its own DMARC record.

The SPF side has its own trap. Adding every service you use to one record can push you past the ten-lookup limit, which turns SPF into a permanent error. SPF Records and Subdomains: How to Stay Under the 10-Lookup Limit covers how to count and cut them.

What 40 real domains publish

Before deciding how strict your own policy should be, I looked up the live _dmarc record of 40 well-known domains on 9 October 2026, including Google, Microsoft, Stripe, Shopify, Cloudflare, Hostinger, WordPress.com, Etsy and Netflix.

Published policy	Domains	Examples
p=reject	31 of 40	Google, Microsoft, Stripe, Shopify, Cloudflare, Hostinger, Netflix
p=quarantine	9 of 40	Apple, Amazon, GitHub, Ahrefs, Vercel, SiteGround
p=none	0 of 40	None

Every one of the 40 publishes an enforcing policy. That does not mean you should jump straight to p=reject on a small site, but it does mean the bounce you got is the policy working as designed. Two details are worth copying: Apple and GitHub publish sp=reject on top of a softer main policy, so unused subdomains cannot be spoofed, and none of the 40 published a pct below 100.

Roll the policy back safely while you repair the sender

If your own legitimate mail is being rejected right now, you can lower the policy while you fix the cause. Google’s rollout guidance runs the same direction in reverse: none only reports, quarantine sends failures to spam, and reject refuses them. The optional pct tag, a whole number from 1 to 100, applies the policy to that share of failing mail.

1. Change the record at _dmarc.yourdomain.com from p=reject to p=quarantine, or to p=none if the damage is large, and make sure a rua address is present.
2. Wait for the TTL to expire, then resend your test message.
3. Fix the alignment of the sender you found, confirm dmarc=pass in the headers, then raise the policy one step at a time.

Treat the rollback as a stopgap. While the policy is lower, anyone can send as your domain with less resistance.

When the rejection is on your side of the inbox

Everything above assumes your domain published the policy. If you are the recipient and legitimate mail is being rejected, the sender’s policy is being enforced by your provider. In Microsoft 365 that behaviour is controlled by the Honor DMARC record policy setting in the anti-phishing policy. For forwarded mail and mailing lists, Microsoft advises adding the forwarding service as a trusted ARC sealer before reaching for allow entries, and notes that an entry in the Tenant Allow/Block List expires after 30 days. Do that only for senders you have confirmed are real.

Where your site mail comes from matters

A site that sends order and contact emails from a hosting account depends on that account’s mail setup being correct. If you are choosing a host partly for that, Hostinger publishes p=reject for its own domain, as the table above shows. That describes its own mail, not yours, so you still need to align your own domain.

Checked for accuracy on 9 October 2026 against Google Workspace documentation, Microsoft Learn’s DMARC article, and live DNS lookups of 40 domains.