How to Check SPF DKIM and DMARC for Any Domain

Introduction

Before you trust a domain's email setup, you need to answer three questions: Can this domain say who sent this email (SPF)? Does the email actually come from the domain it claims (DKIM)? And does that domain explicitly allow the sending server (DMARC)? If any of these fail, your email lands in spam or gets rejected outright.

This guide shows you how to check all three for any domain, using free command-line tools and a few web checkers. MSPs managing multiple clients often use DMARCFlow for continuous monitoring across all domains, but the commands below work for any single-domain check.

SPF vs DKIM vs DMARC in 30 Seconds

SPF (Sender Policy Framework) tells receiving mail servers which IP addresses are allowed to send email for your domain. You publish an SPF record in DNS. If a server sends mail from an IP not listed in that record, it is an SPF failure.

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outgoing email. The receiving server verifies it against a public key published in DNS. If the signature does not verify, something was modified in transit or the signer is not authorized.

DMARC (Domain-based Message Authentication, Reporting and Conformance) sits on top of SPF and DKIM. It tells receivers what to do when either check fails and where to send reports about authentication results. A domain with DMARC but no SPF or DKIM is not protected.

You need all three working together for reliable email authentication.

How to Check SPF Records

Open a terminal and run:


dig TXT +short example.com

Replace example.com with the domain you are checking. The SPF record is a TXT record at the apex.

A basic valid SPF record looks like this:


v=spf1 ip4:203.0.113.50 ~all

This says: only the IP 203.0.113.50 is authorized to send mail for this domain, and everything else should be treated as a softfail (~all).

Common mistakes to watch for:

Too many DNS lookups. SPF records that include too many include mechanisms can exceed the 10 DNS lookup limit and return PermError, which receivers treat as a failure. An SPF record that chains through multiple third-party services is a red flag.

~all vs -all. The tilde (~) means softfail: receivers may accept the mail but mark it suspicious. The minus (-) means hard fail: receivers should reject mail that does not pass. If you are troubleshooting deliverability, check whether the record uses ~all and whether that is intentional.

Multiple TXT records. Some domains accidentally publish two SPF records. Receivers may pick the first one, ignore the second, or treat the conflict as an error. Your dig command will show all TXT records if there is more than one.

How to Check DKIM Records

DKIM uses selector-based discovery. The selector is a string published by the sending domain, and it is included in the DKIM-Signature header of every signed email. To look up a DKIM public key, you need to know the selector.

For a generic check when you do not know the selector, try the default:


dig TXT selector._domainkey.example.com +short

Replace selector with whatever selector name the sending domain publishes. Common selector names include "google", "dkim", "mail", or a random string.

A valid DKIM record looks like this:


v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC5GhX3Q2Vw8x [...]

The record contains a public key that receivers use to verify DKIM signatures. If the record returns empty, the domain is not publishing that DKIM selector.

The DKIM selector is not standardized, so if you are checking a domain for a client and the default selector returns nothing, ask the client which selector they use. Many large providers like Google Workspace and Microsoft 365 use their own selector names.

If the domain uses a third-party email sender (Mailgun, SendGrid, Amazon SES), the selector for that service is usually documented in their setup instructions.

How to Check DMARC Records

Run:


dig TXT _dmarc.example.com +short

Replace example.com with the domain. The DMARC record lives at _dmarc.example.com (note the underscore prefix).

A basic DMARC record with monitoring only:


v=DMARC1; p=none; rua=mailto:reports@example.com

This says: use DMARC version 1, apply no policy (p=none), and send aggregate reports to the specified email address.

The key components:

p= (policy) tells receivers what to do with mail that fails SPF or DKIM. p=none means do nothing, just monitor. p=quarantine means treat failing mail as suspicious. p=reject means refuse the mail entirely.

rua (Reporting URI for Aggregate) is where receivers send XML aggregate reports summarizing authentication results. These reports do not contain message content, just metadata about pass and fail rates. Without an rua address, you are flying blind.

ruf (Reporting URI for Forensic) sends per-message failure reports. These contain more detail but can be noisy and are less commonly configured.

What if _dmarc.example.com returns NXDOMAIN? That means the domain has no DMARC record at all. SPF and DKIM may still work, but there is no policy telling receivers what to do with them.

Online Tools for Quick Checks

If you prefer a web interface over the command line, two tools cover most basic checks:

Google Admin Toolbox (dns.google.com) - Enter a domain and query TXT records for SPF and DMARC. The interface shows results clearly and resolves DNS through Google's infrastructure. One caveat: Google DNS may return different results than the domain's actual authoritative nameservers if there is a propagation delay or if the domain uses a DNS provider that is not fully synced.

MXToolbox (mxtoolbox.com) - Enter a domain and get SPF, DKIM, and DMARC records in a single view. MXToolbox also flags common configuration problems like duplicate SPF records or missing DMARC policies. It is faster than chaining dig commands but does not replace them when you need to see the raw record.

Both tools are useful for one-off checks. They do not alert you when something changes. For ongoing monitoring across multiple client domains, you need something else.

What to Do When Something Is Wrong

SPF softfail (~all) but mail is going to spam. Check whether the sending IP is actually in the SPF record. If it is not, either add it or route mail through the correct IP. If it is in the record but still softfailing, the receiving server may be applying additional heuristics.

DKIM fail. The email was modified in transit or signed by a server not authorized for this selector. Ask the sender to check their DKIM signing configuration. If the email passed through a mailing list or forwarder, DKIM may break at that hop - this is a known limitation of DKIM with email forwarding.

DMARC fail. This means either SPF or DKIM failed and DMARC caught it. Check the DMARC policy: if it is p=quarantine or p=reject, you may be seeing the effect of a domain's enforcement policy rather than the cause of the problem. Ask the sending domain for their DMARC report ( rua) to see exactly what is failing.

No DMARC record at all. The domain has no protection. This is common for small businesses and domains that have never been through an email security audit. SPF may exist alone, which is better than nothing but leaves DKIM and DMARC enforcement out of the picture.

Ongoing Monitoring with DMARCFlow

If you manage one domain, dig commands and MXToolbox are sufficient. If you manage ten or fifty, the same manual checks become a full-time job.

DMARCFlow monitors SPF, DKIM, and DMARC across all your client domains from a single dashboard. It flags new authentication failures, catches configuration drift, and sends alerts when a client's email setup changes. For MSPs, that is the difference between catching problems during an incident and catching them before your client calls you.

The manual checks in this guide tell you what is wrong today. DMARCFlow tells you when it changes.

FAQ

What is the difference between SPF softfail and hard fail?

Softfail (~all) tells receivers to treat mail from unauthorized IPs as suspicious but not reject it outright. Hard fail (-all) tells receivers to reject it. Many domains start with softfail while they test their setup and move to hard fail once they are confident everything is configured correctly.

Can I check SPF DKIM and DMARC for free?

Yes. The dig command works on Linux, macOS, and Windows Subsystem for Linux. It is free. Online tools like Google Admin Toolbox and MXToolbox are also free for basic lookups. Paid tools add monitoring, alerting, and multi-domain management.

Why does dig return nothing for a DKIM record?

Most likely you are using the wrong selector name. DKIM uses selector._domainkey.domain.com, and the selector part is not standardized. Ask the domain owner which selector they use, or check the DKIM-Signature header in an actual email from that domain - the s= tag shows the selector.

My domain has SPF and DKIM but no DMARC. Is that enough?

SPF and DKIM work without DMARC, but without DMARC you have no policy telling receivers what to do when authentication fails. You also get no aggregate reports. DMARC is the layer that makes SPF and DKIM actionable. Without it, you are hoping receivers interpret your records the way you intend.

What does it mean if _dmarc.example.com returns NXDOMAIN?

The domain has not published a DMARC record. SPF and DKIM may still function, but no DMARC policy exists. This is the same as having no DMARC record at all.