How to check SPF, DKIM and DMARC yourself with dig

You can check your entire authentication setup with four DNS queries and one email header. The queries tell you what you have published; the header tells you what receivers actually concluded. You need both, because a perfect record set can still produce a DMARC failure through misalignment.

The four queries

dig +short TXT yourdomain.com                        # SPF
dig +short TXT selector1._domainkey.yourdomain.com   # DKIM
dig +short TXT _dmarc.yourdomain.com                 # DMARC
dig +short MX  yourdomain.com                        # MX

Append @8.8.8.8 or @1.1.1.1 to bypass your local resolver's cache, and compare: a difference between your resolver and a public one is propagation, not a mistake. On Windows without dig, use nslookup -type=txt _dmarc.yourdomain.com 8.8.8.8.

Reading the SPF result

Exactly one returned line should start with v=spf1:

"v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all"

Two checks no single query performs for you:

One record only. If two lines come back starting v=spf1, receivers return PermError and SPF fails for all your mail. Merge the mechanisms into one record and delete the other.

Ten lookups maximum. SPF permits at most 10 DNS-querying mechanisms per evaluation, counted recursively through includes, and at most two that return nothing. Count them by hand:

dig +short TXT _spf.google.com

That record contains further includes, each of which counts. A record with four ESP includes is usually over the limit, and over the limit means SPF fails entirely — not partially.

Finding your DKIM selector

This is where online checkers stop being useful: there is no way to enumerate selectors from DNS. You have to read the selector out of a real message. Open any delivered email's source and find:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yourdomain.com;
 s=selector1; h=from:to:subject:date; bh=...; b=...

s= is the selector, d= is the signing domain. Query that exact selector. Common selectors by platform, as a starting point only: google for Google Workspace, selector1 and selector2 for Microsoft 365, k1 for Mailchimp, mandrill for Mandrill, dkim or mail for many self-hosted setups. A valid record looks like:

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

A record that returns nothing usually means the host field got the domain appended twice, the key is split across two records instead of two quoted strings in one, or you are querying a selector that was rotated out. If the platform uses CNAME-based DKIM, dig +short CNAME shows the delegation and dig +short TXT on the same name still returns the key.

Reading the DMARC result

"v=DMARC1; p=quarantine; sp=none; rua=mailto:dmarc@yourdomain.com; fo=1; adkim=r; aspf=r"

• v=DMARC1 must come first, or the record is invalid.
• p= is the apex policy; sp= is the subdomain policy. Without sp=, subdomains inherit p=.
• rua= needs the full mailto: scheme. A bare address invalidates the tag.
• adkim/aspf default to r (relaxed): any subdomain of the organisational domain aligns. s demands an exact match.
• Only one DMARC record may exist at _dmarc. Two makes the policy undefined.

The MX and reverse DNS check

dig +short MX yourdomain.com
dig -x 203.0.113.9 +short

Lower MX priority numbers win. Targets must be hostnames with A records, never IP addresses and never CNAMEs. For reverse DNS, what receivers want is forward-confirmed: the IP resolves to a hostname and that hostname resolves back to the same IP, and it matches your SMTP banner. Only the IP's owner can publish the PTR.

The header check that the DNS queries cannot replace

Send a message to a mailbox on each provider you care about and read Authentication-Results:

Authentication-Results: mx.google.com;
  spf=pass smtp.mailfrom=yourdomain.com;
  dkim=pass header.i=@yourdomain.com;
  dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=yourdomain.com

Compare smtp.mailfrom and header.i against header.from. That comparison is alignment, and it is the only way to know which mechanism your DMARC pass depends on. A domain where SPF is unaligned and DKIM carries everything is fine — until DKIM breaks.

What not to do

• Do not trust a green tick in a sending platform's dashboard as proof of DMARC alignment. It means the platform can send, not that receivers credit the mail to your domain.
• Do not test only on Gmail. Microsoft, Yahoo and corporate filters reach different conclusions about the same message.
• Do not paste a private DKIM key anywhere. Only the p= public portion belongs in DNS.
• Do not raise a DMARC policy because the records look correct. Raise it because the reports show every sender aligned.
• Do not check once. Keys rotate, services are added by colleagues, and migrations drop underscore-prefixed records silently.

MailPilot runs these checks for every connected mailbox's sending domain and re-runs them as you send, alongside per-provider inbox placement measured with a seed-inbox network — so you find out about a dropped DKIM record from a failing check rather than from a quarter of missing replies.