SPF, DKIM, and DMARC: in plain English
Email authentication helps receiving services distinguish authorised use of your domain from spoofing. It also matters for deliverability, alongside reputation, message content, complaints and recipient policy. Passing authentication does not guarantee inbox placement or prove a message is harmless.
SPF: which servers may use the envelope domain?
SPF publishes authorised sending systems in DNS for the envelope sender domain used in delivery, which may differ from the From address a person sees. It is not a signature on the message and does not directly authenticate that visible From address.
Use one SPF policy per sending domain and follow each provider's current instructions. Check the DNS-lookup limit and remove obsolete senders carefully. Do not copy an example record from a blog into production: newsletter and transactional providers may use their own return-path domains and require different configuration.
DKIM: a signature tied to a signing domain
A mail service signs selected headers and the body using its private key. Receivers find the public key in DNS using the signature's selector and domain, then verify the signature. DKIM can detect changes to the signed content; it does not encrypt the email or establish that the sender's account is uncompromised.
Enable signing using your provider's instructions and verify real messages. Keep track of selectors and key rotations rather than assuming publishing a DNS record enables signing by itself.
DMARC: does authentication align with the visible From domain?
DMARC passes when at least one of these succeeds and aligns with the visible From domain under the configured alignment mode:
- SPF passes for an aligned envelope sender domain.
- DKIM passes with an aligned signing domain.
If neither path passes and aligns, DMARC fails. The published policy requests how receivers should handle that failure; receiver policy still applies. A p=none policy requests monitoring rather than rejection. p=quarantine and p=reject request stronger handling, but need a planned rollout.
Start with the actual senders
Inventory staff mail, newsletters, invoices, website forms, CRM messages and every other service that sends as your domain. Review sample headers and DMARC aggregate reports for each route. A provider using its own envelope domain may rely on aligned DKIM rather than SPF for DMARC.
Start with observation, correct legitimate senders, then agree a staged enforcement policy. Moving straight to rejection without checking all senders can block legitimate mail. Forwarding and mailing lists can affect authentication, so test those flows too.
Check messages, not just DNS
Send controlled test messages through each legitimate sending service. In Gmail, Show original exposes SPF, DKIM and DMARC results; other services provide similar headers. Inspect the domains involved, not just a PASS label. DNS tools can inspect published records, but cannot prove every sender is configured correctly or guess every DKIM selector.
Treat reports and message headers as potentially sensitive. Limit access and retention, and do not send customer messages to a public checker without permission.
Keep the controls current
Review authentication when adding or retiring a sender, changing providers or rotating keys. It is not a one-evening fix that lasts forever. Account security, recovery, forwarding rules and connected applications matter alongside DNS records.
OpsHelp can assess these controls under Web & Infrastructure Security Assurance while you keep your existing Google Workspace, Microsoft 365 or other mail provider. Managed email hosting is a separate option, not a requirement for security help.