# 554 5.7.5 permanent error evaluating DMARC policy: what it means and how to fix it > A "554 5.7.5 permanent error evaluating DMARC policy" bounce means the receiving server could not get a usable DMARC result for your domain. What causes it, how to tell the causes apart, and how to fix DMARC and DKIM fail results. Updated 2026-09-26 · Security · HTML version: https://getreport.app/guides/dmarc-fail-554-5-7-5 A bounce that reads "554 5.7.5 permanent error evaluating DMARC policy" means the receiving mail server could not reach a usable DMARC result for the domain in your From address, so it refused the message. The cause is almost always in your DNS: a DMARC record with a syntax error or a duplicate, an SPF record that breaks with a permanent error, or mail that fails SPF and DKIM for your domain while your policy says reject. Fix the record, and the bounces stop as soon as the change reaches DNS. This guide is for whoever manages the domain's DNS and has been handed a bounce, and for anyone who wants to understand a `dmarc=fail` or `dkim=fail` result in a message header. It sits under the [SPF, DKIM and DMARC setup guide](https://getreport.app/guides/spf-dkim-dmarc-email-authentication), which explains how the three records fit together. ## Quick answer - **Look at your DMARC record first:** `dig +short TXT _dmarc.example.com`. You want exactly one line, starting with `v=DMARC1;`, with straight quotes and semicolons between tags. - **Then look at SPF:** one TXT record starting with `v=spf1`, at most 10 DNS lookups once every include is followed. Two SPF records or 11 lookups make SPF fail for every message. - **Then find the service that sent the bounced mail** and check that it signs with DKIM for your domain (`d=example.com`), not its own. - **Run the free [email and DNS health check](https://getreport.app/tools/email-dns-check)**: it reads SPF, DMARC and DKIM in one go, counts SPF lookups and writes the record to paste. - **Do not delete your DMARC record to make the bounces stop.** Step back to `p=quarantine` or `p=none` for a few days if customers are losing mail, fix the sender, and move up again. ## If you only sent the email If you are not the person who manages your company's domain, there is little you can fix yourself. Forward the full bounce, including the technical part at the bottom, to whoever runs your email or website. They need the recipient's domain, the date and time, and the bounce text. One thing is worth checking on your side: if you sent from a phone or desktop app, make sure the outgoing (SMTP) server is your company's mail provider. A mail app that sends `you@yourcompany.com` through another provider's server fails DMARC by design, and the error is the domain doing its job. ## What "554 5.7.5" actually means The two numbers have separate meanings. `554` is a permanent SMTP failure: the receiver will not accept the message, and resending it unchanged will fail again. `5.7.5` is an enhanced status code from RFC 3463, where class 7 is security and policy, and code 5 means a cryptographic or validation step could not be completed. The text after the code is chosen by the receiver, not by a standard, so the wording varies. What they share is that the receiver's DMARC evaluation ended in an error or a failure it treats as permanent. In practice that comes from three places, in this order of likelihood: | Cause | What the receiver sees | Where to fix it | | --- | --- | --- | | A broken or duplicate DMARC record | No policy it can read, or two conflicting ones | `_dmarc.example.com` | | SPF returns `permerror` | SPF cannot be evaluated, so aligned SPF cannot pass | The SPF record at `example.com` | | No aligned SPF or DKIM pass under `p=reject` | A clean DMARC fail, applied as reject | The sending service's DKIM or SPF setup | ## Cause 1: a broken DMARC record Receivers only accept a DMARC record that starts with `v=DMARC1`. Anything else at `_dmarc` is ignored, and two records that both start correctly are discarded together. Look for these mistakes: - **Two records at `_dmarc`.** Often one from an old provider and one from a new setup. Merge them into one. - **`v=DMARC1` missing or not first**, or written as `v=DMARC 1` or `v=dmarc1;` with extra characters before it. - **Curly quotes or a trailing dot** pasted from a document or chat, so the value your DNS panel stores is `“v=DMARC1; …”`. - **Commas between tags.** Tags are separated by semicolons; only multiple `rua` addresses use commas. - **An unknown policy value**, such as `p=rejected` or `p=quarantined`. - **The record at the wrong host name:** `_dmarc.example.com.example.com`, because the panel appended the domain to a name that already contained it. A correct record, for comparison: ```dns _dmarc.example.com. 3600 IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com" ``` Since RFC 9989 replaced RFC 7489 in May 2026, some old habits no longer break anything. A record without `p=` is read as `p=none`, and receivers ignore tags they do not know, so a leftover `pct=100` is harmless. Write `p=` explicitly anyway: receivers still following the old rules may reject a record without it, and it makes your intent clear. The guide to [what DMARC is and what each tag means](https://getreport.app/guides/what-is-dmarc) has the full tag table. ## Cause 2: SPF fails with a permanent error When SPF itself cannot be evaluated, the receiver gets `spf=permerror`, and aligned SPF cannot pass. If your DKIM is also missing or unaligned, DMARC has nothing left. The two usual reasons: - **Two SPF records.** RFC 7208 says a domain with more than one TXT record starting `v=spf1` gets a permanent error for every message. - **More than 10 DNS lookups.** Every `include`, `a`, `mx`, `ptr`, `exists` and `redirect`, counted through nested includes, uses one of the 10. Adding one more service is often what tips a domain over. The guide to [multiple SPF records and the 10-lookup limit](https://getreport.app/guides/multiple-spf-records-and-the-10-lookup-limit) shows how to merge two records and bring the count down. ## Cause 3: a plain DMARC fail under p=reject If your records are valid, the bounce means the message failed DMARC and your own policy told the receiver to refuse it. That happens when neither check passes *for your domain*: - SPF passed, but for the sending service's bounce domain (`bounces.mailer.example.net`), not yours. - DKIM passed, but the signature's `d=` is the service's domain (`sendgrid.net`, `onmicrosoft.com`, a `gappssmtp.com` domain from Google), not yours. - Or neither passed at all, because the service was never set up. This is the most common reason for a DMARC fail, and it is usually one service: a newsletter tool, a CRM, a helpdesk, an invoicing system or a WordPress site sending form mail through the web server. Turn on custom-domain DKIM in that service; it is the fix that also survives forwarding. The [DMARC policy guide](https://getreport.app/guides/dmarc-policy-none-quarantine-reject) explains alignment in detail. ## Related bounces and what each one means The same underlying problem shows up with different wording at different receivers: | Bounce text | Sent by | Meaning | | --- | --- | --- | | `554 5.7.5 permanent error evaluating DMARC policy` | Various receivers | DMARC could not be evaluated or failed permanently | | `550 5.7.26 Unauthenticated email from example.com is not accepted due to domain's DMARC policy` | Gmail | The message failed DMARC and your policy is reject | | `550 5.7.509 Access denied, sending domain example.com does not pass DMARC verification and has a DMARC policy of reject` | Microsoft 365 and Outlook.com | The same, at Microsoft | | `550 5.7.515 Access denied` | Outlook.com, Hotmail, Live | A high-volume sender without the required SPF, DKIM and DMARC | | `554 5.7.9 Message not accepted for policy reasons` | Yahoo | A policy rejection, often authentication or reputation | The fix path is the same for all of them: records first, then the sending service's DKIM. For the volume rules behind 5.7.515 and Gmail's bulk rejections, see the guide to [Gmail, Yahoo and Outlook bulk-sender requirements](https://getreport.app/guides/gmail-yahoo-bulk-sender-requirements). ## How to read a dmarc=fail or dkim=fail result Every receiver writes its verdict into an `Authentication-Results` header. In Gmail, open a message and choose **Show original**; in Outlook on the web, **View → View message source**. A failing message looks like this: ```text Authentication-Results: mx.google.com; dkim=pass header.i=@mailer.example.net header.s=s1; spf=pass smtp.mailfrom=bounces.mailer.example.net; dmarc=fail (p=REJECT sp=REJECT dis=REJECT) header.from=example.com ``` Read it left to right. DKIM passed, but for `mailer.example.net`. SPF passed, but for `bounces.mailer.example.net`. Neither matches `example.com` in the From line, so DMARC failed and the receiver applied your reject policy. The fix is custom-domain DKIM in that mailer, not a change to your DMARC record. A `dkim=fail` result is different: a signature for your domain was there, but it did not verify. The usual reasons are: - **The key in DNS does not match** the one the service signs with: a truncated TXT value, a missing character, or the record at the wrong host name. - **The key is missing** (`dkim=temperror` or "no key for signature"), often because the CNAME is proxied through Cloudflare instead of set to DNS only. - **The message was changed on the way:** a mailing list added a footer, or a security gateway rewrote links. The header then says "body hash did not verify". The guide to [DKIM selectors and the DKIM record](https://getreport.app/guides/what-is-dkim) covers each of these. ## Find your cause in five minutes > **Free tool:** [DMARC, SPF, DKIM and MX record checker](https://getreport.app/tools/email-dns-check): Free DMARC checker that also tests SPF, DKIM and MX. See what is missing or broken and get the exact DNS records to add. No sign-up, results in seconds. 1. **Run the check on your domain.** It reads the DMARC record and names its policy, follows every SPF include to count lookups, and flags two SPF records, include loops and includes with no SPF record. 2. **Confirm there is exactly one DMARC record.** The check reads the first one it finds, so also run `dig +short TXT _dmarc.example.com` and count the lines. 3. **Look at the SPF result.** "Valid (7 of 10 DNS lookups)" is fine; a permanent error is cause 2. 4. **Find the sender.** The bounce shows which message failed. Ask who sent it and from which tool, then open a copy of a message from that tool and read its `DKIM-Signature` header: `d=` should be your domain. 5. **Fix, then send a test** to a Gmail address and check `DMARC: PASS` in Show original. > **Check: The domain publishes a DMARC record.** Since February 2024, Gmail and Yahoo require DMARC from anyone who sends them more than 5,000 messages a day. DMARC also tells receivers what to do with mail that pretends to come from your exact domain. > > 1. Add a TXT record at _dmarc.yourdomain with v=DMARC1; p=none; rua=mailto:reports@yourdomain to start collecting reports. > 2. After a few weeks of clean reports, move to p=quarantine and then p=reject. > 3. If there are two or more DMARC records, merge them into one: receivers ignore all of them. > **Check: SPF syntax and lookup limit.** A broken SPF record counts as no record at all. The most common break is more than 10 DNS lookups once every include is followed, which makes receivers give up with a "permerror". > > 1. Remove include: entries for services you no longer use, and merge or flatten the rest until the count is 10 or less. > 2. Replace mx, a and ptr mechanisms with the ip4 or ip6 ranges they stand for when you are close to the limit. > **Check: DKIM key.** DKIM signs every message so receivers can check it really came from you and was not changed. DKIM also keeps forwarded mail passing DMARC, which SPF alone cannot. > > 1. Turn on DKIM signing in your email provider (Google Workspace, Microsoft 365, your newsletter tool) and publish the key record it gives you. > 2. DKIM keys live under a selector only your provider knows; if yours is set up, this check may simply not guess its name. The DKIM check tries 27 common selectors. A custom selector shows as "not found" even when DKIM works, so trust the header of a real message over this result. ## Forwarding and mailing lists Mail that you sent correctly can still fail DMARC after someone forwards it. The forwarding server is not in your SPF record, so SPF fails; DKIM usually survives, unless the forwarder changes the message. A mailing list that adds "[list]" to the subject or a footer to the body breaks DKIM too. You cannot fix other people's forwarders. What protects you is DKIM on every message, so an unchanged forward still passes. Many mailing lists now rewrite the From address of posts from domains with a strict policy, and ARC (RFC 8617) lets a forwarder vouch for the original result, but whether a receiver trusts ARC is its own decision. ## Stop the damage while you fix it If invoices or password resets are bouncing, you can buy time without giving up protection for good: 1. Change `p=reject` to `p=quarantine`. Failing mail goes to spam instead of bouncing, and the recipient can still find it. 2. Fix the sender's DKIM, or fix the broken record. 3. Watch the DMARC reports for a week; our guide to [reading DMARC aggregate reports](https://getreport.app/guides/dmarc-reports) shows how. 4. Move back to `p=reject`. Lowering the TTL of your `_dmarc` record to 300 seconds a day before a change makes each step take effect within minutes. Raise it again afterwards. ## Common mistakes - **Deleting the DMARC record.** The bounces stop, but so does all protection, and bulk senders then fail Gmail's, Yahoo's and Outlook's requirements. - **Adding a second SPF record for the new service** instead of adding its include to the existing one. - **Changing DMARC when the problem is DKIM.** A `dmarc=fail` with `dkim=pass` for another domain needs custom-domain DKIM, not a softer policy forever. - **Testing only from your main mailbox.** Your mailbox provider usually passes; the failing mail comes from the other tools that send as you. ## Questions people ask ### Why does DMARC fail when DKIM passes? Because DKIM passed for a different domain than the one in your From line. DMARC only counts a DKIM pass when the signing domain, the `d=` value, matches your From domain. Services that have not been set up with your domain sign with their own, so the header shows `dkim=pass` and `dmarc=fail` together. Turn on custom-domain DKIM in that service. ### What does dkim=fail mean in an email header? It means the message had a DKIM signature, but the receiver could not verify it. Either the public key in DNS does not match the private key the service signs with, the key record is missing or unreachable, or the message was changed after signing, for example by a mailing list footer. Compare your DNS record with the one the service shows. ### Should I remove p=reject to stop DMARC bounces? Not for good. Step back to `p=quarantine` for a few days so failing mail lands in spam instead of bouncing, fix the service that sends without aligned DKIM, then return to `p=reject`. Removing the record or staying on `p=none` leaves your domain open to forgery again and fails the bulk-sender rules of Gmail, Yahoo and Outlook. ### How long after fixing DNS do DMARC bounces stop? Usually within an hour. Receivers cache DNS records for the record's TTL, often 3,600 seconds, so a fix is seen as soon as the old answer expires. Messages that already bounced are not retried; the sender has to send them again. Check the live record with `dig +short TXT _dmarc.example.com` before you resend. ### Can forwarded email fail DMARC even when my setup is correct? Yes. Forwarding breaks SPF, because the forwarding server is not in your SPF record, so the message depends on DKIM alone. If the forwarder also changes the message, such as a mailing list adding a footer, DKIM breaks as well and DMARC fails. Signing every message with DKIM for your domain keeps plain forwards passing.