SPF, DKIM and DMARC explained for founders

What the three email authentication records actually check, why a sending tool asks for all of them, and the order to set them up in without breaking the mail you already send.

The Pombo team ·

Every email tool you sign up for eventually hands you a list of DNS records and asks you to paste them in. Most founders do exactly that, see a green tick, and never think about it again. That works until it doesn't: a second tool starts sending from the same domain, someone edits the SPF record, or Gmail quietly starts filing your onboarding emails under spam and nobody can say why.

The three records are not complicated once you know what each one is checking. This is the version we wish someone had given us, written for people who own a domain and a product, not a mail server.

Why this stopped being optional

For years you could send email with none of this set up and most of it would arrive. That changed in February 2024, when Gmail and Yahoo started enforcing rules for anyone sending in bulk to their users (Gmail counts that as more than 5,000 messages a day). Bulk senders now need:

  • SPF and DKIM both set up for the sending domain.
  • A DMARC record, even if its policy is only p=none.
  • The visible From address aligned with SPF or DKIM (more on alignment below).
  • One-click unsubscribe on marketing email.
  • A spam complaint rate that stays under 0.3%.

Microsoft brought in similar requirements for Outlook.com in 2025. Even if you are nowhere near 5,000 a day, the same checks feed into how every mailbox provider scores your mail. Authentication is the entry ticket. It does not get you into the inbox on its own, but without it you are not in the running.

The one-line version

Each record answers a different question a mailbox provider asks about your email:

  • SPF: is this server allowed to send for this domain?
  • DKIM: was this message really signed by this domain, and has it been changed since?
  • DMARC: do those checks match the address the reader actually sees, and what should happen if they don't?

SPF and DKIM are the evidence. DMARC is the rule that says how to judge it.

SPF: the list of allowed senders

SPF is a single TXT record on your domain that lists the servers permitted to send mail for it. It looks like this:

v=spf1 include:_spf.google.com include:amazonses.com ~all

Read left to right, that says: Google Workspace may send for this domain, Amazon SES may send for this domain, and anything else should be treated with suspicion (~all, a soft fail). The stricter -all means "reject anything else".

Three things trip people up.

You only get one SPF record. Two TXT records that both start with v=spf1 is an error, and providers treat it as if you had none. When you add a new sending tool, you add its include: to the record you already have. You do not paste in a second record.

There is a limit of ten DNS lookups. Every include: can pull in more lookups behind it. Stack up a CRM, a support desk, a billing tool and two email platforms and you can pass ten without noticing, at which point SPF fails for all of them. Remove includes for tools you no longer use.

SPF does not check the address people see. It checks the envelope sender, the hidden return address that bounces go to. When you send through an email platform, that address usually belongs to the platform, not to you. So SPF can pass while telling the receiver nothing about your domain. That gap is what DMARC alignment exists to close, and why good sending tools ask you to set up a custom return address on your own domain (often called a custom MAIL FROM).

DKIM: a signature on every message

DKIM signs each outgoing email with a private key. The matching public key lives in your DNS, and the receiving server uses it to check two things: that the message was signed by your domain, and that nobody changed it on the way.

Most email platforms set DKIM up with CNAME records rather than a raw key. A CNAME points a name on your domain (something like abc123._domainkey.mail.yourcompany.com) at a key the platform hosts. That way the platform can rotate its keys without you ever touching DNS again. Amazon SES, which Pombo sends through, uses three of these.

DKIM is the sturdier of the two checks. It survives most forwarding, where SPF breaks because the forwarding server is not on your list. If you only get one record right, make it DKIM.

DMARC: the rule that ties it together

DMARC is a TXT record at _dmarc.yourdomain.com. It does two jobs.

First, it adds alignment. A message passes DMARC only if SPF or DKIM passes for a domain that matches the one in the visible From address. Your email platform's own SPF passing is not enough; it has to pass for you.

Second, it sets a policy for mail that fails:

  • p=none: deliver it as normal, but send me reports. This is monitoring mode.
  • p=quarantine: treat failures as suspicious, usually meaning the spam folder.
  • p=reject: refuse failures outright.

A typical record looks like this:

v=DMARC1; p=none; rua=mailto:[email protected]

The rua address is where mailbox providers send daily aggregate reports: which servers sent mail claiming to be you, and whether it passed. They arrive as XML attachments, so most people point them at a mailbox they check occasionally or at a free report-reading service. Make sure the address actually exists, or the reports go nowhere.

Alignment, with an example

Say you send an onboarding email from [email protected] through an email platform.

  • DKIM signs it as mail.yourcompany.com. That matches the From address, so DKIM is aligned.
  • The envelope sender is [email protected]. SPF passes for the platform's domain, but that does not match your From address, so SPF is not aligned.

DMARC passes, because it only needs one of the two to pass and align. Set up a custom MAIL FROM on your own domain and SPF lines up as well, which gives you a second way to pass if DKIM ever breaks.

Send from a subdomain

Put your product and marketing email on a dedicated subdomain like mail.yourcompany.com or send.yourcompany.com, and leave your root domain to people's own mail from Google Workspace or Microsoft 365.

It costs nothing and it buys you two things. A reputation problem on a marketing send stays on the subdomain instead of dragging down the email your team sends one to one. And you can set a strict DMARC policy on the sending subdomain from day one, because nothing else sends from it, while your root domain stays on p=none until you have seen the reports and know every tool that sends as you.

The order to set it up in

  1. Pick the sending subdomain and add it to your email platform.
  2. Add the DKIM records it gives you. These are the ones that matter most.
  3. Add the custom MAIL FROM records if your platform offers them (an MX and a TXT on a return-path subdomain), so SPF aligns too.
  4. Update SPF. Add the platform's include: to your existing record, or create one if the domain has none. Never create a second record.
  5. Add DMARC. Use p=none on your root domain while you learn who sends as you. A dedicated sending subdomain can start stricter.
  6. Check a real message. Send yourself an email in Gmail, open the menu on the message and choose Show original. You want PASS next to SPF, DKIM and DMARC.
  7. Read the reports for a few weeks, then tighten the root domain's policy to quarantine and later reject once nothing legitimate is failing.

If you prefer the terminal, dig TXT _dmarc.mail.yourcompany.com and dig TXT mail.yourcompany.com show you what the world currently sees.

How Pombo handles it

When you add a domain under Settings, Domains, Pombo shows the exact records for it, and checks each one until it goes live. You get the three DKIM CNAMEs, a custom MAIL FROM on an envelope. subdomain so SPF aligns, an SPF record, and a DMARC record. If your domain already has an SPF record, Pombo gives you that record with its include: added, rather than a second one that would break both.

The suggested DMARC record starts at p=quarantine, because it is meant for a dedicated sending subdomain where nothing else sends. Its reports go to dmarc@ your domain, so create that mailbox or change the address before you add it. If you are adding your root domain instead, drop the policy to p=none until you have read a few weeks of reports.

Pombo will not send from a domain it cannot authenticate, which is annoying for the ten minutes it takes to set up and a relief every day after. The full list of records and what each one is for is in verify your sending domain, and what keeps you out of spam once they are in place is in deliverability basics.

Authentication gets you through the door. What you send, and who you send it to, decides where you land. If you are working out which of your emails should go out as marketing and which as transactional, that difference changes how they are sent too.

← More in Deliverability