How to Check a DMARC Record (and Fix a Fail)

The short answer

To check a DMARC record, look up the TXT record at _dmarc.yourdomain.com: run dig TXT _dmarc.yourdomain.com +short, or enter your domain in the DMARC and SPF checker. A healthy record is a single line that starts with v=DMARC1 and contains a p= policy.

A "DMARC fail" is a different question, and the lookup cannot answer it. A message fails DMARC when neither SPF nor DKIM passed in alignment with the domain in the visible From address. A record can be perfect and the mail can still fail, which is why the rest of this page is about reading the failure and not only the record.

We will do both: check the record, then read a real failure and fix its cause. If you cannot edit your DNS because the account is with a former developer, start with getting your website back from a previous developer, because every fix below needs access to the DNS zone.

Step 1: Check that the record exists and is well formed

DMARC lives in DNS, in one TXT record at the name _dmarc in front of your domain. There are three ways to read it.

With the checker. Enter the domain in the DMARC and SPF checker. It reads the live DNS for both records and returns a verdict and the exact record it found.

With a command. On macOS or Linux:

dig TXT _dmarc.yourdomain.com +short

On Windows, in PowerShell:

Resolve-DnsName -Type TXT _dmarc.yourdomain.com

With a general DNS tool. The DNS checker shows any record type for any name, which is useful when you want to look at the TXT record and the MX records side by side.

What a good result looks like:

• Exactly one record. If two come back, a receiver may discard both. The current DMARC specification, RFC 9989, says that when more than one DMARC record is found for a target, all of them are discarded. Delete the extra one.
• It starts with v=DMARC1. A record that does not is ignored, and a stray space or a missing semicolon can have the same effect.
• It has a p= tag. The values are none (no handling preference), quarantine (treat failures as suspicious) and reject (treat failures as not valid). Google's DMARC setup guide lists the same three.
• It has an rua= address, ideally a dedicated mailbox or a reporting service, because the aggregate reports are how you find out which senders are failing. Google recommends always including it.

If nothing comes back, no record is published at that name, and the first fix is simply to add one. A safe starting record, with a mailbox you control in place of the placeholder, is:

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

What our checker can and cannot tell you

We wrote the checker, so we can be exact about its limits. It reads the TXT records for the domain and for _dmarc. plus the domain, reports whether an SPF and a DMARC record exist, and reads the SPF ending (-all, ~all) and the DMARC policy. It tells you p=none only monitors. It also warns when more than one SPF or DMARC record is published, since a duplicate can make receivers discard both.

It does not send a test message, so it cannot tell you whether your mail passes DMARC. It does not count the DNS lookups in your SPF record, and it does not follow a DKIM selector unless you use the separate DKIM checker and give it one. A green result means the record is published and readable. Treat it as step one, not as proof that your mail is authenticated.

Step 2: Read the failure in a real message

A DMARC fail is a property of a received message, so the evidence is in that message's headers. In Gmail, open the message, choose More next to Reply, then Show original, as described in Gmail's help. In the headers you want the Authentication-Results line, a standard header defined in RFC 8601. It looks like this (placeholder domains):

Authentication-Results: mx.google.com;
  dkim=pass header.i=@mailer.example header.s=s1;
  spf=pass smtp.mailfrom=bounce.mailer.example;
  dmarc=fail header.from=yourdomain.com

Read that carefully, because it is the single most common surprise. SPF passed. DKIM passed. DMARC failed. That is not a contradiction. DMARC does not ask whether SPF or DKIM passed. It asks whether the domain that passed is the same domain as the one in the From address.

The rule comes straight from the standard. In the DMARC specification a message passes when at least one of SPF or DKIM produces a pass on an identifier that aligns with the From domain. Alignment is relaxed by default (the two domains must share an organisational domain, so mail.yourdomain.com aligns with yourdomain.com) and strict if you ask for it with aspf or adkim. In the example above, the passing domain is mailer.example, a sending service, and the From domain is yourdomain.com, so nothing aligns and DMARC fails.

Gmail's own sender rules say the same thing: for direct email, the domain in the From header must be aligned with either the SPF domain or the DKIM domain.

Step 3: The six causes, in the order we would check them

1. A third-party sender is signing with its own domain. This is the example above, and it is where we would look first. Newsletter tools, invoicing software, CRMs and helpdesks all send mail "from" your address by default, but sign it with their domain. The fix is in that tool's settings: look for "domain authentication", "custom DKIM" or "branded sending domain", publish the records it gives you, and wait for it to show as verified. Then send a test and read the headers again: you want header.i=@yourdomain.com (or a subdomain) on the DKIM line.

2. DKIM is not enabled for your own domain. On Google Workspace and Microsoft 365, DKIM signing for your domain is something an administrator switches on after publishing a key. Until then, mail is signed with a default domain that does not align. Check the key exists with the DKIM checker; you need the selector from your provider's settings (Google Workspace uses google by default, and Microsoft 365 uses selector1 and selector2).

3. Two SPF records, or too many lookups. A domain must publish one SPF record. If more than one comes back, RFC 7208 says the result is a permanent error. SPF is also limited to 10 mechanisms and modifiers that cause DNS lookups (include, a, mx, exists and redirect count; ip4, ip6 and all do not), and exceeding that limit is also a permanent error. Every new service people add tends to arrive as one more include, so a record that worked last year can quietly break. Merge the records into one, and remove includes for services you no longer use. Our checker does not count lookups, so use a tool that does if you suspect this.

4. The DMARC record is duplicated or at the wrong name. It must be a TXT record at _dmarc.yourdomain.com, not at the apex and not at dmarc.yourdomain.com. Many DNS panels append your domain automatically, so entering the full name produces _dmarc.yourdomain.com.yourdomain.com. Look the record up from the outside, as in step 1, and confirm the name you queried is the one that answers.

5. Forwarding and mailing lists. When a message is forwarded, the forwarder's server is not in your SPF record, so SPF fails. When a list changes the subject or adds a footer, the DKIM signature no longer matches the body, so DKIM fails. Either way, an aligned pass is lost. You cannot fix a stranger's forwarder, which is the main reason DKIM is the more reliable of the two to rely on: a signature survives forwarding when the content is not modified.

6. A subdomain you forgot. Mail sent from news.yourdomain.com or app.yourdomain.com is evaluated against that name. A subdomain inherits the organisational domain's policy unless it publishes its own, and many sending tools use their own subdomain. Check the exact From domain in the failing message, not just your main one.

Step 4: Tighten the policy only after the reports are clean

Do not jump to p=reject. A policy applies to every message that claims to be from your domain, including legitimate mail from a tool you forgot about, and a reject setting will cause that mail to be refused.

The sequence Google recommends is to start with p=none, review the authentication results and fix any legitimate mail that fails, and then move to quarantine or reject. The reports sent to your rua address are what make that review possible. They are XML files, and they are easier to read through a free reporting service than by hand.

One point of vocabulary for anyone reading older guides. Many of them tell you to ramp up with pct=25, then 50, then 100, which applied a policy to a share of failing mail. RFC 9989, which obsoletes the older RFC 7489, removes pct and adds a t tag for test mode instead. Receivers adopt a new standard at their own pace, so for now a safe habit is the staged approach above: stay at none until your reports show every legitimate sender passing, then enforce.

Why it matters even if you send very little

Mailbox providers now ask for authentication, not only recommend it. Google's rules for senders say that all senders need SPF or DKIM, and that anyone sending more than 5,000 messages a day to Gmail accounts needs SPF, DKIM and DMARC, with the From domain aligned to one of them. A small business sending a few hundred messages is below the bulk threshold, but the mail that reaches Gmail is still judged on authentication, and unauthenticated mail might be marked as spam.

There is a second reason that has nothing to do with deliverability. Without an enforced DMARC policy, anyone can send a message that appears to come from your domain, and receivers have no instruction on what to do with it.

A ten-minute checklist

1. Run the DMARC and SPF checker on your domain. Confirm one DMARC record, a p= value and an rua= address.
2. Send a message from every system that sends as you (your mailbox, your website forms, your newsletter, your invoicing tool) to a Gmail address.
3. For each one, open Show original and read the Authentication-Results line.
4. Wherever dmarc=fail appears, compare the From domain with the passing SPF and DKIM domains. The mismatch names the cause.
5. Fix the sender's domain authentication, merge duplicate records, and re-test.
6. Leave the policy at none until the reports are clean, then move to quarantine, and reject when you are sure.

Frequently asked questions

What does DMARC fail mean?

It means the message did not pass SPF or DKIM in alignment with the domain in its From address. The mail may have been delivered, filed as spam or rejected, depending on the sender's p= policy and the receiver's own rules.

How do I check my DMARC record?

Query the TXT record at _dmarc.yourdomain.com, with dig TXT _dmarc.yourdomain.com +short, Resolve-DnsName on Windows, or the DMARC and SPF checker. Look for one record starting with v=DMARC1 and a p= policy.

Why does DMARC fail when SPF and DKIM pass?

Because DMARC requires the domain that passed to match the From domain. A sending service that signs and bounces mail with its own domain passes both checks for itself and fails DMARC for you. Set up custom domain authentication in that service.

Is p=none enough?

For monitoring, yes, and it is the right place to start. It asks receivers to take no specific action on failures, so it does not stop others from sending as your domain. Once your reports are clean, move to quarantine or reject.

Can I have two DMARC records?

No. Publish one. The current specification says that when multiple DMARC records are found, all of them are discarded, so a duplicate can switch DMARC off entirely.

How long does a DMARC change take to apply?

As long as your DNS record's time to live (TTL) and the receiver's cache allow, which is often minutes to a few hours. The record can be looked up from outside as soon as it is published, so check it there before you send your test messages.

Do I need DMARC if I only send a few emails?

If you send fewer than 5,000 messages a day to Gmail, DMARC is not mandatory for Gmail's bulk rules, but SPF or DKIM is required of everyone, and a published DMARC record at p=none costs nothing and gives you reports.

When a fix is bigger than a DNS record

Most DMARC failures are one setting in one tool. The harder cases are a domain with years of accumulated records, a mail setup split across several providers, or a website and application that send transactional mail through code nobody has read in a while. That is the kind of job our website fixes and maintenance work covers, and where the setup involves servers or cloud accounts, cloud and DevOps. If you would rather have it checked once and written up, tell us what you send and from where and we will say what we would change.