Most write-ups about cold email deliverability lead with sending volume and warmup schedules. Those matter, but they're the second problem. The first problem is simpler and gets skipped constantly: whether your domain is even configured to let mail pass authentication checks in the first place.
This is a checklist, not a think piece. If you're setting up a sending domain for outreach, work through it in order.
1. SPF: who's allowed to send as you
An SPF (Sender Policy Framework) record is a TXT record on your domain listing which mail servers are authorized to send on your behalf. Receiving servers check this before anything else. No SPF record, or an SPF record that doesn't include your actual sending provider, and you're already flagged as suspicious before content is even scanned.
Common failure: a domain with an SPF record covering Google Workspace for regular email, but nothing added for the SES identity or cold email tool now also sending from that domain. Two senders, one SPF record covering only one of them.
v=spf1 include:_spf.google.com include:amazonses.com ~all
Check your current record with dig TXT yourdomain.com or a free scanner. EmailQo's SPF checker runs this check without requiring a signup, useful for a quick sanity check before you go further down the list.
2. DKIM: proving the email wasn't tampered with
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outgoing mail, generated with a private key and verified by receivers against a public key published in your DNS. It confirms the email's content matches what left your server, and that it genuinely came from a server authorized to sign for your domain.
Setting this up with SES specifically means enabling easy DKIM in the SES console, which generates CNAME records you add to your DNS, then waiting for SES to verify them, usually within 72 hours but often faster. Skipping this step is one of the most common reasons SES-based cold email setups underperform: the mail sends fine technically, but arrives unsigned, which plenty of receiving servers treat as a strong spam signal on its own.
3. DMARC: the policy that ties it together
DMARC (Domain-based Message Authentication, Reporting and Conformance) tells receiving servers what to do when SPF or DKIM checks fail, and sends you reports when they do. A minimal starting record:
v=DMARC1; p=none; rua=mailto:Emails are not allowed
Start with p=none so you get visibility without risking legitimate mail getting rejected while you're still debugging SPF and DKIM. Tighten to quarantine or reject only once reports confirm your legitimate mail is passing cleanly. Jumping straight to p=reject on a misconfigured setup is a reliable way to have your own outreach silently dropped by receiving servers, including the human who would've replied.
Why this matters more for cold email than regular business email
Receiving servers apply more scrutiny to unsolicited mail than mail that's part of an established back-and-forth conversation. A domain with clean, strict authentication is one of the few concrete signals you control that works in your favor regardless of content. Get it wrong and no amount of warmup, list quality, or copywriting compensates, because the mail is getting filtered on a technical layer before any of that is evaluated.
If you'd rather not run this by hand
This is genuinely a few hours of DNS work done once, and worth doing yourself to actually understand your setup. If you'd rather have warmup, authentication monitoring, and reply handling managed on top of your own Gmail, Outlook, or SES connection instead of stitching tools together after the fact, that's the gap EmailQo is built to cover, using the same SPF, DKIM, and DMARC fundamentals above under the hood rather than something proprietary.
Either way, run the three checks above before you debug anything else. A broken DNS record will sink a well-written campaign every time, and no sending tool, free or paid, can fix that for you.