How to Set Up SPF, DKIM, and DMARC for Transactional Email

Password resets, receipts, account alerts, and form confirmations are part of your website's product. If these messages are rejected or sent to spam, customers may not be able to use the service they just signed up for.

SPF, DKIM, and DMARC give receiving mail systems ways to check whether a message is authorized to use your domain. They are important foundations, but they do not guarantee inbox placement or compensate for a poor sender reputation. This guide explains how to configure them for a small website without accidentally disrupting mail from your other services.

What SPF, DKIM, and DMARC do

Standard	What it checks	What you configure
SPF	Whether a sending server is authorized for the SMTP envelope sender domain	A DNS TXT record listing permitted senders
DKIM	Whether a message carries a valid signature from a domain	A public key in DNS; your email provider signs messages with the matching private key
DMARC	Whether SPF or DKIM passes and aligns with the domain in the visible From address	A DNS TXT record that sets a policy and can request reports

SPF checks the SMTP MAIL FROM identity, or the sending server's HELO identity in some cases. It does not directly authenticate the address a person sees in the From header. DKIM uses a signature on the message and a public key published in DNS. DMARC connects those checks to the visible From domain: at least one of SPF or DKIM must both pass and align with that domain for DMARC to pass.

That distinction matters when you use a third-party email provider. Its servers might pass SPF for a provider-owned domain, while your customer sees receipts@example.com. A passing SPF result alone does not mean the domains align. Ask the provider how to authenticate your sending domain and whether it supports a custom DKIM signing domain.

Google's current sender rules for Gmail are a useful baseline: all senders need SPF or DKIM, and senders delivering more than 5,000 messages per day to Gmail need SPF, DKIM, and DMARC. For direct mail, the visible From domain must align with SPF or DKIM. These are mailbox-provider requirements, not a universal volume threshold for when authentication matters; a small site can configure all three before it reaches bulk-sender volume.

Before changing DNS

Make a list of every service that sends mail using your domain. That can include a transactional email provider, your regular mailbox, a newsletter platform, a contact form, and a monitoring service. Check the DNS records already in place before changing anything; a record that looks unrelated may be needed by another sender.

Choose the domain you want customers to see in the From address, such as receipts@example.com. Some providers support a dedicated sending subdomain, such as mail.example.com, which can separate transactional mail from other sending activity. Use one only when the provider documents the setup and the visible From domain can still align with SPF or DKIM. A subdomain is optional, not a substitute for configuring the provider's exact DNS instructions.

You will need access to the DNS settings for the domain and to the email provider's sender-authentication settings. Your DNS host might be your registrar, your web host, or a separate DNS service.

Configure the records in a safe order

1. Verify your sending domain with the provider

Add the domain or sending subdomain in your email provider's dashboard. Confirm the exact address that will appear in From, the envelope sender or return-path domain used for SPF, and the DKIM signing domain. Providers may give you TXT records, CNAME records, or both. Copy the record type, host name, and value exactly as shown in that provider's current setup guide.

Do not reuse record values from another service or an old tutorial. Provider-specific values can change, and the DNS host may ask for a shortened name such as _domainkey rather than the full name shown in the provider's instructions.

2. Add or update SPF

SPF is published as a TXT record for the domain used by the SMTP envelope sender. Your provider will tell you which domain name to update and which sending service to authorize.

First check whether that domain already has a TXT record beginning with v=spf1. A given domain name must not have multiple SPF records; receivers can treat multiple records as a permanent SPF error. If another service already sends from that domain, update the existing SPF record using the instructions from both providers. Do not replace it with a new provider's value until you have confirmed that the existing senders are covered.

SPF also limits DNS-querying mechanisms during an evaluation. Adding a stack of include statements can exceed the limit and cause SPF to fail. Use the exact mechanisms your providers require and remove obsolete services only after confirming they no longer send mail.

3. Publish the DKIM key

The provider will supply a DKIM record, usually a TXT record or a CNAME that points to a provider-managed key. Publish it at the exact selector and host name given in the dashboard. The selector identifies the public key the receiving mail system should look up; the provider uses the corresponding private key to sign outgoing messages.

Do not create a key yourself unless the provider's documentation tells you to. If you use more than one mail service, each can have its own DKIM selector. Avoid overwriting an existing selector that another service still needs.

4. Add a DMARC record in monitor mode

Publish a TXT record at _dmarc for the domain in your visible From address. For a domain such as example.com, a basic monitoring record is:

v=DMARC1; p=none

The p=none policy asks receivers not to quarantine or reject messages just because DMARC fails. It gives you time to find legitimate mail streams that still need authentication. If you want aggregate reports, add a rua destination only after setting up an address or reporting service that can receive and process them. Reports can expose sending sources and IP addresses, so consider who will have access to them.

Use the host name and formatting expected by your DNS provider. If you send from a subdomain, confirm whether the DMARC record should be published for that subdomain or whether a parent-domain policy applies; follow the mail provider's current instructions rather than assuming all DNS dashboards handle names the same way.

5. Verify authentication with a real message

Wait for the DNS provider and mail service to recognize the records, then send a test message to an external mailbox you can inspect. Many services provide a domain-verification check. In Gmail, use Show original to inspect the authentication results; Google's guide to checking if a message is authenticated explains the SPF and DKIM indicators.

Check more than whether each line says PASS. For DMARC, the passing SPF or DKIM domain must also align with the visible From domain. If the message fails, compare the domain shown in the authentication result with the address your customer sees, then check the provider's setup instructions and the DNS host name you entered.

Test each important message type: a password reset, a receipt, and any account notification your site sends. Also test messages from your normal mailbox and newsletter service after changing an SPF record. A successful test proves that those samples authenticated; it does not guarantee that every future message will reach the inbox.

Move from monitoring to enforcement carefully

Once your legitimate senders consistently pass aligned SPF or DKIM and you understand the reports, consider moving from p=none to p=quarantine. After confirming that legitimate mail is unaffected, you can consider p=reject. These policies ask receiving systems to handle failing messages differently, but receivers make the final delivery decision.

Do not switch directly to rejection while you are still discovering who sends mail for your domain. A forgotten contact form, old newsletter integration, or second transactional provider could be affected. Keep a record of the services you authorize and review it when you change providers.

Authentication helps receiving systems evaluate whether a domain authorized a message. It does not stop someone who controls a legitimate mailbox from sending harmful mail, guarantee delivery, or replace clear consent and unsubscribe practices for marketing messages. If you also send campaigns, our guide to email marketing services for small businesses covers choosing a platform; configure its authentication separately as well.

Common setup mistakes

• Publishing a second SPF record: Merge authorized services into the existing record for that sending domain instead of creating another v=spf1 record.
• Changing the wrong DNS name: SPF belongs to the envelope sender domain, while DKIM uses a selector-specific name and DMARC uses _dmarc. Ask the provider which host each record authenticates.
• Assuming SPF PASS means DMARC passes: SPF can pass for a provider's domain but fail alignment with your visible From domain. Check the DKIM signing domain too.
• Enforcing DMARC before inventorying senders: Monitor first and confirm every legitimate sending service before requesting quarantine or rejection.
• Copying records from a different provider: Use the values shown for your own account and domain; don't guess at an include value, selector, or key.

A small-site checklist

1. List every service that sends mail for your domain.
2. Choose the customer-facing From address and confirm its domain with your provider.
3. Add the provider's DKIM record and update the correct existing SPF record.
4. Publish a DMARC record with p=none while you verify your legitimate traffic.
5. Send representative test messages and check both authentication results and domain alignment.
6. Enforce a stricter DMARC policy only after the reports and tests show that legitimate messages are covered.

For the protocol details, see the SPF specification in RFC 7208, the DKIM specification in RFC 6376, and the current DMARC specification in RFC 9989. For current mailbox requirements and DNS instructions, use Google's email sender guidelines and its guides to SPF, DKIM, and DMARC.