How Do I Check Whether SPF, DKIM and DMARC Are Actually Working?
Do not stop at checking DNS records. Verify SPF, DKIM and DMARC against a real message, confirm DMARC alignment, inspect the DKIM selector and signing domain, and make sure every legitimate sender is covered.
DSDillon Intelligence
Direct answer
To check SPF, DKIM and DMARC properly, verify both the public DNS configuration and a real message sent through each production sending path. SPF should pass for the actual envelope sender and sending IP, DKIM should produce a valid signature whose public key resolves through the selector, and DMARC should pass because at least one authenticated domain aligns with the visible From domain. A DNS record existing by itself is not proof that production email is working.
DSDillon reviews the actual sending path, headers, SPF authorization, DKIM selector and DMARC alignment before recommending changes.
Review email authenticationWhat does a proper SPF check actually prove?
SPF tells a receiving server whether the sending host is authorized to use a domain for the SMTP identity being evaluated. RFC 7208 specifies that SPF is published in DNS as a TXT record and that multiple SPF records for the same owner name are not permitted. A superficial lookup can show you the record, but the real test is whether the sending IP follows the mechanisms and produces the expected result for the domain used in the message's SMTP transaction.
If your business sends through more than one system, map each legitimate sender before editing the record. Employee mail, a website server, a CRM, an invoicing system and a marketing platform may all use different delivery infrastructure. Removing one include or IP can fix one path and break another.
What should you verify in an SPF record?
Confirm there is one applicable SPF record, that it begins with v=spf1, that the authorized senders are intentional, and that the final policy matches your design. Also watch DNS lookup complexity. RFC 7208 limits the number of mechanisms and modifiers that trigger DNS lookups during SPF evaluation, so an SPF record can look reasonable but still produce a permanent error when it expands through too many includes.
Do not flatten or rewrite SPF blindly. The right record is the smallest maintainable representation of the infrastructure that is genuinely allowed to send.
- Identify the envelope sender or Return-Path domain used by the real message.
- Identify the actual sending IP.
- Evaluate that IP against the SPF record used for the message.
- Check for multiple SPF records, syntax errors and excessive DNS lookups.
How do you verify DKIM on a real email?
Open the full message headers and find the DKIM-Signature field. The d= value identifies the signing domain and the s= value identifies the selector. RFC 6376 defines the DNS lookup as selector._domainkey.signing-domain. The receiver retrieves that public key and uses it to verify that the signed parts of the message have not been altered in a way that invalidates the signature.
Then inspect the Authentication-Results header produced by the receiver. A DKIM record in DNS means little if the sender never added a DKIM signature, if the selector points to the wrong key, if the signature breaks in transit, or if the signing domain is not the one you expected.
How do you check DMARC instead of merely checking the DMARC record?
DMARC is evaluated against the visible From domain. It passes when SPF or DKIM passes and the authenticated domain aligns with the From domain under the domain owner's alignment policy. That is why DMARC can fail even when SPF or DKIM shows a pass somewhere in the headers.
Inspect the Authentication-Results line for dmarc=pass or dmarc=fail, then compare the From domain with the SPF-authenticated domain and the DKIM d= domain. If the result is a fail, determine whether the underlying authentication failed or whether authentication passed for a domain that did not align.
How can you find the DKIM selector without guessing?
The most direct method is to inspect a message that was actually sent through the system you are testing. In the DKIM-Signature header, the s= tag is the selector and the d= tag is the signing domain. You can then query s._domainkey.d in DNS. Google Workspace documentation gives the same basic method for non-Google sending systems and recommends checking a real message when you need to find the selector.
Do not assume selectors such as default, google or selector1. Providers choose different values, organizations can customize them, and multiple selectors can exist during rotation.
What if SPF, DKIM and DMARC all pass but mail still goes to spam?
That moves the investigation from identity validation toward deliverability. Review domain and IP reputation, complaint rates, list accuracy, rate limiting, sending history, PTR and forward DNS, TLS, content patterns and receiver-specific error dashboards. Google explicitly treats authentication as part of a larger sender requirement set rather than a guarantee of inbox placement.
Test across more than one mailbox provider. A sender can be healthy at one provider and filtered at another because reputation and recipient behavior are provider-specific.
How should a business test multiple sending systems?
Create a sender inventory and test each production path independently. The employee mailbox, website contact form, transactional application, CRM and campaign sender should each produce a traceable message. Record the sending IP, Return-Path, SPF result, DKIM d= and s= values, DMARC result and visible From domain for each path.
This avoids a common false conclusion: one successful test from a staff mailbox is treated as proof that every system using the domain is authenticated. It is not.
What should you fix first when a test fails?
Fix the smallest proven failure first. If DKIM is missing only from one application, repair that application rather than replacing the domain's working authentication. If SPF fails because a legitimate sender is absent, update the authorized path without creating a second SPF record. If DMARC fails because of alignment, determine which authenticated identity should align before changing policy.
After every change, send a fresh message and verify the receiver's results again. DNS propagation, cached records and intermediary modifications can make assumptions unreliable.
When should authentication be professionally reviewed?
A review is valuable before a major migration, when several third-party or self-hosted systems send as the same domain, when DMARC enforcement is being tightened, or when business-critical delivery has become inconsistent. It is also sensible when a change to SPF or DKIM could interrupt payroll, invoicing, customer support or other production mail.
The deliverable should be an evidence map of every sending source and its actual authentication behavior, not simply a screenshot of three green DNS checks.
Sources and verification
These references support the factual claims used in this guide. DSDillon separates published source material from observations that require investigation of an individual business.
Related DSDillon resources
Continue this investigation
DSDillon Email Deliverability & Authentication Remediation is designed for businesses that need production-safe diagnosis and repair across SPF, DKIM, DMARC, DNS and sending infrastructure.
View remediation pricing