Free DMARC checker

Why email security matters for a small business

Fake emails sent in your name are one of the cheapest frauds there is. A fake invoice, a "new bank details" message to a customer or a password reset that never came from you all rely on the same gap: nothing tells the receiving mail server that the email isn't really from your domain. In our October 2026 audit of 359 South West small business websites, about half had no DMARC record at all, so any of those domains could be spoofed freely. You can see the full figures in our South West websites research.

Three DNS records close that gap: SPF, DKIM and DMARC. This checker reads all three, plus your MX and BIMI records, grades the set from A to F and writes a corrected DMARC record for you to paste in. It only reads public DNS. It doesn't send any email, and nothing on your mail server changes.

What DMARC does

Without DMARC, anyone can send an email that claims to come from your domain, and receiving servers have no instruction from you on what to do about it. That's how invoice-fraud and fake-supplier emails work. DMARC is a record at _dmarc.yourdomain that tells receivers to check SPF and DKIM against the From address people actually see, and what to do when those checks fail: nothing (p=none), send to spam (p=quarantine) or refuse the message (p=reject). It also asks receivers to send you reports, so you can see every service sending as your domain.

Reading your result

No DMARC record is the biggest gap: your domain can be spoofed freely, and Gmail and Yahoo expect bulk senders to publish one. p=none is a sensible starting point, but it only monitors. p=quarantine or p=reject is where you want to end up. We also flag a missing reporting address (rua=), a weaker policy for subdomains (sp=), and records that are inherited from a parent domain.

Each record gets its own card with what we found, why it matters and what to do. Green means it's set up well, amber means it works but could be stronger, and red means it's missing or broken. "Could not be checked" means a lookup failed or timed out, so we haven't guessed. Try again in a minute before changing anything.

How the grade works

The grade runs from A to F, and the report puts the top fix first. DMARC carries the most weight, because it's the record that actually stops spoofing. A p=reject policy with a reporting address counts for far more than p=none. SPF and DKIM make up most of the rest, and having at least one mail server helps a little.

Some problems cap the grade however well the rest scores:

• No usable DMARC record (missing, more than one, or no valid p=) caps you at D.
• A broken SPF record (more than one record, over 10 lookups, or an include that doesn't resolve) also caps you at D.
• An SPF record ending in +all, which lets anyone send as you, is an F.

If we can't find a DKIM key on any of the common selectors, you lose a few points rather than all of them, because your provider may use a selector we didn't try. In practice that means the best you can reach without a DKIM key we can see is B.

A domain with no mail servers is graded differently. If you never send email from it, the question is whether it's locked down: SPF ending in -all, DMARC at p=reject and ideally a null MX record. A parked domain set up that way scores an A.

Your corrected DMARC record

When your DMARC record needs work, the result includes a corrected version you can paste in as a TXT record at _dmarc.yourdomain. It keeps the parts of your current record that are valid and drops the tags DMARCbis has retired. It moves you forward one safe step at a time:

• No record: you get p=none with a reporting address, so you can see who sends as you before blocking anything.
• p=none with reporting: you get p=quarantine.
• p=none without reporting: you get the reporting address first, and the policy stays at none for now.
• A domain that sends no email: you get p=reject straight away, as there is nothing legitimate to break.

If we add a reporting address for you, it's a placeholder (dmarc-reports@yourdomain). Replace it with a mailbox you actually read, or with the address your DMARC reporting service gives you, before you publish.

DMARCbis: what changed

DMARCbis is the updated DMARC standard that replaces the original specification. Three changes affect your record. The pct= tag is gone, so receivers following the new standard apply your policy to all failing mail rather than a percentage; if your record still uses pct= to roll out gradually, that no longer works reliably. A new t=y flag marks a testing phase instead. And np= lets you set a policy for subdomains that don't exist, which closes a common spoofing gap. This checker reports all three.

SPF and the 10-lookup limit

SPF is a TXT record listing the services allowed to send email as your domain. Receivers follow each include: in your record to build the full list, and the standard caps that at 10 DNS lookups. Go over and SPF fails outright, even for mail that is legitimate.

It's easy to hit the limit without noticing. Google Workspace, Microsoft 365, a newsletter tool, a booking system and an accounts package can each add one or more lookups, and some of their includes contain includes of their own. The result shows the include tree with the lookup count for each branch, so you can see which service is using up your allowance and which you might remove.

A record should end in ~all (treat others as suspicious) or -all (reject others), never +all, which allows anyone to send. You can only have one SPF record per domain. Two records is a permanent error, and receivers then treat SPF as failed. The dedicated SPF checker goes deeper on a single record, and our guide to SPF, DKIM and DMARC explains how the three fit together.

DKIM and selectors

DKIM signs each outgoing message with a private key, and publishes the matching public key in DNS under a selector name, such as selector1._domainkey.yourdomain. Receivers use it to confirm the message really came from you and wasn't changed on the way.

There is no way to list a domain's selectors from the outside, so we try the common ones. They include those used by Google Workspace, Microsoft 365, Zoho, Proton, Fastmail, iCloud custom domains, Mailchimp, SendGrid, Postmark, Mailjet and Campaign Monitor, and the result lists every selector we tried. If none are found, that doesn't prove DKIM is off: your provider may use a selector we didn't try. Your email provider's setup page will tell you the exact name.

When we do find a key, we check that it hasn't been revoked and that it's longer than 1024 bits. Older 1024-bit keys still work, but they're weak by today's standards, and most providers let you switch to 2048 bits from the same settings page.

MX records

MX records say which servers receive email for your domain. We read them to work out your provider where we can, and to tell whether the domain is used for email at all.

A domain that never sends or receives email should say so, with a null MX record (a single MX of . with priority 0), SPF set to v=spf1 -all and a strict DMARC policy. Unused and parked domains are a favourite for spoofing precisely because nobody is watching them, and those three records tell every receiver to throw away anything claiming to come from them.

BIMI

BIMI lets your logo appear next to your messages in some inboxes. It sits on top of DMARC: mailbox providers generally only show a logo when your policy is p=quarantine or p=reject. We check whether a BIMI record is published, whether it points to a logo (l=), and whether it includes a certificate (a=), which some mail apps, including Gmail, need before they show the logo.

BIMI is optional and doesn't affect whether your email is delivered. It only earns bonus points here when the record has a logo and your DMARC policy is already quarantine or reject, so treat it as a finishing touch once the rest is solid.

Getting to p=reject safely

Most domains can reach a strict policy in a few weeks without losing any genuine email:

1. Publish DMARC at p=none with a reporting address you read. Leave it for two to four weeks.
2. Read the reports, or put them through a free DMARC report viewer. Every service that sends as your domain will show up: your mail provider, newsletter tool, website contact form, invoicing system and anything else.
3. Fix each legitimate sender so it passes SPF or DKIM for your domain. Usually that means adding its include to SPF or switching on DKIM in its settings.
4. Move to p=quarantine and watch the reports for another couple of weeks.
5. When the reports show only fakes failing, move to p=reject.

Run this checker after each change. DNS changes usually spread within an hour. We keep each result for 24 hours, so if the checker shows an earlier result, press "Re-check now" to read your live records again. Once your email is in order, run the full AuditCrow scan to check the rest of your website.