DMARC Is Failing: How to Fix Your Email Records
DMARC fails when an email passes neither SPF nor DKIM in a way that matches the domain in your From address, and you fix it by finding the sender that fails and correcting its SPF or DKIM record in DNS.
This guide is for owners of small business sites, online stores and SaaS apps whose email is bouncing or landing in spam. You don't need to be an engineer. You'll learn how to read a failure, check your records with a few copy-paste commands, fix the usual causes and then tighten your policy safely.
What DMARC actually checks
DMARC (Domain-based Message Authentication, Reporting and Conformance) is a rule you publish in DNS. DNS is the public address book for your domain. The rule tells receiving mail servers what to do with email that claims to come from you but can't prove it.
DMARC leans on two older checks:
- SPF (Sender Policy Framework): a list of servers allowed to send mail for your domain.
- DKIM (DomainKeys Identified Mail): a digital signature added to each message and checked against a public key in your DNS.
A message passes DMARC when at least one of those checks passes and is aligned. Aligned means the domain that passed matches the domain in the visible From address. The rules are in RFC 7489.
This is why "SPF says pass" and "DMARC says fail" can both be true. The check passed, but for a different domain than the one your customer sees.
Common causes and fixes at a glance
| What you see | Likely cause | Fix |
|---|---|---|
| spf=fail or softfail | Sending service missing from your SPF record | Add its include to SPF |
| spf=permerror | Two SPF records, or more than 10 DNS lookups | Merge into one record, trim lookups |
| spf=pass but dmarc=fail | SPF passed for the sender's domain, not yours | Turn on DKIM signing with your domain |
| dkim=none or fail | DKIM never enabled, or the DNS key is wrong | Publish the DKIM record your provider gives you |
| dmarc=none (no record) | No _dmarc record, or published at the wrong name | Create the TXT record at _dmarc |
| Mail bounces after a policy change | Policy is quarantine or reject while a sender still fails | Drop to p=none, fix senders, tighten again |
Step 1: Read the failure in the email headers
Send a test message from the failing address to a Gmail account. Open it, click the three dots, then Show original. Find the lines that look like this:
Authentication-Results: mx.google.com;
spf=pass smtp.mailfrom=bounce.mailtool.com;
dkim=none;
dmarc=fail header.from=yourstore.com
This example tells the whole story. SPF passed, but for bounce.mailtool.com, not yourstore.com. There is no DKIM signature. So nothing is aligned and DMARC fails.
Write down which tool sent the message. Contact forms, invoicing apps, newsletter tools and your store platform often send mail as you, and each needs its own setup.
Step 2: Check your current DNS records
Run these in a terminal (Mac or Linux), replacing yourstore.com with your domain. On Windows, use nslookup -type=TXT yourstore.com.
dig TXT yourstore.com +short
dig TXT _dmarc.yourstore.com +short
In the first result, look for one line that starts with v=spf1. In the second, look for one line that starts with v=DMARC1. You can also run the free email spoofing checker to see how your domain looks from the outside.
Step 3: Fix your SPF record
SPF lives in a TXT record on your root domain. Three rules cause most problems:
- Publish only one SPF record. Two
v=spf1records cause a permanent error. Merge them into one. - Include every service that sends as you. Use the exact include value from each provider's docs.
- Stay under 10 DNS lookups. Each
include,a,mxandredirectcounts, and so does every lookup inside the services you include. This is the usual reason a short-looking record goes over the limit. Going over also causes a permanent error (RFC 7208, section 4.6.4).
A typical record for a business on Google Workspace that also uses one newsletter tool looks like this:
v=spf1 include:_spf.google.com include:servers.mcsv.net ~all
For Microsoft 365 the include is include:spf.protection.outlook.com. The servers.mcsv.net value above is Mailchimp's. Always confirm the value in your own provider's documentation, because it can differ by service.
The ending ~all means "treat other servers as suspicious". -all means "reject other servers". Start with ~all and move to -all only once you're sure every sender is listed.
Don't paste the same service in twice, and remove services you no longer use. Old includes waste your lookup budget.
Step 4: Turn on DKIM for every sender
DKIM is the more reliable path to DMARC alignment. SPF often breaks when mail is forwarded. A DKIM signature survives forwarding if the message isn't altered.
Your email provider generates a key and gives you a DNS record to publish. Here is where to find it for the two most common setups:
- Google Workspace: Admin console, then Apps, Google Workspace, Gmail, Authenticate email. Generate a key, publish the TXT record at the name shown (usually
google._domainkey), then click Start authentication. See Google's DKIM guide. - Microsoft 365: Defender portal, then Email and collaboration, Policies and rules, Threat policies, Email authentication settings, then the DKIM tab. Publish the two CNAME records it shows (
selector1._domainkeyandselector2._domainkey), then enable signing.
Verify the key is live with this command (swap in your own selector):
dig TXT google._domainkey.yourstore.com +short
If it returns nothing, the record is missing, or your DNS host added your domain to the end of the name twice. Many hosts append the domain for you, so enter only google._domainkey in the name field.
Step 5: Fix third-party senders
This is the cause behind most surprise failures. Your newsletter tool, helpdesk, CRM, invoicing app or WordPress contact form sends mail with your address in the From field. Unless you set it up, it signs with its own domain.
For each one:
- Open its settings and look for Domain authentication, Sender authentication or Verify domain.
- Add the DKIM (and sometimes SPF or CNAME) records it gives you to your DNS.
- Send a test and confirm the headers show
dkim=pass header.d=yourstore.com.
On WordPress, plugins that send through your web host's mail function are a common weak spot. A transactional email service connected through an SMTP plugin such as WP Mail SMTP, with its DKIM records published, is much more reliable. Shopify stores should authenticate their sending domain under Settings, Notifications, Sender email.
Step 6: Publish a safe DMARC record
If you have no DMARC record, add a TXT record named _dmarc with this value:
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourstore.com
Make sure dmarc-reports@yourstore.com is a real mailbox or alias (or use the address your report reader gives you), because the XML reports go there and can pile up.
p=none means "monitor only, don't block anything". The rua address receives daily summary reports (XML files) showing who is sending mail as you and whether it passes. A free report reader makes these easy to scan. Google explains the tags in its DMARC setup guide.
Emergency note: if your policy is already p=quarantine or p=reject and real mail is bouncing, you can change it to p=none right now. This stops the damage while you fix the failing senders. Then tighten it again.
Step 7: Tighten the policy gradually
Once your reports show your real senders passing for a couple of weeks, move up one level at a time:
p=none: monitor only.p=quarantine; pct=25: send 25 percent of failing mail to spam, then raise the number.p=quarantine: all failing mail goes to spam.p=reject: failing mail is refused. This gives the strongest protection against people spoofing your domain.
Don't rush to reject. A forgotten sender, like an old invoicing tool, would silently stop delivering.
Why this matters beyond spam folders
Google has required SPF or DKIM from all senders, and DMARC from bulk senders, since 2024 (see Google's sender guidelines). Yahoo introduced similar requirements. Even small senders benefit, because a proper setup makes your mail look trustworthy and makes it harder for scammers to impersonate you to your customers.
If you also want to know whether your wider website has weak spots, our free website security check is a quick passive look. Our guide on whether your website is hackable covers the rest.
Quick checklist
- [ ] One SPF record only, under 10 lookups
- [ ] DKIM enabled for your main email provider
- [ ] DKIM or domain authentication set up for each third-party sender
- [ ] A
_dmarcTXT record exists with aruaaddress - [ ] Test email shows
dmarc=passin the headers - [ ] Reports reviewed before moving beyond
p=none
Where a human audit fits
Email records are one slice of your site's security. If you'd like a person to review the whole thing, including email spoofing exposure, with a written report and exact fixes, the Circuit audit is $49 one-time. It's a focused manual audit for small sites, not an enterprise pentest or a compliance certificate. You can start with the free check and decide later.
Key takeaways
- DMARC passes only when SPF or DKIM passes and matches your From domain. Read the Authentication-Results header to see which part fails.
- Keep exactly one SPF record, include every sending service, and stay under 10 DNS lookups.
- Enable DKIM for your main provider and every third-party tool. It is the most dependable route to alignment.
- Start with
p=noneand reports, then move to quarantine and reject step by step. - If a strict policy is bouncing real mail, drop back to
p=nonefirst, then fix.
A real human security engineer audits your whole site by hand and sends a full report: every issue, its severity, and the exact fix. From $49, with a 14-day money-back guarantee.
See pricing