How To Check Your SPF, DKIM And DMARC Records Before You Send A Cold Campaign

Before a cold campaign, run a preflight check on what your sending domain publishes. SPF, DKIM and DMARC records live in your domain's public DNS, and you can read all three yourself in minutes.

One scope note up front: this is a record check. It tells you what your domain publishes, not what happens to any actual message. Records can be present while real mail fails authentication, so the second half of the job is verifying real results, which we'll get to.

What Each Record Publishes

SPF is a list. Your domain publishes which servers are allowed to send mail for it, and receiving servers check the message's envelope sender against that list. The envelope sender is a routing address, not necessarily the visible From address recipients see, so an SPF check alone says nothing about whether the visible sender is really you.

DKIM is a signature scheme. Your sending provider signs each message with a private key, and your domain publishes the matching public key so receivers can verify the signature. A valid signature shows the signing domain's infrastructure handled the message. By itself it does not prove the message is from your brand; that depends on which domain signed and whether it aligns with the visible From address.

DMARC is the policy. For the visible From domain, a message needs at least one of aligned SPF or aligned DKIM to pass. DMARC tells receivers what to do when neither passes: nothing (p=none), treat it as suspicious (p=quarantine), or refuse it (p=reject). It also sets where reports go, which is how you learn about failing or spoofed mail.

A record can exist and still say little. p=none is a monitoring policy, and Gmail's own sender guidelines allow it as a starting point. Many senders start there deliberately: collect reports, verify alignment with each sending service, then tighten the policy in stages. There is no single policy value that is right for every domain on day one.

Look Them Up Yourself

These are ordinary DNS TXT records. Check your domain's TXT records for one starting with v=spf1. Check _dmarc.yourdomain.com for a record starting with v=DMARC1, and read the p= value.

DKIM lives under a selector, such as google._domainkey.yourdomain.com, and the selector comes from your sending provider. DKIM is set up with the provider: they generate the keys and tell you exactly which records to publish, then verify them. Follow your provider's own verification steps rather than inventing records in DNS.

Records Are Step One, Real Mail Is Step Two

A PASS here means the scan found records matching its checks. It does not mean your configuration is complete or correct: it does not prove that every service sending for you is covered, that your provider signs with an aligned domain, or that actual messages pass. Those are properties of real mail, not of DNS.

So verify with real messages. Send a test from your actual sending tool to an address you control and read the authentication results in the message headers, or check the delivery dashboard your provider keeps. Make changes through your provider's setup and verification flow, then send another test message and read the results again. If a header shows a failure you can't explain, that is a provider question, not a guess-and-edit-DNS question.

Keep the limits straight either way. Authentication records don't measure inbox placement, check blacklists, or say anything about whether your content triggers spam filters. Those need a seed test and sending history. A clean record check is a preflight step, not a deliverability guarantee.

Run The Scan As Your Preflight

The Deliverability Scan on GTME reads these public records for you. Enter your sending domain and it checks SPF, DKIM and DMARC, marking each PASS or GAP with a suggested fix for whatever is missing.

Two things to know about the result. It probes a list of common DKIM selectors, so if your provider uses an unusual one, confirm against the provider's own docs before treating a DKIM gap as real. And treat the marks as a configuration check, not a certification. The scan marks p=none as a gap, but can mark a missing or unrecognized policy as PASS. Read the policy yourself and follow your provider's staged rollout rather than treating the badge as proof.

The working loop: run the scan, close any configuration gaps with your provider's setup steps, send a real test message and read the authentication results in its headers, then re-run the scan to confirm the records match what you intended. When the records and the real results agree, the authentication preflight is done. It covers authentication only; delivery, placement and content are separate checks.

Want us to check yours? Deliverability Audit.

More on this: The Deliverability Fix Kit, The Deliverability Playbook.