SPF, DKIM, and DMARC Settings for Corporate Email

To reduce the likelihood that corporate email messages will end up in recipients’ spam folders and make it harder for others to impersonate your domain, you should first configure SPF, DKIM, and DMARC. You need access to your domain’s DNS management and the administration panel of the email service you use. Before adding records, note the existing DNS values, because even a small change to the same service can affect sending and receiving flows.

What does corporate email authentication solve?

SPF defines in DNS which servers are authorized to send email on behalf of your domain. DKIM adds a digital signature associated with your domain to the outgoing message; the receiving server verifies that this signature has not been altered. DMARC determines how SPF and DKIM results should align with the sender domain in the message header and states which policy should be applied to messages that fail.

These records do not guarantee delivery by themselves. Your sender reputation, the recipient’s filters, message content, sending volume, and the service provider’s own rules also affect the outcome. Nevertheless, if you use a particular sending service, that service’s authorized server should be included in the SPF record; the DKIM key should be enabled in the provider’s panel; and the DMARC policy should not be hardened before the existing flow has been verified.

Map the existing sending flow before you begin

First, list which systems send messages on behalf of your domain: for example, your primary email provider, your website contact form, customer relationship software, and marketing platform. If a system’s messages are not authorized in SPF, SPF may fail. For a system that does not support DKIM, it is safer to review the provider’s alternative authentication method or a separate sending subdomain.

Suppose employees send messages through one email service while your website sends messages through a separate application server. Adding only the email service’s SPF value may leave website forms outside authentication. If messages are sent only from employee accounts, a narrower SPF record is preferable; if there are two separate sources, both must be combined in the single SPF record recommended by the providers. Instead of creating multiple SPF records for the same domain, edit the existing record.

How to configure corporate email SPF, DKIM, and DMARC records step by step

The following procedure is intended for people who have access to the domain’s DNS panel and the email service’s administrator screen. Menu names may vary by provider; use the hostname, record type, and value supplied by the service provider.

1. Back up the existing DNS records. Export the TXT records for your domain from the DNS panel or copy their values to a secure location. In particular, preserve the existing SPF record and, if present, the _dmarc record. If an SPF record already exists for the same name, do not create a new record; determine which sending sources are missing and adjust the existing value accordingly.
2. Update the SPF record according to the service list. Use the TXT value recommended by your email provider together with authorization for your website or any third-party sending service, if applicable. If the DNS panel accepts the record but SPF appears as failed in recipient reports, check whether the sending server is actually defined in SPF. If the problem affects only application messages, add the correct sending record for that application instead of loosening the entire policy.
3. Create and enable the DKIM key. Open the DKIM setup section in the email service’s administration panel and add the selector name and TXT or CNAME target provided by the service to the DNS panel. When verification succeeds, the provider’s panel will show the status as enabled or verified. If the record cannot be found, check whether the panel automatically adds the underscores, periods, and domain suffix in the selector name; before creating the same record a second time, wait for DNS visibility to propagate.
4. Begin the DMARC policy in monitoring mode. Add a monitoring policy to the _dmarc hostname with a report address supported by your provider. The purpose at this stage is to observe failed messages; do not use a strict policy that rejects messages before identifying legitimate systems whose SPF or DKIM results fail. If the reports show only an unexpected sending source, distinguish whether it is a real application or unauthorized use.
5. Repeat the same sending operation and check the new evidence. After making the changes, send a short test message from the same corporate account to a recipient address you control. Inspect the SPF, DKIM, and DMARC results in the message’s original headers; also check new DMARC reports covering the period after the change. If SPF and DKIM succeed but DMARC fails, examine domain alignment: the visible sender domain may not match the signing domain or the return-path domain.

Choosing a safe correction based on the results

If SPF fails and DKIM succeeds, first investigate whether the sending service is missing from the SPF record; do not make random DNS changes that could disrupt DKIM authentication. If DKIM fails and SPF succeeds, check that the selector and key in the service panel match the DNS record exactly. If both methods succeed but DMARC fails, the issue is usually domain alignment; examine how the provider configures the visible sender domain, return-path, or DKIM signing domain.

If the test message produces the correct result but actual application messages fail, assume that the application and email service use different sending paths and inspect the new message’s headers separately. Change only one DNS value at a time so that correcting one source does not affect another. Preserve the value from before the change; if the new value causes unexpected receiving or sending problems, revert only the latest change and test again.

When should you tighten the DMARC policy?

If monitoring reports show that all known sending sources are authenticated with SPF or DKIM and legitimate messages have DMARC alignment, you can consider tightening the policy gradually. You may first consider marking failed messages as spam, followed by a rejection approach; the exact values and report format vary by provider. If an unknown source appears regularly, verify before rejecting whether it is a forgotten application, a forwarding system, or genuinely unauthorized sending.

You can use relevant resources on İyibirNet to review your domain records and the sending services you use together. The next safe step is to send the same test message again with the new configuration and compare the header results for that message with the earlier records.