Here is a deliverability problem I see a lot: a business says its invoices "just stopped arriving," and nothing changed on their side. When you look at their DNS, you find two SPF records, a DKIM key that was never published, and no DMARC record at all. The mail isn't broken. It just can't prove it's theirs, so receiving servers stop trusting it.

I'm Muhammad Ali Mughal, and I built PixelValut, a set of free developer and network tools that includes DNS, MX, SPF, DKIM and DMARC checkers. I use them for exactly this kind of debugging. This guide walks through how to check a domain's email authentication records yourself in about ten minutes, what each record should look like, and the mistakes I see most often.

The 60-second version

Three DNS records work together to prove an email really came from your domain:

• SPF lists which servers are allowed to send mail for your domain.
• DKIM adds a cryptographic signature to each message; the public key lives in DNS.
• DMARC tells receivers what to do when SPF or DKIM fail, and where to send reports.

All three are TXT records. You don't need special access to check them. Anyone can look them up, which is also why attackers check them before spoofing a domain.

Step 1: Find out who sends mail for you

Before checking records, make a list of everything that sends email as your domain. People usually forget half of it:

• Your mailbox provider (Google Workspace, Microsoft 365, Zoho, etc.)
• Your website or app (Laravel, WordPress, a contact form plugin)
• Transactional email services (password resets, receipts)
• Marketing and newsletter tools
• Helpdesk, CRM and invoicing software

Every one of these needs to be covered by SPF, DKIM or ideally both. Missing one is the most common reason legitimate mail fails DMARC later.

Step 2: Check your MX and TXT records

Start with a general DNS lookup on your root domain and select MX and TXT. The MX records tell you which provider receives your mail, which is a good hint about who should also be in your SPF record.

In the TXT results, look for a line starting with v=spf1. That's your SPF record. You'll often see other TXT records too (domain verification tokens and so on). Those are fine; only the v=spf1 one matters here.

Step 3: Validate SPF

A healthy SPF record looks something like this:

v=spf1 include:_spf.example-mail.com include:mailer.example.net -all

Run your domain through the SPF record checker. It follows the include: and redirect= chains and counts DNS lookups. Here's what to look for:

Only one SPF record. If you have two TXT records that start with v=spf1, SPF evaluation returns an error. Merge them into a single record.

Ten DNS lookups or fewer. The SPF spec caps evaluation at 10 DNS-querying mechanisms (include, a, mx, exists, redirect, including nested ones). Each third-party service you add can bring several lookups with it. Go over 10 and receivers return a permanent error, which usually means SPF fails. Remove services you no longer use, and avoid ptr entirely.

A sensible ending. -all means "anything not listed should fail." ~all means "soft fail." ?all is neutral and +all lets the whole internet send as you. Never use +all. If you're unsure everything is listed, start with ~all and tighten later.

Every sender covered. Compare the includes against your list from Step 1.

Step 4: Check DKIM

DKIM is trickier to inspect because the record lives at a selector:

selector._domainkey.yourdomain.com

The selector is chosen by whoever signs your mail. To find it, open a message you sent, view the original or full headers, and find the DKIM-Signature header. The s= value is the selector and d= is the signing domain.

Then put the selector and domain into the DKIM record checker. You want to see:

• A record that exists and starts with v=DKIM1 (the version tag is optional but common)
• A public key in the p= tag. An empty p= means the key has been revoked.
• A reasonable key size. 2048-bit RSA is a good baseline; 1024-bit keys are increasingly considered weak.
• No leftover t=y testing flag if you've finished setting things up

Each sending service usually has its own selector, so check each one. If a service offers DKIM signing with your domain and you haven't enabled it, that's worth fixing. DKIM survives forwarding better than SPF does.

Step 5: Read your DMARC policy

DMARC lives at a fixed location:

_dmarc.yourdomain.com

A typical starting record:

v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r

Check it with the DMARC checker, which reads the policy tag by tag. The key tags:

• p= is the policy: none (monitor only), quarantine (send to spam), or reject (block).
• rua= is where aggregate reports go. Without it you're flying blind.
• sp= sets a policy for subdomains if it should differ.
• adkim= / aspf= control alignment: relaxed (r) or strict (s).
• pct= applies the policy to a percentage of failing mail during rollout.

The part people miss: alignment

DMARC doesn't just ask "did SPF or DKIM pass?" It asks whether they passed for the same domain as the visible From address. If your newsletter tool passes SPF for its own bounce domain but doesn't sign with DKIM for your domain, the message can pass SPF and still fail DMARC. That's why enabling custom-domain DKIM on every service matters so much.

Step 6: Roll out DMARC safely

Jumping straight to p=reject is how companies block their own invoices. The rollout I recommend:

1. p=none with rua reporting for two to four weeks. Read the reports and find every legitimate source that fails.
2. Fix SPF and DKIM for those sources.
3. Move to p=quarantine, optionally with pct=25, then raise it.
4. When reports are clean, move to p=reject.

Aggregate reports are XML files, and a single day can contain dozens of sending IPs. A DMARC report analyser helps a lot, but even skimming the source IPs and pass/fail counts will show you what you missed.

Common mistakes I keep seeing

• Two SPF records after adding a new tool. Always edit the existing record.
• Too many includes, pushing SPF over 10 lookups.
• DKIM published on the wrong host, like selector._domainkey.yourdomain.com.yourdomain.com because the DNS panel already appends the domain.
• DMARC at p=none forever. Monitoring is a phase, not a destination.
• Forgetting parked domains. Domains that never send mail should publish v=spf1 -all and a p=reject DMARC record so nobody can spoof them.
• Not re-checking after DNS changes. TTLs mean old values can linger for a while; check again after the TTL expires.

A quick checklist

• One SPF record, starting with v=spf1, under 10 lookups, ending in ~all or -all
• DKIM enabled for every sending service, keys published and at least 2048-bit where possible
• DMARC record at _dmarc with a rua address
• Plan in place to move from none to quarantine to reject
• Non-sending domains locked down

Wrapping up

Email authentication looks intimidating because it's three acronyms and a lot of semicolons. In practice it's a short checklist, and you can audit any domain with public lookups. I keep these checks on pixelvalut.com because I needed them myself for client work, and they're free with no signup. Start with the SPF record checker, then follow the DKIM and DMARC steps above.

If you want to find it again later, search for pixelvalut.com on Google.

Have you ever tracked down a deliverability problem to a DNS record? I'd love to hear the story in the comments.

emailsecurity #dns #devops #sysadmin #spf #dkim #dmarc #cybersecurity #emaildeliverability #webdev #infosec #devtools