Setting Up SPF, DKIM, and DMARC to Protect Business Email
Business email is commonly used for internal communication, customer support, system notifications, and marketing activities. However, if a domain is spoofed, recipients may receive phishing messages using an address that closely resembles the official one. This issue not only affects brand reputation but also causes customers to doubt legitimate emails, especially when the message concerns payments, accounts, or personal information.
The three mechanisms SPF, DKIM, and DMARC were created to give receiving servers more grounds for evaluating the origin of an email. They are not a single solution that prevents every form of fraud, but when configured correctly, they form an important foundation for domain-based email authentication. Businesses can also use data from these mechanisms to identify which services are sending email on their behalf and adjust their policies accordingly.
What Do SPF, DKIM, and DMARC Do?
SPF, short for Sender Policy Framework, is a record in the DNS system that indicates which servers or services are authorized to send email using a business’s domain. When an email arrives at a receiving server, that server can check whether the sending IP address is included in the published list. If the sending source is not authorized, the email may be marked as suspicious, placed in the spam folder, or rejected, depending on the recipient’s policy.
SPF is usually declared as a TXT record. The record may include the primary mail server, external email-sending platforms, and a mechanism for handling sending sources that do not match. An important point is that SPF checks the sending server; it does not prove that the email content has not been altered. In addition, a domain should have only one valid SPF record. If multiple SPF records exist simultaneously, the check may produce unexpected results.
DKIM, short for DomainKeys Identified Mail, uses a digital signature to attach authentication information to an email’s header. The sending service creates the signature using a private key, while the receiving server uses the public key published in DNS to verify it. This method helps confirm that the email was signed by a system authorized to use the domain and that important content in the message was not altered during transmission.
The DKIM public key is usually placed at a subdomain called a selector. A selector allows a domain to use different keys for different systems or operational stages. The private key must be kept confidential within the email-sending system. If the key is exposed, an attacker may be able to create a valid forged signature, so key management is an inseparable part of DKIM configuration.
DMARC, short for Domain-based Message Authentication, Reporting and Conformance, combines SPF and DKIM results with an email-handling policy. DMARC also checks the alignment between the domain displayed in the sender address and the domain authenticated by SPF or DKIM. As a result, an email may pass SPF but still fail DMARC if the authenticated domain does not match the domain visible to the recipient.
Why Is Configuring SPF Alone Not Enough?
SPF helps identify which servers are authorized to send mail, but it has an important limitation. In some cases, information related to the SPF check may no longer remain intact when an email passes through intermediary servers. DKIM adds a layer of authentication based on a signature attached to the email, while DMARC helps businesses define how messages that do not meet requirements should be handled.
Simply adding an SPF record and considering the job finished can lead to many misunderstandings. A business may be using multiple services to send email, such as an internal mail system, a customer support platform, a marketing tool, and transaction software. If a service has not been included in SPF or has not enabled DKIM, legitimate email from that service may be rated poorly. Conversely, if too many sources are added to SPF without review, it becomes difficult for the business to know which services genuinely need sending permission.
DMARC does not replace SPF or DKIM. It works more effectively when at least one of the two authentication mechanisms passes and the authenticated domain is properly aligned. Therefore, the implementation process should begin by creating a list of all sending sources, then configuring SPF and DKIM before applying a strict DMARC policy.
A Safe Implementation Process
1. Inventory All Sending Sources
Before modifying DNS, a business should record every system that is sending email using its domain. This list may include the primary email server, contact forms on the website, invoice-sending systems, marketing automation tools, customer support platforms, and notification-sending services. An overlooked sending source may cause legitimate email to fail authentication after the new policy is applied.
The inventory should also distinguish between systems that are still in use and services that have been discontinued. Sending permissions that are no longer needed should be removed rather than retained indefinitely. The fewer unnecessary sending sources there are, the smaller the domain’s risk surface and the clearer incident investigations will be.
2. Create SPF with the Minimum Necessary Scope
The SPF record should include only the servers or services that genuinely have permission to send. Do not copy a service’s configuration verbatim without understanding the meaning of each component. When adding multiple providers, check how they require their records to be declared and avoid creating multiple independent SPF records for the same domain.
After updating the record, check whether it has been published correctly for the domain where it is needed. DNS changes may take time to become visible to other servers. During this period, sending test messages to different mailboxes can help detect syntax errors, missing sending sources, or inconsistent configurations at an early stage.
3. Enable DKIM on Each Appropriate System
Email providers commonly create a selector and provide the DNS record information that needs to be added. The business must publish the public key in the correct location and then enable DKIM signing on the sending system. If a service uses a subdomain or a custom mechanism, clearly determine which domain appears in the signature and whether it aligns with the sender address.
The private key should not be sent through insecure channels or stored in public documents. When changing providers, the old selector should also be reviewed. Delete the old record only after confirming that no legitimate email still depends on that key, because deleting it too early may interrupt authentication for messages still being sent from the old system.
4. Start DMARC in Monitoring Mode
DMARC can send aggregate reports about sending sources and authentication results. During the initial phase, a business should use a monitoring policy to observe activity before requiring receiving servers to handle failing emails strictly. Reports help answer important questions: which sources are sending mail, which sources pass SPF, which sources have DKIM, and whether any unfamiliar source is using the domain.
Report data should be read according to trends rather than by looking at just one individual email. A legitimate sending source that has not been configured correctly may appear repeatedly. After verifying and correcting the necessary systems, the business can gradually move to a policy requiring failing messages to be placed in a suspicious area, and only then consider a rejection policy for appropriate cases.
Common Configuration Errors
The most common mistake is failing to list sending sources before modifying DNS. A business may remember only its primary email system while overlooking notification software or the website server. Another mistake is enabling a rejection policy too early, before there has been enough time to observe reports. In that situation, legitimate email may be rejected, and operators may have difficulty determining the cause.
Using the same selector or DKIM key for too many systems also reduces manageability. When a problem occurs, it becomes difficult for the business to revoke one service’s permission without affecting the others. In addition, retaining authentication records for providers that are no longer in use can create unnecessary sending permissions and complicate the checking process.
Businesses should also avoid viewing DMARC as a tool that absolutely guarantees that every phishing email will be blocked. Attackers can still use similar-looking domains, free email addresses, or fraudulent content that does not use the business’s domain. Therefore, domain authentication needs to be accompanied by employee training, procedures for verifying payment requests, and alerting mechanisms for unusual activity.
Long-Term Management Instead of One-Time Configuration
Email is a system that changes over time. When a business adds a marketing tool, changes mail providers, or deploys a new application, its authentication records also need to be updated. Each change should have an assigned person responsible, an implementation time, and a verification step afterward. This helps prevent a situation in which DNS configurations are modified repeatedly but no one knows which sending sources are authorized.
DMARC reports, the list of authorized services, and active DKIM selectors should be reviewed regularly. Sending sources that no longer appear can be verified and removed. If an unfamiliar source is detected, the business needs to determine whether it is a legitimate service that has not been documented or a sign that the domain is being abused. Keeping a history of changes is also useful when investigating email delivery problems or feedback from customers.
SPF, DKIM, and DMARC are not configurations intended only for large businesses. Any organization that uses email with its own domain can benefit from identifying sending sources, signing email, and publishing a clear policy. Implementing them step by step, beginning with monitoring and testing, will reduce the risk of disrupting legitimate mail.
Effective email protection requires coordination between DNS, mail-sending systems, and operational procedures. When the three authentication layers are built on a controlled list of sending sources, a business can improve its ability to identify spoofed email, maintain its domain reputation, and respond more proactively to changes in its email infrastructure. This work needs to be reviewed regularly, but a sound foundation from the outset will make subsequent adjustments clearer and safer.
