SPF, DKIM, and DMARC Setup for Business Email

To improve the delivery of business email messages, you need to configure SPF, DKIM, and DMARC authentication together on your domain. First identify which services send messages on your behalf; then add the DNS values provided by your provider one by one and check the results of new test messages along with DMARC reports. These records do not guarantee delivery, but they make the domain’s authorized senders and authentication policy clearer.

What do the three records do in business email authentication?

SPF defines through DNS which servers are authorized to send email on behalf of your domain. The receiving server compares the sending source that connected for the message with this list. DKIM, meanwhile, adds a cryptographic signature to the message during sending; the recipient retrieves the public key from DNS to check whether the signature is valid and whether the content changed during transmission.

DMARC evaluates whether the SPF or DKIM result aligns with the visible sender domain. It can also determine whether reports should be sent for failed messages and how the policy should be applied. Even if SPF and DKIM appear valid on their own, the DMARC result may differ from what you expect if domain alignment is not achieved. Therefore, treat the records as parts of the same sending flow rather than as separate settings.

List your sending sources before setting up business email authentication

You must have access to the DNS management screen and the administrator panel of your business email provider. Also list every source that sends on behalf of your domain: the primary mail service, contact forms on the website, invoicing or marketing applications, and any customer support system. Use the current values supplied by your provider for SPF, DKIM, and DMARC; record names and key formats may vary by service.

Suppose your company uses a single email provider for employee mail, but the website also sends notifications directly from its own server. If the SPF value includes only the mail provider, website notifications may fail. In that case, instead of creating a second SPF record, the better option is to combine both authorized sources within a single SPF policy in the format recommended by the provider, or direct the website to a verified sending relay. If the website does not send messages, do not authorize an unnecessary source.

Add SPF, DKIM, and DMARC records in a safe order

1. Review the existing DNS records. In the domain’s DNS screen, compare the TXT records with the domain verification section of the email provider. If you see multiple SPF records for the same domain, do not add another record; follow the provider’s merging instructions. Save the old value somewhere; you may need this information to roll back before the change.
2. Update the SPF record with the provider’s value. Check that the TXT record is added to the correct domain and covers the existing authorized sending sources. If the test result shows SPF failure, first look for a missing service or a typing error in the record; do not add every source indiscriminately. If there are multiple SPF records, the goal is not to duplicate them randomly but to create one consistent policy.
3. Enable the DKIM signature. In the email management panel, create a DKIM key for your domain or add the selector name and TXT/CNAME value supplied by the provider to DNS. Wait for the panel to show the status as verified. If DKIM still fails, check whether the key was published under the wrong selector and whether the DNS provider saved the value without changing it; note the existing value before generating a new key.
4. Start DMARC with a monitoring policy. Create the TXT record recommended by the provider for the domain’s DMARC subdomain in DNS, and use an address controlled by your organization to receive the reports. Collecting reports at the initial stage lets you see which sources fail SPF or DKIM authentication. If you do not have access to the reporting address, specify an organization-managed mailbox instead of using a random personal address.
5. Retest the same sending flow. After the change, send the same type of test message from a working account; in the message details at the recipient, review the SPF, DKIM, and DMARC results and their alignment with the visible sender domain. The result may not change immediately because of DNS caches. If SPF and DKIM pass but DMARC fails, check in the provider’s relevant settings that the signing or envelope-sender domain aligns with the visible sender domain.

How should you tighten the policy based on the results?

If DMARC reports show only the mail provider you expect and the messages pass aligned authentication, you can consider gradually moving to a stricter policy supported by your provider. Conversely, if the website, CRM, or automation tool appears as a failing source, first enable DKIM in that service or move its sending to verified mail infrastructure. Tightening the policy before correcting the source can cause legitimate notifications to be quarantined or rejected.

For example, if reports show that employee mail passes but order notifications come from another application, do not try to solve the problem by expanding SPF without limits. Examine the application’s DKIM support and visible-sender settings; if it does not support them, direct the application to the email provider’s verified SMTP or API flow. Then send a new order notification and check the report generated after only this change. If the problem continues, restore the previous setting and consider temporarily sending notifications from a separate, verified subdomain.

What evidence should you keep when verifying the changes?

Before each change, keep a record of the DNS value and the original status in the email panel; do not change multiple settings at the same time. Note the sending time of the test message and evaluate the receiving server’s message headers, the provider’s verification screen, and the DMARC reports for that same time together. A result that appears successful at one recipient does not mean that all recipients apply the same policy; provider behavior, caching, and report delays may differ.

If you do not manage the domain’s DNS settings or mail services yourself, first prepare the recommended values shown in the provider’s verification screen and the existing records. You can compare the technical terms and meaning of the records with the relevant hosting guides on İyibirNet; however, obtain the original values for your domain only from your own provider’s management screen.

The first safe next step is to list all services that send messages and record the current SPF and DKIM results in a single test message. Do not tighten the DMARC policy before this inventory is complete; otherwise, it will be harder to distinguish which source has failed.