Business email may come from several places: mailboxes, the website, invoicing software and a newsletter platform. If domain authentication covers only one, other legitimate messages can have problems. SPF, DKIM and DMARC work together, but none guarantees that every message reaches the inbox. Content, reputation and recipient preferences still matter.
Inventory all senders
List every service sending on behalf of the domain. Include forms, password resets, invoices and older systems used only occasionally. Identify the From address and the technical sending domain for each. Do not change DNS using a generic example alone: correct values must come from your account and each provider’s documentation.
What SPF does
SPF declares which systems may send for the domain checked during delivery. It does not simply authenticate the displayed sender name. Publish one coherent configuration; multiple separate SPF records for the same domain can cause errors. Evaluation also has DNS lookup limits. Have the combined configuration validated rather than adding provider includes indefinitely.
What DKIM adds
DKIM signs a message using a provider-controlled key. Recipients verify the signature using the public key in DNS. Selectors allow multiple services and key rotation. Copy the supplied values accurately and wait for the provider’s verification. Never publish a private key. A valid signature helps, but the signed identity must also be evaluated against the visible domain.
What DMARC decides
DMARC uses SPF and DKIM results and their alignment with the domain in From. Monitoring can help identify legitimate senders before a stricter policy is introduced. Moving directly to rejection without an inventory can block your own messages. Reports need a managed destination and someone to interpret them; publishing the record is not the end of the work.
Verify actual sending paths
Use synthetic messages to authorised addresses and inspect authentication results at the recipient. Test invoices, forms and password resets separately. For website forms, use your own domain as the sender and place the visitor’s address in Reply-To, as supported by the application. Do not make your server pretend it sends on behalf of the visitor’s personal email domain.
Sources and further reading
A CloudCity editorial guide informed by the documentation below. Check the official source for rules and procedures that may change.
