Skip to content

Learn

SPF, DKIM and DMARC, one record at a time

Three records in your domain's DNS tell the world that your email really comes from you. Here is what each one does, in what order to set them up, and how to tighten DMARC without losing real mail.

Why a mail server asks for proof

Anyone can type any address in the From line of an email. RFC 7208, the standard behind SPF, opens by saying that email can be forged in a number of ways. So a server that receives a message can't just believe it. It looks for proof in the DNS of the domain the message says it comes from.

DNS is a public list of facts about a domain, and any server can read it. One entry in that list is a DNS record. Three records matter for email, and each one answers a different question:

SPF
Is the server that sent this message on the domain's list of allowed senders?
DKIM
Does the message carry a signature from the domain? Google says receiving servers use DKIM to verify that the domain owner actually sent the message.
DMARC
What should a receiver do when those checks fail? Google says DMARC tells receiving servers what to do with your messages that don't pass SPF or DKIM.

SPF: who may send for your domain

An SPF record is one line of text in your domain's DNS. It lists the servers that may send mail for the domain. Google says that when a message arrives, receiving servers check the SPF record to verify that the messages came from authorized servers.

This is the record Google gives to a domain that sends only through Google Workspace. Yours will list your own provider.

example.com.  TXT  "v=spf1 include:_spf.google.com ~all"
v=spf1
Every SPF record starts with this tag.
include:
Adds another sender's list of servers. Google's page says to use it in front of each sender domain in your record.
~all
The last term. It always matches, so it sets the default for every server not on the list. The tilde makes that default a softfail, which RFC 7208 calls a weak statement that the host is probably not authorized. Google recommends this ending.
-all
The same, but the result is a fail, which the RFC calls an explicit statement that the client is not authorized. Use it only when you are sure the list is complete.

Two limits surprise many people.

DKIM: a signature on every message

DKIM puts a signature on each message. Whoever sends your mail makes it with a private key that only they hold. The receiver checks it with the matching public key, which, in the words of RFC 6376, comes from querying the signer's domain directly.

The key sits at a name built from a selector, a label the signer picks so that one domain can have several keys. RFC 6376 says all DKIM keys are stored in a subdomain named _domainkey. For the selector mail and the domain example.com, the receiver asks DNS for this name:

mail._domainkey.example.com.  TXT  "v=DKIM1; p=<public key>"

You don't make the key yourself. Your mail provider creates it and shows you the record to publish. Publish it exactly as shown, on the exact name. A key under the wrong name is a key nobody finds.

Google says that sending to personal Gmail accounts requires a DKIM key of 1024 bits or longer, and it recommends a 2048-bit key if your domain provider supports it.

DMARC: what to do when the proof fails

The From line is the address a person sees. SPF doesn't check it. It checks the address the sending server announces, the MAIL FROM or HELO identity. DKIM doesn't either, because it separates the signer from the author. DMARC closes that gap. Google says the domain in the From line must be aligned with either the SPF domain or the DKIM domain. One of the two is enough.

A DMARC record sits at _dmarc in front of your domain's name. It says what a receiver should do with a message that fails, and where to send reports about what it saw.

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"
p=none
The owner states no preference for what happens to mail that fails (in the words of RFC 9989, offers no expression of preference). Google recommends it when you start.
p=quarantine
The owner finds the failed mail suspicious: it is possible the mail is valid, although the failure creates a significant concern.
p=reject
The owner takes every failure as a clear indication that the use of the domain name is not valid.
rua=
Where receivers send aggregate reports, which can reveal mail streams that use your domain but don't pass. Some will be impostors. Some will be your own services, not set up yet.

Point rua at an address made only for reports. They come in a format RFC 9989 recommends be read by machine, and many services will read them for you.

From p=none to a stricter policy

A stricter policy means quarantine or reject. Moving there too early turns a gap in your records into lost mail. RFC 9989 explains why a record starts at none: to ensure that nothing's been missed in the initial SPF and DKIM deployments. Microsoft advises moving gradually, from none to quarantine to reject, to avoid unintended mail loss.

None of the steps below is a provider's rule. They are one way to follow that advice.

  1. Set up SPF for every service that sends as your domain, and ask your mail provider to sign with DKIM.
  2. Publish DMARC at none, with an rua address used only for reports. For now you ask receivers for nothing except their reports.
  3. Read the reports. RFC 9989 says that, depending on how often you send, it may take many months of reading reports before you are sure all your mail authenticates.
  4. Fix each legitimate service that fails. The RFC says these shortcomings must be addressed before any stricter policy.
  5. Move to quarantine and watch the reports and the replies that come in. Move to reject only when the reports stay clean.

For the sender rules, you may never need to go past none. Google's guide says a DMARC policy can be set to none, and Microsoft's rule for high-volume senders asks for at least p=none. Going further is your choice. The rules ask for the record, not for a stricter policy.

Why an app's email gets its own subdomain

Say your product sends receipts and sign-in codes, and you also do cold outreach. Providers keep a record for each sending domain. Yahoo says each IP and DKIM domain has a reputation, and tells senders not to send bulk or marketing email from the same IPs they use for the mail their product sends. If both kinds of mail share one domain, they share one reputation.

So send the app's email from a subdomain of its own, such as mail.example.com, and keep outreach off it. RFC 7208 says each SPF record is placed at the owner name it pertains to, so the subdomain needs its own. Ask your provider to sign the subdomain's mail with a key published under it, so it has a DKIM domain of its own.

DMARC takes less work. Google says that without an sp tag, subdomains inherit the DMARC policy set for the parent domain. RFC 9989 agrees, and adds that the policy applies to subdomains unless the subdomain policy is explicitly described using the sp or np tags. One record on the parent covers the subdomain until you say otherwise.

A subdomain doesn't get you out of the volume rules. Google adds up the mail from one primary domain to decide who is a bulk sender, and its own example splits sending between a domain and a subdomain and still counts one sender. For a split that holds, send outreach from a different domain.

What colding checks

colding never signs your mail and never edits your DNS. Your mail provider signs, and you publish the records. colding only reads them.

For each mailbox, it looks for an SPF record on the mailbox's own domain, and for a DMARC record on that domain or the nearest parent that has one. A DMARC record at none counts. Both must be there for the domain to pass.

DKIM never decides. DNS can't list a domain's selectors, so colding tries the names providers use most. If it finds a key, it says so. If it doesn't, it says the key is not verified, never missing, because yours may have another name.

If SPF or DMARC stays missing for 72 hours, warmup and campaigns stop using that mailbox until a check passes. A campaign whose mailboxes all fail pauses and says why. If DNS doesn't answer, nothing stops: a lookup that failed is not a verdict. Read how to inspect a mailbox's domain through the API.

colding doesn't count SPF lookups, and it doesn't notice a second SPF record. Check those two yourself each time you add a sender.

When one domain sends both an app's email and campaigns, the mailbox's page suggests a subdomain for the app's email. It is advice, and it blocks nothing.

Sources

We read these pages on October 5, 2026. They are in English. If a provider has changed its page since, the provider's page is right and this essay is out of date.

Keep reading