To strengthen business email protection, inventory every service sending on behalf of your domain, then configure and verify SPF, DKIM and DMARC. Enforcing a strict policy before identifying those senders can cause legitimate invoices, donation receipts or other messages to be rejected.
These mechanisms help receiving servers assess a message’s authenticity. They reduce some forms of domain impersonation, but do not stop all spam, lookalike domains or abuse of a genuinely compromised account.
What SPF, DKIM and DMARC check
SPF: authorized sending servers
SPF identifies servers allowed to send for a domain used in the message’s technical envelope. That domain can differ from the visible “From” address. A valid SPF result alone therefore does not confirm the address a reader sees.
DKIM: a verifiable signature
DKIM adds a cryptographic signature associated with a domain. Receiving servers use a key published in DNS to check the signed parts of the message. Changes to those parts in transit can invalidate the signature. DKIM does not encrypt the email or establish that its contents are truthful.
DMARC: alignment and policy
DMARC connects authentication to the domain in the visible “From” address. A message passes DMARC when at least one mechanism, SPF or DKIM, passes with a domain aligned to that address under the configured rules. Only one needs to pass with alignment, although setting up both makes sending more resilient.
DMARC lets domain owners publish a policy for messages that fail and request reports. Recipients still apply their own handling rules. Microsoft’s email authentication documentation explains how these mechanisms work together.
Inventory senders before changing DNS
Look beyond Outlook or Gmail. Check accounting software, the CRM, newsletters, the website, forms, printers, payment services and fundraising platforms.
For each service, record an owner, the domains it uses and the authentication method supported by its provider. Send a test message to an external mailbox and inspect authentication results in the headers, rather than simply checking whether it arrived in the inbox.
Fix common configuration errors
Publishing multiple SPF records at the same domain name is not a way to add providers. You need a coherent configuration that respects SPF’s DNS lookup limits. The actual values depend on the services you use.
Publishing a DKIM key may not be enough: signing also needs to be enabled in the service and verified in outgoing messages. For DMARC, check alignment rather than relying on two isolated “pass” results. Forwarded messages can fail SPF; a preserved DKIM signature may help in that situation.
A move from GoDaddy to Microsoft 365 is a useful opportunity to review the inventory. Avoid changing every setting at once without a way to trace a problem to its cause.
Introduce DMARC enforcement gradually when needed
An observation phase lets you review reports before requesting quarantine or rejection of failing messages. Observation alone does not constitute an enforcement policy. First correct legitimate senders that are not aligned, test their mail and then decide how to strengthen the policy.
Assign someone to review reports, protect access and investigate anomalies. Aggregate reports describe sources and authentication results; they are not copies of all your email. Document each change and retain a record of previous settings.
Who maintains the configuration?
The domain owner needs to know when a new service starts sending email. Include that check in software purchasing and access changes covered by the employee onboarding and offboarding checklist.
Microsoft 365 and Google Workspace administration includes this coordination between email, DNS and providers. There is no universal DNS record to copy: a correct configuration describes your actual environment.