SPF, DKIM and DMARC for business email
A customer receives a message that appears to come from your business and asks for payment to a new account. The visible sender address alone is not proof that you sent it. Email authentication helps receiving systems distinguish authorised domain use from certain forms of forgery.
SPF, DKIM and DMARC work together, but none is a complete defence against fraud. Their value is strongest when you understand every legitimate sending service, configure it correctly and review the results.
SPF: authorise sending systems
SPF publishes a policy in DNS for the domain used in the SMTP envelope sender, also called the return-path domain. A receiver checks whether the connecting sending system is authorised by that policy. It is not simply a check of the address a person sees in their inbox.
Maintain one SPF record for each relevant domain. If several services send mail, combine their authorised mechanisms correctly. Publishing multiple competing SPF records can cause an error. SPF also has DNS-lookup limits that complex chains of includes can exceed. RFC 7208 defines these rules.
Use your providers' current values, not a generic example copied from a guide. Forwarding can change the connecting server, which is one reason SPF alone is not sufficient for every delivery route.
DKIM: sign the message
DKIM adds a cryptographic signature associated with a signing domain. The receiver uses published key information to verify the signed content. The signing domain is identified by the signature, and a selector tells the receiver which key information to retrieve.
Enable signing at the sending service and publish the exact TXT or CNAME records it supplies. DNS publication alone does not turn signing on. Different legitimate services can use different selectors.
A valid signature shows that the signed material verifies under that domain's key; it does not prove the content is honest or that an individual employee approved it. RFC 6376 describes the underlying mechanism.
DMARC: connect authentication to the visible sender
DMARC evaluates whether a successful SPF or DKIM result aligns with the domain in the visible From address. A message can pass DMARC through an aligned passing result from either mechanism. A passing result for an unrelated domain is not enough.
The domain owner can publish a policy requesting no specific enforcement, quarantine or rejection of failures. Receivers retain their own handling decisions. DMARC does not grant authenticated messages a guarantee of inbox delivery. See the current DMARC specification, RFC 9989.
Inventory senders before enforcing
List every system sending on your behalf: staff mailboxes, contact forms, CRM, invoicing, booking confirmations, newsletters and support tools. Identify the owner of each service and whether it uses your domain or a provider-controlled return path and signature.
Test actual messages from each source. A mailbox test does not reveal whether invoices or password-reset messages are configured correctly. Keep the domain-to-email guide alongside this inventory when changing DNS.
Roll out in a controlled sequence
- Establish correct SPF and DKIM for known senders.
- Publish a DMARC policy and arrange a monitored aggregate-report destination.
- Review legitimate traffic and fix authentication or alignment failures.
- Move towards quarantine or rejection when the evidence supports enforcement.
- Continue checking reports after new tools or mail routes are introduced.
Monitoring with p=none is a useful discovery stage, but it does not request quarantine or rejection. Equally, starting blindly with rejection can block legitimate messages. Choose the rollout according to the domain's actual sending environment rather than a universal deadline.
Read reports and investigate exceptions
Aggregate reports can show sources, volumes and authentication outcomes. Someone must review them and distinguish forgotten legitimate services from unauthorised attempts. Use a reporting tool or maintainer capable of interpreting the data.
Avoid treating an unknown IP address as proof of a breach. Forwarders, service infrastructure and configuration changes can affect results. Investigate before changing a policy that supports normal business communication.
Keep the remaining defences
DMARC does not prevent lookalike domains, display-name impersonation or abuse of a compromised legitimate account. Use multi-factor authentication, train staff to verify payment changes and review mailbox access.
Authentication also differs from encryption; see TLS and end-to-end email protection for that layer. ResaHost's business email service can help connect mailbox setup with the relevant DNS configuration. Bring the full sender inventory so the work protects ordinary business mail as well as the main inbox.