How to Actually Check SPF, DKIM, and DMARC for Client Domains: A Practical Workflow

If you manage email for client domains, you know the situation: SPF, DKIM, and DMARC are all set up, the DNS records look right, and then a client reports mail landing in spam. The records exist. The problem is the workflow that nobody taught you.

Here is how practitioners actually check SPF, DKIM, and DMARC for client domains, including the checks that catch problems before they cause delivery failures.

Why Standard DNS Checks Are Not Enough

Running dig or nslookup tells you whether a record exists. It does not tell you whether the record is correct, whether the pieces work together, or whether the sending infrastructure is actually using them.

Three false confidence patterns show up repeatedly:

SPF pass at the SMTP level does not mean your From domain is protected. A message passes SPF because the sending server's IP is in the SPF record, but if the RFC 5321 From domain does not match the return path domain, DMARC fails alignment. Most people never check this.

DKIM signature verifying does not mean the signature is aligned. The DKIM signature can be cryptographically valid and DMARC can still fail if the d= domain in the signature does not match the RFC 5321 From domain.

DMARC record existing does not mean the policy is doing anything. A p=none policy means you are monitoring but enforcing nothing. Without reading the aggregate reports, you do not know what is actually passing and failing.

The three records interact in ways that individual DNS lookups cannot show. A checklist is what makes the difference.

The Three Things That Actually Matter

SPF check: The sending server's IP must be listed in the SPF record published at the return path domain (the RFC 5321 MAIL FROM, not the From header).

DKIM signature: The message must carry a valid DKIM signature from a domain that aligns with the From header. The d= domain in the signature must match the From domain.

DMARC alignment: At least one of SPF or DKIM must align with the From domain. If neither SPF nor DKIM aligns, DMARC fails regardless of whether individual checks pass.

You can have perfect SPF and DKIM records and still fail DMARC if nothing aligns. That distinction between authentication passing and alignment passing is where most guides fall short.

A Practical Step-by-Step Checklist

Work through these steps for any new client domain:

Step 1: Check the SPF record

Run:

dig -t TXT yourdomain.com

Look for:

• More than 10 DNS lookups (the SPF limit, and it is easy to hit)


• ~all instead of -all at the end (softfail is not enforcement)


• IP addresses that look wrong or outdated

Step 2: Check DKIM selectors

Run:

dig -t TXT default._domainkey.yourdomain.com

Try common selector names if you do not know the client's: default, google, microsoft, mailchimp, sendgrid. If you manage the sending infrastructure you already know your selector. If you do not, ask the client or the vendor.

Step 3: Check the DMARC record

Run:

dig -t TXT _dmarc.yourdomain.com

Read the p= value. p=none is monitoring only. p=quarantine sends suspicious mail to spam. p=reject refuses it. Also check the rua and ruf tags: do they point somewhere the client actually monitors?

Step 4: Check alignment, not just existence

This is the step most tutorials skip. Alignment is not visible in DNS lookups. To check alignment you need either a real test message with full authentication headers, or a DMARC checker tool that simulates the evaluation.

A message can pass SPF at the SMTP level and fail DMARC because the return path domain does not match the From domain. This happens constantly with forwarding, third-party senders, and shared hosting.

Step 5: Send a real test message

Send a message from the client's infrastructure to a test address that displays authentication headers, or use a DMARC checker that queries multiple receivers. The received headers show you exactly what each receiver sees.

The Alignment Check Most Tutorials Skip

SPF alignment and DKIM alignment are separate requirements.

SPF alignment: The return path domain (MAIL FROM) must share an organizational domain with the From domain. If you send from user@examplesender.com but the SPF record is at sender-example.com and those are different organizational domains, SPF alignment fails.

DKIM alignment: The d= domain in the DKIM signature must match the From domain exactly. If the From header says example.com but the signature is from email.example.com, alignment fails.

This is why a valid DKIM signature can exist and DMARC can still fail. The signature is real, it verified, but the domains did not align.

When authentication passes but DMARC fails, alignment is the cause. Check whether the From domain matches the return path domain for SPF and the d= domain for DKIM.

What to Verify Before a Domain Goes Live

Do these before any new domain starts sending:

Send a test message and check the authentication headers. Confirm SPF, DKIM, and DMARC all show pass and aligned.

Check that the DMARC policy matches the sending infrastructure. If the client uses a third-party marketing platform, make sure it is included in SPF or DKIM signed before you set p=quarantine.

Verify all known sending IPs are covered. Organizations consistently discover after going live that they had additional sending sources they forgot: legacy mail servers, SaaS tools, mobile sync servers.

Confirm DKIM selectors are consistent. If the selector rotates or changes, a previously aligned message may suddenly fail alignment. Watch for typos in selector names. default._domainkey is not the same as defaults._domainkey.

How to Monitor Without Running Commands Every Day

Manual checks do not scale. Managing ten or fifty domains requires monitoring, not just one-off checks.

DMARC aggregate reports are the primary monitoring signal. They show what receivers are actually seeing: which sources pass authentication, which fail, and which are aligned. Without aggregate reports, you are guessing.

What to look for in weekly reports:

New failure sources that were not there last week. An unknown IP range suddenly failing SPF often means an undocumented sending source got added.

DKIM pass rates changing. A drop from 98 percent to 70 percent means something changed in the infrastructure or in how receivers handle your signatures.

Domains in your reports that you do not recognize. This can indicate spoofing attempts or forgotten sending sources.

Common Failure Patterns DNS Checks Miss

Some DMARC problems are invisible without aggregate reports or real test messages:

Third-party senders not in SPF. A client starts using a new transactional email vendor. The SPF record does not include the vendor's sending infrastructure. A percentage of mail starts failing DMARC.

Marketing platforms that DKIM sign from a different subdomain. The From header says example.com but the DKIM signature is from email.example.com. This fails alignment even though the signature is valid.

Shared hosting where SPF is already at the 10-lookup limit. Adding one more include mechanism breaks SPF resolution for some receivers.

Forwarding chains that break DKIM integrity. When a message is forwarded, the original DKIM signature may fail because the message was modified in transit.

Subdomains inheriting p=none from the root domain unintentionally. An actively sending subdomain without its own DMARC record inherits the root domain's policy. If you are moving to enforcement, make sure all sending subdomains have explicit policies.

How DMARCFlow Helps You Monitor Multiple Domains

DMARCFlow aggregates DMARC reports across all client domains into one dashboard. Instead of running dig for each domain and guessing what the aggregate data means, you see which domains are passing, which are failing, and why.

The alignment failures that are invisible to DNS lookups show up clearly in DMARCFlow. You can see which domains are passing SPF but failing alignment, or which DKIM selectors are not signing correctly, without sending manual test messages.

Weekly digest reports surface new failure patterns before they become delivery emergencies. If a client's mail starts landing in spam because of an authentication problem, you find out before they call you.

The practical difference between checking and monitoring is this: checking confirms a domain is set up correctly today. Monitoring confirms it stays correct over time.

FAQ

How often should I check SPF, DKIM, and DMARC for client domains?

Run a full manual check when you add a new sending source, change mail infrastructure, or move to a stronger DMARC policy. Monitor aggregate reports continuously and review them at least weekly. Problems that go unnoticed in reports tend to show up as delivery failures weeks later.

What is the difference between SPF authentication and SPF alignment?

SPF authentication checks whether the sending server's IP is in the domain's SPF record. SPF alignment checks whether the return path domain matches the From domain. A message can pass SPF authentication but fail SPF alignment, and DMARC requires at least one aligned method.

Can SPF pass but DMARC still fail?

Yes. SPF can pass at the SMTP level while DMARC fails if the return path domain does not align with the From domain. This is one of the most common DMARC failure modes and it is invisible without checking alignment specifically.

How do I check DKIM if I do not control the sending server?

Use the DKIM selector lookup (dig -t TXT selector._domainkey.yourdomain.com) to confirm the record exists. To check whether DKIM is actually signing correctly, send a real test message and read the authentication headers, or use a DMARC checker tool that queries multiple receivers simultaneously.

What is the single most important check most people skip?

Alignment. Specifically, whether the From domain matches the return path domain for SPF and the d= domain for DKIM. Individual record checks confirm the pieces exist. Alignment checks confirm they work together. Without alignment, DMARC enforcement is not doing anything.