SPF, DKIM and DMARC setup for cold email domains

Cold email runs on the reputation of a domain. Before that domain sends anything, receiving servers should be able to tell that your mail is really yours. SPF, DKIM and DMARC are how a domain says so.

This guide walks through the three records in order, shows how to verify each one, and describes a DMARC policy that moves from monitoring toward enforcement. It also covers the mistakes that tend to cause trouble and what to do after you change sending providers.

For the wider picture of domains, warm-up and daily volume, read Cold email deliverability. For definitions, see the glossary entries for DMARC and deliverability.

Who this is for

This guide is for people who send cold email from a domain they control and want the DNS side done properly:

A founder or sales lead setting up a first sending domain.
An operations or revops person who inherited a domain with half-finished records.
A developer who wires up outbound sending and wants a checklist to hand over.

It assumes you can edit DNS records for the domain, or can ask someone who can. It does not assume you know the record formats. Your DNS host and your sending tool show the exact values to publish, and this guide does not repeat them.

If you use Outlevo's managed mailboxes, the setup below is mostly done for you. Outlevo buys the sending domains, creates the mailboxes through Zapmail, sets up DNS and warms them up, so you never touch your main domain [[1]](#sources). You can still use the verification and recheck sections to confirm the result. If you bring your own domains and mailboxes, you will do the steps yourself.

Why the three records matter now

The rules are no longer optional for volume senders. As checked on 2026-10-22, Gmail and Yahoo require SPF or DKIM for all senders, and SPF, DKIM and DMARC for bulk senders [[2]](#sources). The other outside rules quoted in this guide were checked the same day.

Google's own guideline puts it this way: "email senders who send more than 5,000 messages per day to Gmail accounts must meet the requirements in this section. Set up SPF and DKIM email authentication for your domain." [[3]](#sources)

Microsoft announced: "For domains sending over 5,000 emails per day, Outlook will soon require compliance with SPF, DKIM, DMARC." [[4]](#sources) The word "soon" comes from that announcement. The requirement may already be in effect, so check Microsoft's current guidance before you rely on the wording.

A cold email program may stay well under those volumes. Setting all three up anyway means you do not have to redo the work when you scale.

What each record is, in plain terms:

SPF (Sender Policy Framework) is the record you publish in Step 1.
DKIM (DomainKeys Identified Mail) "permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message." [[5]](#sources)
DMARC lets "a mail-originating organization express domain-level policies and preferences for message validation, disposition, and reporting." [[6]](#sources)

Before you start

Make three decisions before touching DNS.

1. Which domain will send. Outlevo's managed mailboxes are set up so you never touch your main domain: you choose from the domains Outlevo proposes and the sender names, and Outlevo does the purchase, the DNS records, the mailboxes and the warm-up [[1]](#sources). If you bring your own, choose the domain before you touch DNS.

2. Which tool sends. Every system that sends mail as this domain needs to be covered by the records. With Outlevo and Smartlead, Outlevo writes and schedules the emails, and Smartlead sends them from the mailboxes in your Smartlead account [[7]](#sources). So Smartlead and your mailbox host are the senders your records must cover. If you send through another provider, such as Mailgun, see Mailgun SPF, DKIM and DMARC setup.

3. Who owns the DNS. Find out where the domain's DNS is hosted and who can log in.

Write down every service that will send as this domain. You will use this list in the SPF step and again when you change providers.

Steps

Step 1: Publish SPF

SPF is a DNS record on your sending domain that names the services allowed to send for it. Your sending tool gives you the value to include. Add it to the domain's existing SPF record if one exists, and create one only if there is none.

Keep the record short. RFC 7208 limits the DNS-lookup terms in an SPF record: "SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation" [[8]](#sources). Count the lookup terms each service adds before you add the next one.

To verify: look the record up with any public DNS lookup tool and confirm that:

There is a single SPF record on the domain.
It names every service on your sender list.
It has no entries for services you stopped using.

Step 2: Publish DKIM

DKIM adds a signature to each message. The public half of the key lives in DNS, and your mailbox provider or sending tool generates it. You publish the record it gives you at the exact name it specifies.

Copy the name and value exactly. After saving, look the record up again and compare it character by character with what the tool showed.

Then confirm the signing actually works. Most mailbox providers and sending tools have a "verify" or "check" button for DKIM. Use it. As a second check, send a test message to a mailbox you control and open the message headers to see whether the DKIM result is a pass.

Check that the signing domain in the headers is your sending domain, since DKIM associates the signing domain with the message [[5]](#sources).

Step 3: Publish DMARC at monitoring

DMARC tells receivers what you want done when SPF and DKIM do not line up with the visible From domain, and where to send reports. Start with the weakest policy. Yahoo's guidance is: "Publish a valid DMARC policy with at least p=none" [[9]](#sources).

A p=none policy meets that minimum. Add a reporting address that goes to a mailbox someone actually reads, or to a service that reads the reports for you.

Verify the record by looking it up and confirming it is published on the sending domain and has a valid policy tag.

Step 4: Send, then read the reports

Send a small amount of real mail from the domain. Then read the DMARC reports. You are looking for three things:

Mail that passes. This is what you expect from your sending tool.
Mail that fails. Find out which service sent it. It is either a sender you forgot to add, or something sending without your approval.
Senders you did not know about.

Do not move to a stricter policy while the reports show a legitimate sender failing. Fix that sender's SPF or DKIM first.

Step 5: Move toward enforcement

Once the reports show only mail you recognize and it passes, tighten the policy. The usual progression is from p=none to p=quarantine, and then to p=reject.

Move one step at a time and read the reports after each change. How long to stay at each step depends on how much mail you send and how clean your reports are. Hold each level until a full cycle of your normal sending shows nothing unexpected failing.

For a dedicated cold-sending domain with a short sender list, getting to enforcement is usually simpler than on a company's main domain, because there are fewer systems to account for.

Step 6: Confirm the sending tool agrees

Your sending setup may check the records too. With the Smartlead connection, a campaign does not send until each mailbox is connected and warmed up, and its domain must have SPF, DKIM and DMARC checked in the last 7 days [[7]](#sources). So a record you set up months ago and never rechecked can block a launch. Recheck before you launch, not after.

If you use managed mailboxes, a new mailbox sends nothing until it is warm. That takes at least 14 days and usually about 3 weeks [[1]](#sources). Use that time to confirm the records. The warm-up state and reputation of each mailbox are checked daily [[1]](#sources).

What to check

Run through this list when you set a domain up, and again whenever anything changes.

Records

One SPF record, covering every sender on your list and nothing you retired.
SPF stays within the limit of 10 DNS-lookup terms [[8]](#sources).
A DKIM record for each service that signs mail, published at the exact name the service gave you.
A DMARC record with a valid policy, at least p=none [[9]](#sources), and a report address someone reads.

Alignment

The domain in the visible From address is the domain your SPF and DKIM results refer to.
A test message shows a pass for SPF, DKIM and DMARC in its headers.

Common misconfigurations

Adding a second SPF record instead of editing the first. Merge senders into one record.
Going over the lookup limit. Remove services you no longer use before adding new ones.
Publishing a DKIM name that differs from what the service gave you. Look the record up after saving and compare it with the original.
Publishing DMARC and never reading the reports. The policy only helps if you act on what it shows.
Jumping to a strict policy too early. If a real sender is still failing, enforcement blocks your own mail.
Checking once and forgetting. The 7-day check window in the Smartlead connection shows that checks are expected to be recent [[7]](#sources).
Treating authentication as the whole job. Records prove who you are. They do not make a list clean or a message wanted. Bounces still hurt a domain. Outlevo's email verification costs 1 credit per check [[10]](#sources), and the ZeroBounce page has the pricing of a dedicated verification tool.

Monitoring after launch

Watch for bounces, replies and unsubscribes. With the Smartlead connection, sent, reply, bounce, unsubscribe and category-change events come back to Outlevo by webhook [[7]](#sources). A jump in bounces after a DNS edit is a signal to look at the records first.

If you build your own checks, Outlevo's API reference lists sender-domains and mailboxes among its resources [[11]](#sources), so domain and mailbox setup can be read from code. Start in the developer hub if that suits your team.

After you change providers

Changing your sending tool, mailbox host or DNS host means the records need checking again. Treat it as a new setup with a checklist.

List the old and new senders. Note which services will stop sending and which will start.
Add the new service before you remove the old one. Publish its SPF entry and DKIM record while the old sender still works, so mail is covered during the move.
Verify the new records exactly as in Steps 1 to 3: lookup, tool check, test message with headers.
Send a small batch and read the DMARC reports. A sender you forgot shows up as a failure.
Remove the old service from SPF and delete its DKIM record once the reports show it no longer sends. Leaving it in place uses up SPF terms and keeps a key published that nobody manages.
Keep DMARC where it is until the reports are clean again. If you were at an enforcing policy, consider stepping back to monitoring during the move and tightening again afterward.
Recheck within the window your sending tool expects. With Smartlead, that is a check in the last 7 days [[7]](#sources).

If the new provider is Outlevo's managed mailboxes, the DNS records come from Outlevo [[1]](#sources). You still need to remove old senders from your own domain's records if that domain keeps sending other mail.

Next step

Pick the domain you plan to send from and write down every service that sends as it. Publish SPF and DKIM, add DMARC at p=none, and send a small batch. Read the reports for a full cycle of normal sending, then tighten one step at a time.

If you want Outlevo to handle domain purchase, DNS and warm-up, see managed mailboxes. Builder includes 1 domain and 2 mailboxes, and Growth includes 2 domains and 4 mailboxes [[1]](#sources). If you send through Smartlead, the Smartlead integration page describes the pre-send checks. Plans are on the pricing page.

Once the domain is ready, the next question is who to write to. The free ICP assessment is where that work starts. If you sell to developers, Outbound for developer tools covers that audience.