SPF, DKIM and DMARC help receiving systems assess whether a message uses an authorised domain identity. They address related but different parts of email authentication. A green authentication result does not guarantee inbox placement or establish that the message itself is trustworthy.
This guide explains the identities, records and evidence to review with your technical owner. Use the values supplied for your actual account and sending service rather than copying another organisation's configuration.
Inventory every legitimate sender
List staff mailboxes, website forms, booking tools, billing systems and campaign platforms. Record the visible From address, sending service and responsible owner. Include subdomains and infrequently used applications that might be missed in a short observation period.
Distinguish verifying ownership of a domain in a platform from authenticating outgoing mail. A verification step may permit configuration without establishing the required sending records. Test an actual message from each route.
Understand SPF and its configuration limits
SPF describes authorised sending sources for the relevant domain identity. It is published using DNS TXT records. Multiple applicable SPF records for one domain cause an invalid arrangement; adding a second record for a new service is not a safe way to combine requirements.
Have the technical owner maintain one valid configuration and assess its evaluation limits. Review the actual envelope identity and any forwarding behaviour. The domain checked by SPF is not necessarily the domain a customer sees in the From address.
Understand DKIM signatures and selectors
DKIM uses a cryptographic signature associated with a signing domain. The receiving system looks up the appropriate public verification information using the selector. Providers may supply TXT records or aliases to managed verification information.
Use the account's exact values and supported rotation procedure. When signing changes to a new key, previously signed messages may still need the old public key for verification. Plan an appropriate overlap instead of removing its record immediately without review.
Check DMARC alignment
DMARC connects authentication with the domain in the visible From address. A pass needs a passing SPF or DKIM route with the required alignment. A passing result for an unrelated domain does not satisfy that relationship.
Strict alignment requires identical domains; relaxed alignment uses the relevant organisational-domain relationship. Review the configured mode and observed identities. A subdomain should not be assumed to behave identically under every policy.
Document policy and receiver behaviour
A DMARC policy can request monitoring, quarantine or rejection treatment for failing messages. Receivers still make their own handling decisions. Record the existing policy, scope and reporting destinations before a migration or supplier handover.
Investigate legitimate failing senders before changing enforcement. Do not weaken an established policy merely to silence a warning. Assign changes to the responsible technical owner, with testing and a clear record of the reason.
Use reports as scoped evidence
Aggregate reports group observations from participating receiving systems over a period. Connect sources and authentication results with the sending inventory. A summary does not necessarily identify the business owner of every source without further investigation.
Reporting tools can cover particular recipients or lack data at low volume. A blank dashboard is not proof that the whole email operation has no problems. Compare reports with test-message headers and the providers' available delivery evidence.
Check recipient requirements and delivery separately
Receiving services can impose additional sender requirements, including different expectations for bulk activity. Check the current rules applicable to your destinations and volume. Authentication is one part of an operating plan that also covers complaints, message quality and subscription handling.
SPF, DKIM and DMARC protect use of your own domain identity. They do not give you control over another registered domain or eliminate misleading display names. Staff should continue checking the actual address and context of unexpected messages.
Keep an authentication handover record
- List each sender, identity, owner and business purpose.
- Record account-specific DNS instructions and accepted settings.
- Check SPF validity, DKIM signing and DMARC alignment.
- Preserve dated headers and relevant report observations.
- Plan key rotation and removal of retired services.
- Recheck after adding a sender or changing mail routing.
Our DNS guide explains the record-management context. Giraffe Hosting can support the hosting and domain side of the arrangement alongside your email technical owner.
