Try the DKIM Checker

The Complete Email Authentication Audit: How to Check SPF, DKIM, DMARC, PTR, and BIMI

Most organisations have never systematically audited their full email authentication stack. Here's the complete 8-step process: inventorying all sending services, auditing SPF, DKIM, DMARC, PTR, and BIMI, sending a test to verify all pass, and setting up ongoing monitoring.

By sadiqbd Β· June 9, 2026

Share:
The Complete Email Authentication Audit: How to Check SPF, DKIM, DMARC, PTR, and BIMI

A complete email authentication audit takes about 30 minutes β€” and most organisations have never done one

The typical situation: SPF was set up years ago, someone added DKIM for the primary mail provider, DMARC was added later at p=none, and various other services have been added since without anyone systematically checking whether they're all correctly configured. The result is an authentication infrastructure that works for the main mail flow but has gaps that could allow spoofing or cause deliverability failures.

A systematic audit closes these gaps. Here's the process.


Step 1: Inventory all email-sending services

Before checking DNS, list every service that sends email on behalf of your domain. This is often more than people expect:

  • Primary email provider (Google Workspace, Microsoft 365, etc.)
  • Transactional email (Mailgun, Postmark, SendGrid, AWS SES)
  • Marketing platform (Mailchimp, HubSpot, ActiveCampaign, Klaviyo)
  • CRM with email sending (Salesforce, HubSpot CRM)
  • Help desk / customer support (Zendesk, Freshdesk, Intercom)
  • E-commerce platform (Shopify, WooCommerce order notifications)
  • Invoice/billing system
  • HR/payroll system
  • Any custom application that sends email
  • Automated alert systems (monitoring, error notifications)

Tools to identify unknown senders: run DMARC monitoring for 4–6 weeks at p=none β€” the aggregate reports will show every IP address sending email claiming to be from your domain. Cross-reference against your known list.


Step 2: Audit SPF

Check what your SPF record currently says:

dig TXT yourdomain.com | grep spf

Or use the SPF Lookup tool at sadiqbd.com.

Check for these issues:

Multiple SPF records β€” only one SPF TXT record is allowed at the domain apex:

# Wrong: two SPF records
yourdomain.com  TXT "v=spf1 include:google.com ~all"
yourdomain.com  TXT "v=spf1 include:mailchimp.com ~all"

# Correct: one combined record
yourdomain.com  TXT "v=spf1 include:google.com include:mailchimp.com ~all"

DNS lookup limit exceeded β€” count the DNS lookups. If more than 10, investigate SPF flattening (see the SPF post). Use an online SPF lookup count tool.

Missing services β€” does every service in your inventory have its SPF include or IP listed? For each service, check their documentation for the correct SPF include value.

Overly permissive β€” does the record end with +all? This allows any server to send as your domain. Change to ~all or -all.


Step 3: Audit DKIM

For each service in your inventory, verify a DKIM selector is correctly published.

For each service:

  1. Find the selector name (usually in the service's DNS setup documentation, or visible in the DKIM-Signature header of an email sent from that service)
  2. Query: dig TXT {selector}._domainkey.yourdomain.com
  3. The result should show a TXT record containing v=DKIM1; k=rsa; p={public-key}

Common issues to look for:

Missing selectors β€” a service was set up but the DNS record was never published or has expired.

Wrong domain β€” the DKIM signature uses the provider's domain, not yours. Check the d= value in the DKIM-Signature header of an email from each service. It should match your domain, not the provider's.

Short key length β€” keys should be 2048 bits. 512-bit keys are no longer accepted by many servers. Check the key length: count the characters in the p= base64 string. A 512-bit key is about 88 characters; 1024-bit is about 216 characters; 2048-bit is about 392 characters.

Old selectors β€” selectors from services you've stopped using. These aren't security risks but are DNS clutter.


Step 4: Audit DMARC

Check your DMARC record:

dig TXT _dmarc.yourdomain.com

Verify:

  • Record exists at _dmarc.yourdomain.com (not at the domain root)
  • rua= is set to a monitored address for aggregate reports
  • Current policy (p=): where are you on the path to p=reject?
  • If p=quarantine or p=reject: are all legitimate senders passing? Check DMARC reports for failures.
  • pct= value: if less than 100, it's transitional β€” plan to reach 100%

Step 5: Audit PTR (reverse DNS)

For every IP address your mail servers send from:

dig -x {sending-ip}

The result should return a hostname that:

  1. Is a meaningful hostname (not just the raw IP formatted as a hostname)
  2. Forward-resolves back to the same IP (FCrDNS check)

Contact your hosting provider to set PTR records if missing or incorrect.


Step 6: Check BIMI status

If DMARC is at p=quarantine or p=reject, BIMI is possible:

dig TXT default._bimi.yourdomain.com

If no record exists and you want BIMI, see the BIMI setup guide for implementation steps.


Step 7: Test with a full authentication check

Send a test email to a Gmail account and view the original message headers. Look for the Authentication-Results header:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@yourdomain.com header.s=selector1
       spf=pass (google.com: domain of sender@yourdomain.com designates X.X.X.X as permitted sender)
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=yourdomain.com

All three should pass. DMARC should show your intended policy. If any fail, return to the relevant step.


Step 8: Ongoing monitoring

Set up recurring monitoring:

  • Google Postmaster Tools: domain reputation, spam rate, authentication failure rate
  • DMARC aggregate reports: weekly or monthly review (or use a tool: dmarcian, Valimail, Postmark DMARC Digests)
  • Blacklist monitoring: MXToolbox Monitoring (free tier), check sending IPs monthly
  • DNS change alerts: services like DNSWatch or Constellix alerts notify when DNS records change unexpectedly

How to use the DKIM Checker on sadiqbd.com

  1. Enter your domain and selector β€” for each service in your inventory
  2. Verify the key is present and valid β€” check key type (RSA), key length indicator, and record syntax
  3. Repeat for each selector β€” a complete DKIM audit requires checking every selector in use

Frequently Asked Questions

How often should I audit email authentication? After any change to sending infrastructure (new service, new IP, ESP migration). As a routine check: quarterly for organisations sending significant email volume, annually for low-volume senders.

What's the most common authentication failure found in audits? Missing DKIM for secondary sending services β€” the primary mail provider is correctly configured but a CRM, billing system, or help desk platform is sending without DKIM alignment. This shows up in DMARC reports as SPF pass + DKIM fail for specific IP ranges.

Is the DKIM Checker free? Yes β€” completely free, no sign-up required.


A systematic email authentication audit takes 30–60 minutes and produces a definitive picture of where authentication is working and where it has gaps. The audit is most useful done once thoroughly, then maintained with ongoing monitoring.

Try the DKIM Checker free at sadiqbd.com β€” verify any DKIM selector for any domain instantly.

Share:
Try the related tool:
Open DKIM Checker

More DKIM Checker articles