The error "Message rejected due to DMARC policy" means the receiving mail server checked your message against your sending domain's DMARC record, found that it failed authentication (dmarc=fail), and honored a policy ofp=reject (bounce) or p=quarantine (spam). DMARC fails when neither SPF nor DKIM both passes and aligns with the domain in the visible From: address. The fix is to authorize your sender in SPF, sign with DKIM using your own domain, and make sure at least one of them aligns with your From domain.
What the Error Looks Like
Each provider words the rejection differently, but every one of them is reporting the same thing —dmarc=fail against a policy that is not p=none:
# Gmail / Google Workspace
550-5.7.26 Unauthenticated email from example.com is not accepted due to
550-5.7.26 domain's DMARC policy. Please contact the administrator of
550 5.7.26 example.com domain.
# Microsoft 365 / Outlook
550 5.7.509 Access denied, sending domain example.com does not pass DMARC
verification and has a DMARC policy of reject.
# Generic bounce
550 5.7.1 Email rejected per DMARC policy for example.comThe tell-tale line in the raw message headers is in Authentication-Results:
Authentication-Results: mx.google.com;
dkim=fail header.i=@example.com;
spf=fail (google.com: domain of bounce@mailer.net does not designate
203.0.113.9 as permitted sender) smtp.mailfrom=mailer.net;
dmarc=fail (p=REJECT sp=REJECT dis=REJECT) header.from=example.comPaste a bounced message into the Email Header Analyzer
How DMARC Actually Passes
DMARC does not run its own check — it sits on top of SPF and DKIM and adds one extra requirement: alignment. A message passes DMARC if at least one of these is true:
- SPF passes and aligns — SPF authorizes the sending IP and the
Return-Path(envelope-from) domain matches theFrom:domain. - DKIM passes and aligns — a valid DKIM signature verifies and the signing
d=domain matches theFrom:domain.
It is not enough for SPF or DKIM to merely pass. If SPF passes for mailer.net but your From is example.com, that is a pass without alignment, and DMARC still fails. This is the single most common reason for this error.
Why It Happens
1. Sending through a service you never authorized
You send campaigns or transactional mail through a provider (Mailchimp, SendGrid, Amazon SES, Zoho, a CRM, a helpdesk) but your SPF record does not include them and you never set up DKIM with your own domain. The mail authenticates for the provider's domain, not yours, so nothing aligns.
2. SPF passes but is not aligned
Bulk senders use their own bounce/Return-Path domain (e.g. bounce@mailer.net), so SPF evaluates against their domain, not yours. SPF passes, but because the envelope domain differs from your From domain, DMARC sees no SPF alignment.
3. DKIM is missing, broken, or not aligned
Either there is no DKIM signature at all, the published DKIM key is wrong or revoked, the message body was modified in transit (breaking the signature), or the signature uses the provider's d= domain instead of yours. Any of these means no DKIM alignment.
4. Strict alignment on a subdomain mismatch
If your DMARC record sets aspf=s or adkim=s (strict), the domains must match exactly. Sending as news.example.com while authenticating for example.com passes under relaxed alignment (the default) but fails under strict.
5. Forwarding broke SPF (and sometimes DKIM)
When a message is auto-forwarded, the forwarding server becomes the sender, so SPF fails at the final hop. If the forwarder also rewrites the subject or footer, DKIM breaks too — and DMARC fails. This is a known limitation of forwarding, mitigated by DKIM surviving intact or by ARC at the receiver.
6. You moved to p=reject before authentication was ready
A domain that publishes p=reject or p=quarantine while some legitimate senders are still unauthenticated will have that mail bounced. Enforcement should come afterevery source is passing, not before.
p=none, DMARC only monitors — mail still fails authentication but is delivered, and you receive reports. This rejection error only appears once your policy is quarantine or reject. Do not raise the policy until your reports are clean.How to Diagnose It
Work from the message itself. The Authentication-Results header tells you exactly which check failed and whether it was a pass-without-alignment. Look at three fields:
spf=andsmtp.mailfrom=— did SPF pass, and for which domain?dkim=andheader.i=/d=— did DKIM pass, and for which domain?dmarc=andheader.from=— the verdict and your visible From domain.
Then confirm your published records. Check that the DMARC record exists and see its policy, verify SPF includes every sender, and confirm the DKIM selector resolves:
# Your DMARC policy (note p= and the alignment tags aspf/adkim)
dig TXT _dmarc.example.com +short
# e.g. "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=r; aspf=r"
# Your SPF record — does it include the service actually sending?
dig TXT example.com +short | grep spf1
# A DKIM public key at the selector your provider signs with
dig TXT selector1._domainkey.example.com +shortIf you already collect DMARC aggregate reports, the fastest way to see which sources are failing is to run the XML through the DMARC Report Analyzer — it groups failures by sending IP so you can spot the unauthorized or misaligned source immediately.
How to Fix It
Fix A — Authorize the sender in SPF
Add the sending service to your SPF record with the include: its provider publishes. Keep a single SPF record and stay under the 10 DNS-lookup limit:
; One SPF record, listing every legitimate sender
example.com. 3600 IN TXT "v=spf1 include:_spf.google.com include:sendgrid.net ~all"SPF alone often is not enough for DMARC, because bulk senders use their own Return-Path (so SPF passes without alignment). Treat SPF as necessary but pair it with DKIM below.
Fix B — Set up aligned DKIM (the reliable fix)
DKIM alignment is what survives forwarding and works even when the Return-Path differs, so this is the most robust path to a DMARC pass. In your sending platform, enable DKIM for your own domain and publish the CNAME/TXT selector records it gives you so the signature's d= is example.com:
; Provider gives you a selector — publish its key under your domain
s1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq...QAB"
; Many ESPs instead give a CNAME that points at their managed key
s1._domainkey.example.com. 3600 IN CNAME s1.dkim.mailer.net.Because the message is now signed with d=example.com, DKIM aligns with your From domain and DMARC passes — regardless of the envelope/Return-Path.
Fix C — Align the domains you send as
Make sure the domain in the visible From: matches the domain you authenticate for. If you send as news.example.com, either authenticate for that subdomain or keep DMARC alignment relaxed (the default) so the organizational domains match. Avoid adkim=s/aspf=sunless every sender matches the From domain exactly.
Fix D — Roll the policy back while you fix sources
If legitimate mail is bouncing right now, temporarily lower enforcement to stop the damage, fix the sources, then raise it again once reports are clean:
; Temporary: monitor only — nothing gets rejected while you fix senders
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
; Then step up: quarantine a fraction, watch reports, then full enforcement
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com"
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"p=none and leaving it there removes your spoofing protection. Use it only as a short bridge while you authorize the real sender in SPF and DKIM — then return to quarantine or reject. The goal is aligned authentication, not a disabled policy.Verify the Fix
DNS changes only take effect once the old record's TTL expires. After publishing, confirm the new records are live, send a real test message, and check that its Authentication-Resultsheader now shows dmarc=pass:
# Confirm the DKIM selector is now resolving
dig TXT s1._domainkey.example.com +short
# Send a test to a mailbox you control, then in the raw headers look for:
# dmarc=pass (p=REJECT ...) header.from=example.com
# with dkim=pass header.d=example.com (aligned!)You can also send to a Gmail address and use Show original to see the SPF/DKIM/DMARC verdicts at a glance, or paste the full source into the Email Header Analyzer. Once the aggregate reports show the previously failing source passing, it is safe to keep p=reject.
Frequently Asked Questions
My SPF passes — why does DMARC still fail?
Because SPF passing is not the same as SPF aligning. Bulk senders authenticate their own Return-Path domain, which differs from your From domain, so DMARC sees no alignment. Set up DKIM with your own domain, or configure a custom Return-Path on the same organizational domain as your From address.
What is the difference between quarantine and reject?
p=quarantine tells receivers to accept the failing message but treat it as suspicious (usually the spam folder). p=reject tells them to refuse it outright, producing the bounce you are seeing. Both are enforcement policies; only p=none delivers normally while you monitor.
I fixed the records but mail still bounces — why?
Almost always DNS caching. Receivers may still see the old SPF/DKIM/DMARC values until the previous TTL expires. Confirm the new records with dig from a fresh resolver, wait out the TTL, and send a new test. Also double-check the DKIM selector name matches exactly what your provider signs with.
Does DMARC failing affect email I already sent?
No. DMARC is evaluated by the receiver at delivery time for each message. Fixing your records affects new mail only; previously bounced messages must be resent after the fix is verified.
Should I just remove the DMARC record to stop the bounces?
No. Removing DMARC (or setting p=none permanently) stops the bounces but also removes your protection against spoofing and lets attackers impersonate your domain. Fix the underlying authentication instead, then keep enforcement on.