How to Verify SPF DKIM and DMARC Are Working

You set up SPF, DKIM, and DMARC. The configuration looked correct. But is it actually working?

That is a different question than whether the records exist in DNS. Authentication can fail silently, and most administrators find out only when email starts landing in spam folders or when a domain gets flagged for spoofing.

This guide covers how to check each authentication method, what the results mean, and how to set up monitoring so you catch breakage before it becomes a deliverability problem. If you manage more than a few domains, there is also a section on continuous monitoring tools that scale better than manual checks.

The Difference Between Record Checks and Authentication Checks

A DNS lookup confirms a record exists. It says nothing about whether the authentication mechanism works when an email arrives.

Here is the distinction:

SPF check: Your DNS record lists which servers are allowed to send mail for your domain. The receiving server checks whether the sending server IP is on that list.
DKIM check: Your mail server signs outbound email with a private key. The receiving server looks up the public key in DNS and verifies the signature.
DMARC check: The receiving server verifies that SPF and DKIM results align with the visible From domain. Alignment is the part most setups get wrong.

You need all three checks, not just the DNS lookups.

How to Check SPF Is Working

Option 1: CLI dig or nslookup

Run a TXT record lookup for your sending domain:


dig txt example.com

Or:


nslookup -type=txt example.com

Look for an SPF record that lists your authorized sending servers. A basic record looks like this:


v=spf1 include:_spf.google.com ~all

The ~all means softfail. v=spf1 -all means reject. If you see -all your policy is strict.

Option 2: MXToolbox SPF Lookup

MXToolbox offers a free SPF record lookup at mxtoolbox.com. Paste your domain and it will retrieve and parse the SPF record for you.

What SPF failure looks like

When SPF fails, the receiving server either marks the email as suspicious or rejects it entirely, depending on your policy. Common failure reasons:

The sending server IP is not in your SPF record
Your record uses include: mechanisms that point to third-party systems no longer in use
You switched email providers and did not update the SPF record

If you changed your email stack recently, your SPF record is the first thing to check.

How to Check DKIM Is Working

DKIM is harder to verify with a simple lookup. The signature is attached to each individual email message, not stored in DNS as a global record. To check DKIM you need to either send a test email or examine a recent message.

Option 1: Use a DKIM validator

Send a test email to a free validator service. Mail-tester.com gives you a unique address - send a test email to it and it reports on SPF, DKIM, and DMARC in plain English.

Option 2: Use dkimpy from the command line

If you have access to your mail server's private key, you can verify it with dkimpy:


dkimpy-verify -s selector -d example.com < email_message.eml

You need the selector name and domain. The selector is usually visible in the DKIM-Signature header of any outbound email.

Option 3: Inspect the email headers of a recent message

Find an email you sent from your domain and view the full headers. Look for:


DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector;

Then look for an Authentication-Results header that shows the DKIM result. If it says pass, DKIM is working for that message.

Common DKIM failures

Selector changed or rotated without updating DNS
The private key does not match the public key published in DNS
The mail server is not applying DKIM signatures to all outbound mail
Forwarding paths that strip the DKIM signature

How to Check DMARC Is Working

Step 1: Look up the DMARC record


dig txt _dmarc.example.com

A basic DMARC record looks like:


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

This says: version DMARC1, policy is none (monitor only), send aggregate reports to this address.

Step 2: Read the policy tag

p=none: Monitor only, take no action on failures
p=quarantine: Send failing mail to spam
p=reject: Reject failing mail entirely

If you see p=none and you have not reviewed your DMARC reports, you are flying blind. The record exists but you are not getting signal from it.

Step 3: Understand DMARC alignment

DMARC checks whether SPF or DKIM results align with the visible From domain. This is the part that trips up most setups:

SPF alignment: The envelope From and the Header From must match or be on the same organizational domain
DKIM alignment: The DKIM signature domain must match the Header From domain

You can have perfect SPF and DKIM results individually, but if alignment fails, DMARC fails.

Use a tool like dmarcian DMARC record lookup to validate your record syntax and check alignment settings.

How to Verify All Three Together

The most reliable one-time check is to send a test email through an external service that reports on all three authentication methods.

Mail-tester.com (free for 3 tests per day): Send to the address it gives you and get a score with full SPF DKIM DMARC breakdown.

Glockapps (paid): Tests against multiple email providers and shows exactly where mail lands.

Google Postmaster Tools (free): If you send volume to Gmail, Google Postmaster Tools shows your authentication rates, spam rates, and domain reputation. It does not verify your setup - it shows you what Gmail sees after the fact.

The Silent Breakage Problem

The most dangerous thing about email authentication is that it can stop working without you knowing.

Real examples of silent breakage:

Cloud provider changes: You use Google Workspace and your SPF record includes include:_spf.google.com. If Google changes their sending infrastructure silently, your SPF may fail for some messages.
Key rotation failures: DKIM selectors get rotated. If the new public key is not published before the old private key is retired, every message signed with the new key fails DKIM.
DNS TTL traps: Low TTLs on your authentication records mean changes propagate quickly, but also mean your records can be overridden or overwritten more easily. High TTLs mean slow propagation but also slow recovery if something breaks.
Email forwarding: When mail is forwarded, the envelope From changes. If the forwarder does not use ARC, your SPF may fail for the forwarded copy even though the original passed.

One-time checks confirm your setup works right now. They do not catch breakage that starts an hour after you close the browser.

How to Monitor SPF DKIM DMARC Continuously

If you manage one domain and nothing changes, manual checks are enough. If you manage multiple domains or have a dynamic sending infrastructure, the gap between "I set it up" and "I know it is still working" is where deliverability problems hide.

Daily verification cadence

Set a weekly calendar reminder to run your standard checks across all domains. This is not ideal but it is better than finding out when something breaks.

DMARC report analysis

If your DMARC record includes a rua= reporting address, you receive aggregate reports that tell you what percentage of your mail is passing or failing authentication. Review these weekly. Patterns like "our CRM is sending mail from a subdomain we did not know about" show up in DMARC reports before they become deliverability problems.

Scaling across many domains

When you have ten or more domains to monitor, manual checks stop scaling. You need a tool that watches all your domains continuously and alerts you when authentication rates change unexpectedly.

This is where DMARCFlow fits. It monitors SPF DKIM and DMARC status across all your domains from a single dashboard, alerts you when authentication fails for reasons you did not expect, tracks trends in passing rates over time, and gives you actionable data from DMARC aggregate reports without requiring you to parse XML. The core problem it solves is visibility: knowing whether your authentication is working right now, not whether it worked last month.

For practitioners managing email authentication across multiple domains and third-party senders, the alternative is either accepting blind spots or spending significant time on manual verification that does not scale.

Verification Checklist

Run through this list regularly for each domain you manage:

[ ] SPF record exists in DNS (TXT lookup)
[ ] SPF record includes all your current sending sources
[ ] SPF policy is appropriate for your sending volume and risk tolerance
[ ] DKIM selector is published in DNS with a valid public key
[ ] DKIM is signing outbound mail from your primary sending domain
[ ] DKIM signature validates against the published public key
[ ] DMARC record exists at _dmarc.yourdomain.com
[ ] DMARC policy (p=) matches your operational readiness
[ ] DMARC aggregate reports (rua=) are being received and reviewed
[ ] SPF and DKIM alignment is confirmed passing for your primary From domain

If you check all ten items and everything passes, your authentication is working as designed. If you find gaps, those are your action items.

FAQ

How often should I verify email authentication?

At minimum, monthly for stable configurations. Weekly if you are making changes to your email infrastructure. Immediately after any change to DNS, email provider, or mail server configuration.

Can I just check once and be done?

No. Authentication can break at any time due to changes on your side or on the receiving server side. One-time checks are useful for initial setup validation. Ongoing monitoring is what catches breakage.

What breaks email authentication silently?

Common silent breakage causes: provider-side infrastructure changes that affect SPF, DKIM key rotation without DNS updates, DNS configuration errors that overwrite authentication records, forwarding chains that break alignment, and third-party senders that add new sending IPs without updating your SPF record.

How do I know if my SPF record is wrong?

Run a dig lookup and check whether every IP address that sends mail for your domain is listed. If you use Google Workspace, Microsoft 365, your CRM, your marketing platform, and your help desk, all of them need to be in your SPF record. Missing any of them causes authentication failures for mail sent from that system.

What does DMARC alignment failure mean?

It means SPF or DKIM passed but the domain that passed does not match the visible From address. For example, if your From address is user@example.com but the DKIM signature is from send.example.com, alignment fails and DMARC fails even though DKIM itself passed.

Is p=none useful?

p=none generates reports without taking action. It is useful during the monitoring phase before you are ready to enforce. But if you have been at p=none for more than a few weeks without reviewing your reports, you are not getting value from it. Either upgrade to quarantine or reject when ready, or start reading the reports you are already receiving.