SPF, DKIM and DMARC: records, alignment and delivery

Start with the actual message identities

The visible From address is not necessarily the SPF identity. SPF normally evaluates the SMTP envelope sender domain; DKIM uses d= as the signing domain and s= as the selector. DMARC checks alignment with the visible From domain: an aligned SPF pass or aligned DKIM pass can satisfy authentication. Use the original message headers from a mailbox you control.

Query the correct DNS names

Replace example.com and selector1 with the identities supplied by your mail provider. The three example commands assume those domains coincide; query each actual domain separately when they differ. dig requires a DNS utilities package. Without a selector, our tool does not try to discover DKIM records.

dig +short TXT example.com
dig +short TXT selector1._domainkey.example.com
dig +short TXT _dmarc.example.com

Read findings within the checker’s limits

check.uk.app inspects only the submitted hostname. It does not expand SPF include chains, apply parent-domain DMARC inheritance, verify message signatures or test alignment. A missing _dmarc record at a subdomain therefore does not prove that no DMARC policy applies.

Multiple SPF records beginning v=spf1 at one name are a configuration error; unrelated TXT records are allowed. Several quoted strings inside one TXT record are not several SPF records. For DKIM, an empty p= revokes the key; a published key alone does not prove outgoing messages are correctly signed.

Change records using provider evidence

Inventory every legitimate sender before editing SPF. Maintain one SPF record at each evaluated domain and account for the standard’s DNS lookup limit. Publish the DKIM record exactly as issued for the selector; do not replace keys in active use blindly.

Begin DMARC changes with monitoring and analysis of legitimate sending sources. p=none requests no DMARC quarantine or rejection; it does not promise inbox placement. Configure a mailbox you control for reports and confirm any required external-report authorization. Move to stricter policy only after checking alignment.

Investigate delivery beyond DNS

For a missing registration email, locate the application event, queue entry and SMTP response at the same timestamp. An SMTP acceptance is not proof of inbox delivery. Inspect bounces, recipient spam folders and the receiving provider’s trusted Authentication-Results. Do not trust arbitrary authentication headers inserted by a sender.

Save original DNS values and TTLs before editing. After publication, check authoritative and recursive answers and send a controlled message to your own mailbox. Compare authentication results before and after; cache expiry can delay changes. Restore the saved records if legitimate senders fail. check.uk.app sends no email during this test.