SPF authorizes sending servers for an envelope domain. DKIM signs a message using a domain’s key. DMARC connects authenticated identities to the domain readers see in From. A passing check and an aligned identity are related, but different, questions.
First, write down the three identities
These are illustrative domains. Your provider supplies the real values. A common mistake is inspecting SPF at the visible From domain when the actual envelope sender uses another domain. Another is looking for a DKIM record without knowing its selector.
| Identity | Example | Where to find it |
|---|---|---|
| Visible From domain | app.example | From: field shown to the reader |
| Envelope / return-path domain | bounce.app.example | Return-Path or provider configuration |
| DKIM signing domain and selector | d=app.example; s=mail1 | DKIM-Signature header |
SPF: check the actual envelope domain
Query TXT records at the envelope domain and identify the SPF policy. There should be one applicable SPF record at that name. Adding a second record for a new provider is not the same as extending the existing policy.
SPF evaluation has limits on DNS-dependent mechanisms. A record’s short appearance does not prove it stays within the lookup budget: includes can lead to further lookups. Do not flatten or merge records without understanding your provider’s update requirements.
dig +short TXT bounce.app.example
dig +short TXT app.exampleDKIM: use the selector from the message or provider
A signature’s s= value selects the key and d= supplies the signing domain. For s=mail1 and d=app.example, inspect mail1._domainkey.app.example. Providers may publish a TXT key directly or use a CNAME that delegates it.
A DNS key can be present while a particular message’s signature fails. The message may have been modified after signing, the wrong key may be in use, or signing may be disabled. Reading DNS alone does not cryptographically verify a message.
dig +short CNAME mail1._domainkey.app.example
dig +short TXT mail1._domainkey.app.exampleDMARC: look for alignment with the visible From
DMARC can pass when either SPF or DKIM passes with an aligned domain. Relaxed alignment typically compares organizational domains; strict alignment requires an exact match. A valid DKIM signature from an unrelated provider domain does not by itself align with your From domain.
Inspect _dmarc at the From domain. If there is no applicable record there, organizational-domain fallback may apply. An existing malformed or multiple-record policy is a configuration problem; it should not be silently replaced by a reassuring parent result.
A monitoring policy, p=none, requests no DMARC enforcement action. It is not an instruction to put messages in the inbox. Preserve an existing stronger policy while investigating; weakening it is not a general delivery fix.
dig +short TXT _dmarc.app.example
# Illustrative monitoring policy, not a prescription to replace yours:
# v=DMARC1; p=noneApply sender requirements to your actual traffic
Google distinguishes requirements for all senders to personal Gmail accounts from requirements for bulk senders. The latter include SPF, DKIM, and DMARC; marketing and subscribed messages have one-click unsubscribe requirements. Check the current sender guidelines for your traffic category instead of treating every transactional email as a marketing subscription.
Authentication is one input to receiving decisions. Recipient expectations, complaints, message formatting, transmission security, and infrastructure also matter. A green DNS check does not override those signals.
Troubleshoot in a fixed order
Use the free tools to collect evidence, not to generate a universal deliverability score. The header analyzer works locally in your browser. The DNS checker queries public records through Stampwing’s server and clearly labels missing, unavailable, and found results.
- Confirm the visible From, envelope domain, signing domain, and selector using configuration or a real controlled message.
- Query the exact record names. Account for DNS propagation and cached results; distinguish “not found” from a resolver failure.
- Compare provider-supplied expected values with what DNS actually returns. Preserve unrelated records and existing mailbox MX routes.
- Read the receiving system’s Authentication-Results. A pasted field from an unknown source is not trustworthy evidence.
- Resolve the specific issue, then recheck a newly generated controlled message. Keep the earlier evidence for comparison.
Sources and further reading
- RFC 7208: SPF
- RFC 6376: DKIM
- RFC 7489: DMARC and identifier alignment
- Google: current email sender guidelines
Written for Stampwing with AI assistance and checked against the linked documentation. Examples are educational; simulated results are labelled. How these resources are maintained.