Email spoofing can make a message appear to come from your business domain even when it was sent by someone else. Setting up SPF, DKIM, and DMARC gives receiving email systems ways to check whether a message is authorized to use your domain. To stop email spoofing with SPF, DKIM, and DMARC without disrupting everyday business communication, take a measured approach: identify your senders, configure authentication, monitor results, then strengthen enforcement.
These controls help protect your own domain from being impersonated. They do not prove that a message is harmless, prevent lookalike domains, or stop someone from using a compromised employee account. Treat them as one part of a wider email security plan.
What SPF, DKIM, and DMARC do
SPF tells receiving systems which mail servers are permitted to send email for your domain. It is published as a DNS record. If a message comes from a server that is not authorized by your SPF policy, the receiving system can treat that as a failed check. Your email provider’s SPF setup guidance can help you identify the provider-specific details to include.
DKIM adds a digital signature to outgoing messages. A receiving system can check the signature against a public key published in your domain’s DNS. This helps verify that the message was signed by an authorized sender and that signed parts of it have not been changed in transit. Your email provider or sending platform usually supplies the DKIM configuration details.
DMARC tells receiving systems what to do when a message using your domain does not pass the required checks. It also lets your organization receive reports about authentication activity, if you configure a reporting destination. DMARC connects SPF and DKIM results to the domain that appears in the visible From address. The DMARC specification describes the protocol.
For DMARC to pass, a message must pass SPF or DKIM, and the domain that passes must align with the visible From domain. A message can pass SPF for a sending service’s domain but still fail DMARC if that domain does not align with your business domain. DKIM can also pass while failing to align if it uses a different signing domain.
Use a staged setup
Start by finding every service that sends your email
Before changing DNS, make an inventory of systems that send messages using your business domain. Check your regular email host, marketing platform, invoicing system, customer relationship management tools, website forms, scheduling tools, and any other service that sends on behalf of your organization.
Ask the owner of each system or your email provider whether it sends as your domain and what authentication records it requires. Include subdomains and less frequently used systems, such as automated notifications. A forgotten sender can become a source of failed authentication after you tighten your policy.
Configure SPF and DKIM with your providers
Work from the instructions provided by your email host and third-party services. SPF identifies authorized sending sources in DNS. Keep the record managed and current as services change, and avoid creating competing SPF records for the same domain. If you are unsure which services belong in the policy, ask your provider or IT administrator before editing it.
Enable DKIM for each service that sends from your domain when the service supports it. Follow its instructions to publish the required DNS entries, then confirm that the service is signing outgoing messages. Do not assume that turning on DKIM for your main email host also covers a separate marketing or billing platform.
DNS changes can affect all users of a domain. Coordinate updates with the person responsible for your DNS and email administration, and keep a record of what was changed and why.
Publish DMARC in monitoring mode
Begin with a DMARC policy of p=none. This asks receiving systems not to quarantine or reject messages based on DMARC, while allowing you to collect reports if a reporting address is configured. The record is published in DNS for the domain, using the format and reporting options supported by your provider. Microsoft’s DMARC setup guidance explains its configuration for Microsoft 365 domains.
DMARC reports can show which sources are sending mail that claims to use your domain and whether SPF or DKIM passed and aligned. Reports are technical, so you may need a reporting tool or IT support to interpret them. They can help distinguish an authorized service with a configuration problem from mail you do not recognize.
Review results before tightening enforcement
Use the monitoring period to compare report data with your sender inventory. For each legitimate source that fails DMARC, check whether SPF authorization, DKIM signing, or domain alignment needs attention. Recheck services that send through an outside platform, and consider how forwarding may affect authentication results.
Once legitimate sending sources are accounted for and authentication is working as intended, you can consider moving to p=quarantine, which asks receiving systems to treat failing messages as suspicious, or p=reject, which asks them to reject failing messages. Receiving systems apply the policy according to their own handling, so monitor reports and business email after a change. If legitimate messages begin to fail, investigate the sender and alignment settings before making further adjustments.
For organizations with compliance responsibilities, document who approved the DNS changes and how your team reviews authentication reports. This can fit into broader IT compliance and regulatory support practices.
Common issues to watch for
- Third-party senders: A service may send using your From address but may not be included in SPF or configured to sign with aligned DKIM. Confirm the service’s recommended setup.
- Forwarding: Forwarded email can change how SPF is evaluated because the message may reach its destination from a different server. DKIM may still help if the message’s signed content is preserved, but outcomes depend on the message and forwarding path.
- Subdomains: Mail from a subdomain may need its own review. Check which domains each system uses and how your DMARC policy applies to them.
- Overly quick enforcement: Switching to quarantine or reject before you have identified legitimate senders can disrupt wanted messages. Monitor first and make changes deliberately.
SPF, DKIM, and DMARC protect your domain from unauthorized use; they do not secure an employee’s mailbox if an attacker takes over the account. Use account protections as well, including strong multifactor authentication for business accounts. And remember that these settings do not stop staff from receiving spoofed messages that use someone else’s domain. Mail filtering, staff awareness, and a clear process for reporting suspicious messages remain important.
Frequently asked questions
Can SPF or DKIM pass while DMARC fails?
Yes. DMARC checks whether a passing SPF or DKIM result aligns with the domain in the visible From address. A pass for an unrelated sending or signing domain does not satisfy that alignment check.
Can strict DMARC settings cause legitimate email to be rejected?
They can affect legitimate messages if an authorized sender is missing from your setup or does not pass with an aligned domain. Inventory senders, review reports, and fix configuration issues before moving from monitoring to enforcement.
Do these settings stop someone from taking over an employee’s email account?
No. These controls help verify authorized use of your domain, but they do not prevent account takeover. Protect employee accounts separately with appropriate access controls and authentication.
Do they protect staff from spoofed messages sent from another domain?
Not directly. Your domain’s records do not control how other organizations authenticate their domains. Use email filtering and staff reporting procedures to help address suspicious incoming messages.
Make authentication a managed process
SPF, DKIM, and DMARC work best when they reflect the services your business actually uses. Inventory senders, configure each provider carefully, monitor reports, and raise enforcement only after legitimate email is accounted for. If you need help reviewing email authentication or coordinating DNS changes, contact Zevonix to discuss your business IT needs.