An email domain can publish plausible SPF, DKIM and DMARC records while its real messages still fail authentication. The missing evidence is often the message itself. A useful audit follows one delivered message from its sending service through the envelope sender, DKIM signature and visible From address.
Start with a message you control, sent through a representative production workflow to a mailbox where you can inspect the original headers. Repeat for newsletters, support mail, invoices and account recovery. Those streams may use different providers even when recipients see the same brand.
Write down the three identities
The visible From header is the address people normally see in their mail client. The SMTP envelope sender is used during transport and commonly appears in the delivered Return-Path. DKIM identifies a signing domain through the d parameter and a selector through s. These identities can differ legitimately.
SPF evaluates an authorised sending host against an SMTP identity, usually the envelope sender domain. DKIM verifies a signature over selected message content with a key published under the signing domain. DMARC evaluates whether a passing SPF or DKIM result aligns with the visible From domain.
The email domain audit inspects published DNS configuration. It cannot infer every provider your organisation uses or verify a message it has not received. Use it alongside delivered headers, not as a substitute for them.
Use the receiving system's authentication evidence
Open the original message source and locate Authentication-Results added by your receiving service. Preserve the result names, evaluated domains and explanatory text. A message can contain headers inserted earlier in the path, so know which header belongs to the receiver you trust for this test.
Do not rely on a sender-supplied claim that SPF or DKIM passed. Headers are text and can be added by a sender. Receiving systems use their own trust boundaries when deciding which authentication results to accept. In a manual audit, attribute each result to the system that evaluated it.
Keep the unmodified test message privately if you need signature verification later. Redacting or reformatting it can alter signed bytes. For a shared report, extract the minimum needed fields and remove addresses, message identifiers and body content that are not relevant.
| Field | Where to find it | Why it matters |
|---|---|---|
| Visible From domain | From header | DMARC alignment target |
| Envelope sender domain | Transport evidence or delivered Return-Path | SPF identity and alignment |
| DKIM signing domain | d in DKIM-Signature | Signature key lookup and alignment |
| DKIM selector | s in DKIM-Signature | Exact DNS key name |
| Receiver result | Trusted Authentication-Results | Observed evaluation for this delivery |
Work through a provider-domain mismatch
Suppose the visible From is billing@example.com, the envelope sender uses bounce.provider.example and DKIM signs with d=provider.example. SPF and DKIM can both pass for the provider's identities. They still may not align with example.com for DMARC.
The fix is not necessarily adding the provider to example.com's SPF record. SPF is being evaluated against the envelope domain actually used. Configure a supported custom return-path domain or aligned DKIM signing according to the provider's instructions, then send a fresh message and inspect the result.
One aligned passing mechanism can satisfy DMARC. Many deployments prefer aligned DKIM as a durable path because ordinary forwarding can change the IP that SPF evaluates. Still audit both mechanisms and document which path each message stream relies on.
Repeat the example for transactional and marketing providers separately. A correct setting in one account does not configure another provider. Keep an inventory with owner, From domain, envelope domain, signing domain, selector and current authentication result.
Review SPF where the message actually uses it
Query the envelope sender domain's TXT records and identify its SPF policy. Check authorised sources, include relationships and lookup limits. Several separate SPF policies at the same name are not a valid way to combine providers; the policy must be constructed coherently within the protocol's limits.
Use the SPF policy analyzer to review text, then inspect dependent DNS records as needed. A pasted-policy parser cannot know the complete live include tree or the outcome for every sending IP. Preserve that distinction in the audit.
Check unusual flows such as forwarding and null reverse-path messages separately. SPF's evaluated identity and the path taken can differ from an ordinary direct delivery. Avoid changing the main policy based on one forwarded sample without understanding how the message reached the receiver.
Locate the key from a real signature
Read the selector from the message rather than guessing common names. The key lookup name combines the selector, _domainkey and signing domain. A DNS record under selector1 is irrelevant to a message signed with a different selector unless the provider's configuration actually uses it.
A published key proves that DNS contains key material at that name. It does not prove that the signature on the message verifies. Verification also depends on signed headers, body canonicalisation and whether the content changed after signing.
If a mailing list or gateway modifies a subject or footer, examine the resulting signature failure. The original direct message and the transformed message are distinct test cases. Keep the exact path in the record so a content modification is not mistaken for a missing key.
Use reports to find streams you did not inventory
DMARC aggregate reports can reveal sources using your From domain and their reported authentication outcomes. Use them to compare observed traffic with the provider inventory. A new source may be legitimate forgotten infrastructure, spoofed traffic or a reporting interpretation issue.
Assign an owner before authorising a source. Adding every reported IP to SPF can legitimise traffic that should remain unauthorised and can exhaust lookup limits. Validate the business workflow, configure aligned authentication and send a controlled test message.
Move toward enforcement in stages with representative mail flows covered. Monitor failures after each policy change. A single successful message from the main mailbox does not establish that account recovery, invoices and support replies will survive a stricter policy.
Keep authentication separate from inbox placement
Passing authentication does not guarantee delivery to the inbox. Receiving services consider reputation, content, recipient behaviour and other policies. Conversely, a message arriving in the inbox does not prove every authentication mechanism passed.
For a delivery incident, record SMTP rejection text or mailbox placement separately from authentication results. A provider can accept a message and later classify it as spam. DNS changes aimed at SPF will not necessarily fix content or reputation problems.
Use the audit to establish a dependable identity foundation, then investigate remaining delivery evidence. Avoid promising that a perfect-looking DNS dashboard will make every recipient accept every message. The receiving system retains its own policy decisions.
Keep an audit that can be repeated
For each sending stream, retain a dated result, the responsible team and the configuration location. Include selector rotation and provider retirement in the maintenance process. An old provider can remain authorised long after the team stops using it unless someone owns the cleanup.
Schedule a new test after changing From domains, return-path settings, signing keys or email gateways. Preserve the expected alignment path in plain language, such as DMARC passes through aligned DKIM for this newsletter service. That makes later failures easier to interpret.
Frequently asked questions
Can SPF pass while DMARC fails?
Yes. SPF can pass for an envelope sender domain that does not align with the visible From domain. DMARC requires an aligned passing SPF or DKIM path. Inspect the evaluated domains, not just the word pass beside each mechanism.
Does a DKIM DNS key prove my mail is signed?
No. The provider must actually sign outgoing messages with the corresponding private key and selector. Inspect a delivered message for DKIM-Signature and the receiver's verification result. An unused public key record can remain in DNS without affecting any current mail.
Why does forwarding change the result?
The receiver may see the forwarder's IP for SPF, while DKIM can survive if signed content remains intact. Forwarders and mailing lists can also transform messages. Test the actual path and distinguish transport changes from content changes before modifying domain policy.
Should every employee mailbox have its own SPF record?
SPF is published for the domain identity evaluated in SMTP, not separately for each local mailbox name. Different subdomains can have separate policies where the architecture uses them. Base the record layout on actual envelope identities and provider requirements.
Will DMARC reject stop all phishing?
It can help receivers handle unauthenticated use of the protected From domain, subject to their policies. It does not prevent lookalike domains, display-name impersonation or compromised legitimate accounts. Keep those threats separate from the domain-authentication problem being audited.
Which message should I use for testing?
Use a controlled message sent through the real workflow with synthetic content. Include each distinct provider and important routing path. A message sent manually from a mailbox may not exercise the invoice or password-reset service that users depend on.
What should I share with a provider?
Share the sending stream, time, relevant domains, selector and trusted receiver results, plus the provider's message identifier if needed. Remove unrelated personal content. Keep the original message available privately when the provider needs to investigate exact signature bytes.