How to Check Your DMARC Record (and Fix What's Broken)

A checker tool says your DMARC record is valid. Policy, syntax, reporting address, all green. Your campaigns are still landing in spam, and when you finally read the aggregate report, half your legitimate mail shows dmarc=fail.

That gap, a record that looks correct and still isn’t working, is almost never about the record’s syntax. It’s about what the record doesn’t show you: alignment, a duplicate you didn’t know about, or a sending source nobody authenticated.

This post covers how to actually check your DMARC record (not just whether it exists), the specific errors that cause a “valid” record to keep failing, and the ESP and registrar fixes for the platforms that come up most. To keep this grounded in more than documentation, I took the most common DMARC questions to Prasanth on the InboxEagle product team and asked him to answer them the way he would for a customer. His answers are marked “Prasanth, InboxEagle team” throughout. They’re short and direct, because that’s how an engineer answers, so I’ve added the context around each one: why it happens, what it looks like in practice, and how to fix it.

How do I check if my domain has a valid DMARC record set up?

Start with the quick question: does my domain have a valid DMARC record at all?

If you’d rather not touch a terminal, paste your domain into the free DMARC record checker and it reads the record for you. If you do want the command line, these two do the same job:

dig +short TXT _dmarc.yourdomain.com
nslookup -type=TXT _dmarc.yourdomain.com

The v=DMARC1 part matters more than it looks. It has to be the first tag in the record, and a record that doesn’t begin with it isn’t read as DMARC at all, however sensible the rest of it is.

A lookup only proves the record is published. It doesn’t prove your mail passes. Here’s the full check:

1. Look up the record. Use one of the methods above. Confirm a record exists, starts with v=DMARC1, and that there is exactly one.
2. Read every tag, not just the policy. Policy, subdomain policy, reporting address, and alignment mode all affect the outcome. A record with the right p= value and a broken rua= is still failing you in a way the policy alone won’t show.
3. Send a real test message and read the headers. Send yourself a message through your actual sending setup, then open the full headers in Gmail (Show original) and look for dmarc=pass. This is the step a record lookup cannot do for you, and it’s where most “my record is valid but mail still fails” cases get solved.
4. Confirm reports are actually arriving. If rua= points to an address on a different domain than the one publishing the record, that domain needs its own authorization record, or receivers silently drop the reports without telling you.
5. Fix what you find, in order. Duplicate records first, since they mask every other symptom. Then alignment. Then missing sources. Then move the policy forward once reports are clean.

What should my DMARC record look like for a small business domain?

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Here’s why that order makes sense. p=none doesn’t change what happens to any email, so you can’t break anything by publishing it. What it does is switch on the rua= reports, which list every server sending mail as your domain and whether each one passed. Most small businesses discover a sender they forgot about in that first report: an old newsletter tool, a helpdesk, an invoicing app. If you had gone straight to p=reject, those messages would have been blocked.

The rest of the tags are optional at this stage. If you leave out adkim and aspf, alignment defaults to relaxed, which lets a sending subdomain like send.yourdomain.com align with yourdomain.com. What is DMARC? covers what each policy level does if you’re choosing between them for the first time.

How long should I keep DMARC at p=none before moving to quarantine?

There is no fixed number, and the calendar is the wrong thing to watch. Stay at p=none until your aggregate reports show every legitimate sender passing and aligning, then move.

Two things make that take longer than people expect:

• Cover a full sending cycle. Some senders don’t send daily. A monthly invoice run, a quarterly newsletter or a seasonal campaign won’t show up in a two-week window, and those are the senders that get blocked by surprise later.
• Wait for clean reports, not just time. A few weeks of reports with no legitimate source failing is the signal. If a new failure appears each week, you’re not ready.

For a small domain with two or three senders, that is usually two to four weeks. A domain with many senders, or several teams sending independently, can take a couple of months. When you do move, go to p=quarantine first and watch the reports again before considering p=reject.

What is the difference between DMARC quarantine and reject policy for my domain?

Both are enforcement policies, and both tell receivers what to do with mail that fails DMARC. The difference is how hard they act:

• p=quarantine sends failing mail to the recipient’s spam folder. It is still delivered, just flagged, so a mistake is recoverable: a customer can find the message and mark it as not spam.
• p=reject blocks failing mail outright at the SMTP level. The message never reaches the recipient, not even in spam. That’s the strongest protection against spoofing, and also the least forgiving of a missed sender.

That’s why the usual order is p=none, then p=quarantine, then p=reject, with a clean set of reports before each step. What is DMARC? covers all three policy levels and when to move between them.

What is the difference between SPF, DKIM and DMARC and how do they work together?

They’re three records with three different jobs, and DMARC is the one that connects the other two to the address your customer actually sees.

Think of it as a delivery. SPF is the guest list at the door: is this server allowed to send for you? DKIM is the tamper seal on the package: did it change on the way, and who signed it? DMARC is the rule that says the name on the seal must match the name on the envelope, and what to do with a package where it doesn’t.

Together: a receiver runs SPF and DKIM, then asks DMARC whether at least one of them passed for a domain that lines up with your From address. If yes, the message passes. If not, your policy decides what happens. SPF, DKIM and DMARC explained goes deeper on the mechanics of each.

Do I need a DMARC record if I already have SPF and DKIM set up?

Yes. Neither SPF nor DKIM tells receivers what to do when they fail, and neither checks whether the authenticated domain matches your visible From address. Without DMARC, a spoofed message can fail both checks and still get delivered, because nothing is telling the receiving server to act on that failure.

There’s a second reason. SPF and DKIM only report on the domains they authenticate, which may be your ESP’s domain and not yours. DMARC is the only one of the three that checks the domain your customer sees.

How do I set up SPF, DKIM and DMARC for my domain step by step?

Do them in this order. Each step depends on the one before it.

1. List every service that sends mail as your domain. Your ESP, your Google Workspace or Microsoft 365 mailboxes, your helpdesk, your invoicing tool, your CRM. You’ll authenticate each one.

2. Publish one SPF record. It’s a single TXT record at your domain that includes each sender. Only one SPF record is allowed per domain, so combine everything into it, and keep it within SPF’s limit of 10 DNS lookups. For example:

   v=spf1 include:_spf.google.com include:sendgrid.net ~all

   Swap in the includes for your own senders.

3. Turn on DKIM signing with your own domain at each sender. In each platform’s settings, authenticate your domain and publish the DNS records it gives you (usually CNAMEs or a TXT at a selector._domainkey host). This is what makes DKIM align with your From address.

4. Publish a DMARC record at p=none. Add a TXT record at _dmarc.yourdomain.com:

   v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

5. Send a test and read the headers. From each sender, send a message to a Gmail address, open Show original, and confirm spf=pass, dkim=pass and dmarc=pass.

6. Read your aggregate reports for a few weeks. They show every source sending as your domain and whether it passed. Fix anything legitimate that fails.

7. Tighten gradually. Move to p=quarantine, watch the reports, then move to p=reject.

If you want the platform-specific versions of steps 2 and 3, they’re in the platform section below.

What does it mean when an email says “DNS authentication DMARC fail”?

To find out which half is the problem, open the full message source and look at the Authentication-Results header. You’ll see separate spf= and dkim= results sitting next to the dmarc= result. Whichever one shows fail, or shows pass without lining up with your From domain, is the one to fix. The DMARC record itself is usually fine.

Can I have more than one DMARC record for the same domain?

The reason it trips people up is that DNS itself won’t stop you. You can publish two TXT records at _dmarc.yourdomain.com without any error. Receivers just won’t merge them or pick the first one. A domain with multiple DMARC records is treated as having no valid policy at all, the same as having none.

This happens more often than it sounds: an agency adds a record during a migration without checking for an existing one, or a DNS host keeps a stale record after a platform switch. Fix: check for a duplicate before troubleshooting anything else. Run the dig command from earlier and count the lines it returns. Every other symptom, alignment failures, missing reports, enforcement that doesn’t seem to apply, can be a downstream effect of this one.

How do I read DMARC aggregate reports and understand the XML data?

Aggregate reports are what turn p=none from a guess into a plan. Receivers like Google, Microsoft and Yahoo send them to your rua= address, usually once a day, as zipped XML attachments. Each report lists the sources that sent mail claiming to be your domain, and how DMARC judged each one.

Here is one record from a report, trimmed to the parts that matter:

<record>
  <row>
    <source_ip>203.0.113.25</source_ip>
    <count>1240</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>yourdomain.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>esp-example.com</domain>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>bounce.esp-example.com</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

Read it in this order:

1. source_ip and count. Who sent the mail and how much of it. Group records by source IP, then work out which sender each IP belongs to.
2. policy_evaluated. This is DMARC’s verdict, and the part that decides what happens to the mail. dkim and spf here mean “passed and aligned”. disposition is what the receiver did: none, quarantine or reject.
3. auth_results. The raw SPF and DKIM results, with the domains they were checked against. These show why the verdict came out the way it did.

The record above is the classic alignment failure. auth_results shows SPF and DKIM both passing, but for esp-example.com, not yourdomain.com, so policy_evaluated fails both. The fix is to set up custom domain authentication at that sender, covered in the sections below.

Raw XML is tedious to read at any volume, so most people paste reports into a viewer. How to Read DMARC Reports and Roll Out Safely walks through the full file structure, including the report_metadata and policy_published sections not shown here.

Adding and fixing your DMARC record by platform

The record itself is identical everywhere. DMARC doesn’t care who hosts your DNS or which ESP sends your mail. What differs is where you publish it and which alignment mistakes are common on each platform.

How do I add a DMARC record to my domain in GoDaddy DNS settings?

In practice, that looks like this:

1. Log into GoDaddy and go to My Products → DNS for the domain.
2. Choose Add New Record: Type TXT, Name _dmarc, Value v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com (start at p=none if this is your first record).
3. Save. GoDaddy is usually quick, but DNS changes can take up to 48 hours to be visible everywhere.
4. Look the record up afterwards. Some DNS panels append your domain to the Name field automatically, so if you typed _dmarc.yourdomain.com instead of just _dmarc, you can end up with _dmarc.yourdomain.com.yourdomain.com, a record that resolves nowhere useful. Check what the record actually resolves to, not what you typed into the field.

How do I set up DMARC for a domain that sends email through Google Workspace?

Google Workspace handles SPF and DKIM through its admin console, but it does not publish a DMARC record for you. You add that separately, through whichever registrar or DNS host manages your domain. Do it in this order, since DMARC alignment depends on DKIM:

1. Turn on DKIM. In the Admin console, go to Apps → Google Workspace → Gmail → Authenticate email, generate the DKIM record for your domain, publish it as a TXT record at the host Google shows (typically google._domainkey), then click Start authentication. Allow time for DNS to propagate first.

2. Check SPF. Your SPF record should include _spf.google.com.

3. Publish DMARC. Add a TXT record at _dmarc.yourdomain.com, starting at p=none:

   v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

4. Test. Send a message from a Workspace mailbox to a Gmail address outside your domain and confirm dmarc=pass in Show original.

If you also send from other platforms, such as an ESP, each one needs its own authentication on top of this.

How do I fix DMARC fail for Amazon SES emails using a custom MAIL FROM domain?

That principle covers this section and the next two, each with its own way of going wrong.

SES alignment issues usually trace back to the MAIL FROM domain. Out of the box, SES uses an amazonses.com return-path, so SPF passes for Amazon’s domain and not yours. A custom MAIL FROM subdomain (for example mail.yourdomain.com) fixes that, and it needs two records of its own: an MX record pointing to SES’s feedback endpoint for your region, and an SPF TXT record on that subdomain that includes amazonses.com. Turn on Easy DKIM as well, so your messages are signed with d=yourdomain.com.

A common SES-specific failure: the MAIL FROM domain is configured, but its own MX or SPF record is missing, so SPF fails even though the domain is verified correctly.

How do I fix DMARC failure for emails sent from Office 365?

Exchange Online signs with your onmicrosoft.com domain until you enable DKIM for your own domain, and that is exactly the mismatch DMARC catches. In the Microsoft Defender portal, enable DKIM for your custom domain after publishing the two CNAME records Microsoft gives you (selector1._domainkey and selector2._domainkey).

The other common O365 failure is a hybrid setup, with part of your mail flowing through Exchange Online and part through an on-premises server or a third-party relay, where the SPF record only authorizes one path. Confirm every actual sending path is covered, not just the one the setup wizard configured.

Why does SendGrid fail DMARC alignment for my custom domain?

Until you complete domain authentication, SendGrid signs with its own domain, so DKIM passes without aligning. Authenticating your domain (under Sender Authentication in the SendGrid settings) gives you CNAME records for DKIM and for a branded return-path.

Alignment then depends on your From address using the domain you authenticated. A frequent SendGrid-specific issue: domain authentication is completed correctly, but campaigns are sent from a different, unauthenticated subdomain, which fails alignment even though SendGrid’s own checks all show green.

How do I set up DMARC for emails sent through Mailchimp from my domain?

Mailchimp signs with its own DKIM selector by default, which doesn’t align with your domain until you authenticate it. Without that step, campaigns can pass SPF and DKIM under Mailchimp’s domain while still failing DMARC against your From address.

1. Authenticate your domain in Mailchimp (Account → Domains). Mailchimp shows you DKIM CNAME records to publish at your DNS host. Add them, then verify the domain in Mailchimp.
2. Send from an address on that domain. Authentication only helps when the From address uses the domain you verified.
3. Publish your DMARC record at _dmarc.yourdomain.com, starting at p=none, if you don’t already have one.
4. Send a test campaign and confirm dmarc=pass in the headers before you tighten the policy.

In most setups Mailchimp uses its own return-path domain, so DMARC passes through DKIM alignment rather than SPF. That makes step 1 the one that matters most.

Why does DMARC fail when SPF and DKIM both pass?

This is the single most common cause of DMARC failure on ecommerce mail, and the one that confuses senders the most, because every individual check reports success.

Put plainly: DMARC doesn’t take SPF and DKIM results at face value. It asks whether the domain that passed SPF (the return-path domain) or the domain that signed DKIM (the d= domain) matches the domain your customer sees in the From line. If you send through an ESP’s shared domain, SPF and DKIM both authenticate against the ESP’s domain, not yours. Both checks are clean, and DMARC still fails.

Fix: configure the branded or custom sending domain in your ESP, so DKIM signs with d=yourdomain.com and the SPF return-path uses your subdomain. Our Klaviyo authentication guide walks through the exact setup for that specific case.

How do I fix DMARC alignment failure when DKIM passes but the domain doesn’t match?

This is the narrower version of the same problem. The DKIM signature is cryptographically valid, but the d= domain in it belongs to your provider, not to you. That’s the default behavior at most ESPs until you explicitly set up custom domain signing. To confirm, find the DKIM-Signature header in the message source and read the d= value. If it doesn’t match your From domain (or a subdomain of it, under relaxed alignment), DKIM alignment fails even though DKIM itself passes.

Why do forwarded emails fail DMARC even when SPF and DKIM pass?

Here’s what that looks like in a real case. Someone has an old address that forwards to their Gmail. Your email reaches the forwarding server, which passes it on from its own IP. SPF now sees a server that isn’t in your SPF record, so it fails. If the message arrives untouched, the DKIM signature still validates and aligns, and DMARC passes anyway. This is why DKIM alignment matters more than SPF alignment in practice.

The trouble starts when the forwarder alters the message, by adding a footer, rewriting the subject, or changing headers. That breaks the DKIM signature, and now both checks fail on a message you authenticated correctly at the original send.

ARC (Authenticated Received Chain) is the repair for this. The forwarding server records the authentication results it saw before it touched the message, and a receiving server that trusts that forwarder can take those into account. It helps in supported setups, but it isn’t universal, so don’t rely on it as your only protection. Signing with your own domain is still the best defense.

Emails landing in spam, my DMARC is continuously failing, what should I do?

The temptation when DMARC keeps failing is to tighten the policy and hope. It does the opposite of helping: p=reject on a domain with unauthenticated senders blocks your own legitimate mail. Work through this order instead:

1. Check for a duplicate record. This alone can make an otherwise-correct record behave as if it doesn’t exist.
2. Check SPF and DKIM individually, then check alignment. Send a real test and read the headers; this is where most “valid record, still failing” cases resolve.
3. Check your DNS configuration. Look for typos, doubled domain names, and records that were never saved or have stopped resolving.
4. Check every sending source against your aggregate reports, not from memory. Klaviyo, your helpdesk, a review app, and your invoicing tool each need their own authentication, and it’s easy to forget one.
5. Check sender reputation. Passing authentication is the floor, not a placement guarantee. A domain or IP with a poor reputation can land in spam with a clean dmarc=pass.
6. Only then move the policy forward, one step at a time. Our DMARC failure and spam folder study has the data on what DMARC failure actually costs you in placement, which is worth knowing while you work through the fix.

Why DMARC fails: 17 common causes

Alignment is the cause people hit most, but it is rarely the only one. Here are the causes we see, roughly in the order worth checking them. Find the one that matches your symptoms, then jump to its fix below.

1. DKIM and SPF authentication failure. If neither SPF nor DKIM passes, DMARC has nothing to evaluate and fails.
2. Lack of DNS records. A missing, misspelled or unpublished SPF, DKIM or DMARC record means alignment can’t be checked at all.
3. DMARC alignment failures. SPF and DKIM pass, but for a domain that doesn’t match your From address.
4. Unrecognized sending sources. A tool sends as your domain (helpdesk, invoicing, review app, CRM) and nobody authenticated it.
5. Inconsistent policy enforcement. Different policies across your root domain, subdomains or records, so some mail is held to a standard you didn’t mean it to be.
6. Subdomain misconfigurations. You send from mail.yourdomain.com, but the subdomain has no records of its own and the root policy isn’t set up for it.
7. Email forwarding challenges. Forwarders change the envelope sender and sometimes the message itself, which breaks SPF and can break DKIM.
8. Dynamic IP address usage. Mail sent from IPs that change or have no stable reverse DNS can’t be reliably listed in SPF and tends to look suspicious to receivers.
9. Delayed DNS propagation. You tested before your new record had spread, so the receiver still saw the old one (or none).
10. Overly strict policies. p=reject published before every legitimate sender was authenticated, so your own mail gets blocked.
11. Incorrect reporting addresses. A typo in rua=, or a reporting address on another domain that hasn’t authorized your reports, so you fly blind.
12. Security software interference. Email gateways and filters that add footers, rewrite links or change subjects break the DKIM signature in transit.

A few more worth adding to the list:

13. Duplicate DMARC records. Two records at _dmarc.yourdomain.com and receivers act on neither.
14. Syntax errors in the record. A typo like p=rejct or a missing semicolon can leave the record unreadable.
15. Too many SPF lookups. SPF allows 10 DNS lookups. Go past that and SPF returns a permanent error, which takes SPF alignment out of the picture.
16. Missing or rotated DKIM keys. The selector’s public key was removed, never published, or replaced without updating the sender, so signatures stop validating.
17. Mailing lists and relays that alter messages. Like forwarders, list software that appends footers or rewrites the From line invalidates the original signature.

How to fix DMARC failures, one cause at a time

Each fix below matches the cause with the same number, so you can go straight to the one that applies to you.

1. DKIM and SPF authentication failure:
   • Read the Authentication-Results header of a failing message to see which of spf= and dkim= failed.
   • Fix the failing one first. DMARC needs only one of them to pass and align, so getting DKIM right is usually the faster route.
2. Lack of DNS records:
   • Look up the SPF, DKIM selector and _dmarc records and confirm each resolves.
   • Publish what’s missing, and check the host name you saved. Doubled domains like _dmarc.yourdomain.com.yourdomain.com are a common slip.
3. DMARC alignment failures:
   • Set up custom domain authentication in your ESP so DKIM signs with d=yourdomain.com.
   • Use a custom return-path (MAIL FROM) on your own subdomain so SPF aligns too.
4. Unrecognized sending sources:
   • Read your DMARC aggregate reports and list every source sending as your domain.
   • Authenticate each legitimate one, and stop or block the ones you don’t recognize.
5. Inconsistent policy enforcement:
   • Keep one DMARC record per domain and set sp= on purpose rather than by default.
   • Move policies forward together, one step at a time, instead of ending up with p=reject on one domain and p=none on another by accident.
6. Subdomain misconfigurations:
   • Authenticate each sending subdomain with its own SPF and DKIM.
   • Set sp= to control the policy for subdomains, or publish a separate DMARC record for a subdomain that needs different treatment.
7. Email forwarding challenges:
   • Make sure DKIM aligns with your From domain, since DKIM usually survives plain forwarding and SPF doesn’t.
   • Accept that some forwarding failures can’t be fixed on your side. Forwarders that support ARC help preserve the original result.
8. Dynamic IP address usage:
   • Send through an ESP or relay with stable, dedicated IPs and proper reverse DNS.
   • Rely on DKIM alignment rather than SPF if your IPs genuinely change.
9. Delayed DNS propagation:
   • After any DNS change, wait before testing. Records can take up to 48 hours to be visible everywhere, depending on the TTL.
   • Look the record up from more than one resolver to confirm it has spread before you judge the result.
10. Overly strict policies:
    • If legitimate mail is being blocked, step back from p=reject to p=quarantine or p=none while you fix the unauthenticated senders.
    • Move forward again only when the aggregate reports are clean.
11. Incorrect reporting addresses:
    • Check rua= for typos and make sure it starts with mailto:.
    • If the address is on a different domain, publish an authorization record there, in the form yourdomain.com._report._dmarc.reportingdomain.com, so receivers will send the reports.
12. Security software interference:
    • Find out whether your gateway or filter changes message bodies, subjects or links after you sign them.
    • Turn those changes off for your own outbound mail, or exempt it, so the DKIM signature stays valid.
13. Duplicate DMARC records:
    • Run dig +short TXT _dmarc.yourdomain.com, and if it returns more than one line, delete the extra record.
14. Syntax errors in the record:
    • Check the record starts with v=DMARC1, separates tags with semicolons, and uses valid values like p=none, p=quarantine or p=reject.
    • Run it through the DMARC record checker to catch anything you missed.
15. Too many SPF lookups:
    • Remove include: entries for services you no longer use.
    • Where you can, consolidate senders so the record stays at or under 10 lookups.
16. Missing or rotated DKIM keys:
    • Confirm the selector in the DKIM-Signature header (s=) matches a key published in DNS.
    • When you rotate keys, publish the new key before the sender starts signing with it.
17. Mailing lists and relays that alter messages:
    • Sign with DKIM on your own domain as the main defense, and prefer relays that support ARC.

Quick answers to common DMARC questions

What does a DMARC failure mean? It means the message didn’t pass DMARC when the receiving server checked it. Neither SPF nor DKIM both passed and matched the domain in your From address. What happens next depends on your policy: nothing at p=none, spam folder at p=quarantine, blocked at p=reject.

What does it mean when an email fails DMARC authentication? The same thing, seen from the recipient’s side. The sender’s domain couldn’t be verified as the real source of the message, so the receiver applies the sender’s published policy, or its own filtering, to decide what to do with it.

How do I check if my DMARC is working? Three checks. First, look up _dmarc.yourdomain.com and confirm one valid record exists. Second, send a test message and look for dmarc=pass in the Authentication-Results header. Third, confirm aggregate reports are arriving at your rua= address and read them for failing sources. A lookup alone only proves the record exists.

Is DMARC really necessary? For most senders, yes. Without it, anyone can send mail that looks like it comes from your domain and nothing tells receivers to stop it. It is also a requirement for bulk senders: Gmail and Yahoo (from 2024) and Outlook (from 2025) require DMARC from senders at 5,000 or more emails a day. Even below that volume, p=none is the minimum starting point.

How do I pass DMARC verification? Make sure at least one of SPF or DKIM passes and aligns with your From domain. In practice that means setting up custom domain authentication at every sending platform so DKIM signs with your own domain, publishing one valid DMARC record, and covering every sending source. Then check a real test message’s headers for dmarc=pass.

How can I fix the “DMARC Policy Not Enabled” error? This error means your domain has either no DMARC record or a record set to p=none, which only monitors. If there’s no record, publish one starting at p=none. If you’re already at p=none, read your aggregate reports, authenticate every legitimate sender, then move to p=quarantine and later p=reject. Staying at p=none indefinitely is the usual reason the error keeps appearing.

What is a DMARC permanent error? Usually it’s an SMTP rejection like 550 5.7.26, meaning the receiving server permanently refused your message because it failed authentication checks. It often shows up soon after a domain moves to p=quarantine or p=reject with a sender that isn’t aligned. The code doesn’t say which check failed, so read the Authentication-Results header or your aggregate reports. You may also see permerror in a header, which generally means the record itself couldn’t be evaluated, for example because it’s malformed. Check the record’s syntax and that there is only one.

How do I troubleshoot DMARC issues and fix a DMARC error? Work through the causes and solutions above in order: duplicate record, record syntax, SPF and DKIM individually, alignment, then unauthenticated sources in your reports. The checklist under the spam question above puts that in sequence.

The bottom line

• A record checker confirming your record exists is not the same as confirming it works. Alignment problems don’t show up in a basic lookup.
• Duplicate records are the first thing to rule out, since receivers treat the domain as having no valid policy, and every other symptom can trace back to this.
• Alignment, not authentication, is the most common cause of failure. SPF and DKIM passing under your ESP’s domain doesn’t mean DMARC passes against your From domain.
• Start at p=none, and tighten only when your reports are clean. Each platform has its own common failure mode, so check the platform section above before assuming your DMARC record itself is wrong.

About this guide

The expert answers in this post come from Prasanth of the InboxEagle product team, collected in October 2026. They reflect hands-on experience with customer domains, not a survey or a measured dataset, and they come from one person. Everything outside the marked quotes is ours: the setup steps, report walkthrough, causes, solutions and quick answers were written with reference to public vendor guides and the SMTP status code standard (RFC 7372), not drawn from Prasanth’s answers. Provider consoles change their menus often, so confirm the exact navigation paths in your provider’s current documentation.