SPF, DKIM and DMARC: Email Authentication for Application Senders

If your application sends email (sign-up confirmations, password resets, invoices, alerts), mailbox providers decide whether to trust it largely on three DNS-based standards: SPF, DKIM and DMARC. This guide explains how SPF, DKIM and DMARC work together, what records to publish, and how to roll out a DMARC policy without breaking legitimate mail.

Why application senders need all three #

Email’s original protocol, SMTP, lets any server claim to send mail from any domain. The three standards close that gap in different ways:

Since 2024, Google and Yahoo have required bulk senders to authenticate with SPF and DKIM and to publish a DMARC record, and other large mailbox providers have moved in the same direction. Even for low-volume senders, missing authentication is one of the most common reasons transactional mail lands in spam.

SPF: authorizing sending servers #

SPF (Sender Policy Framework) is a TXT record that lists the servers permitted to send mail for a domain. The receiving server checks the domain in the SMTP envelope sender (also called the Return-Path or MAIL FROM), not the From address the user sees.

Anatomy of an SPF record

A typical record for a domain that sends through Google Workspace and an email service might look like:

v=spf1 include:_spf.google.com include:spf.example-esp.com ~all

• v=spf1 identifies the record as SPF. There must be only one SPF record per domain name.
• include: pulls in another domain’s SPF policy, which is how you authorize a provider’s servers.
• ip4: and ip6: authorize specific addresses, useful for your own servers.
• ~all (softfail) or -all (fail) says what to do with everything else.

Common SPF mistakes

• Two SPF records on the same name. This causes a permanent error; merge them into one.
• Exceeding the 10 DNS lookup limit. Each include, a, mx and redirect counts, including nested lookups. Too many and SPF evaluation fails. Remove services you no longer use.
• Forgetting that SPF breaks on forwarding. When a message is forwarded, the forwarding server is not in your SPF record. That is one reason DKIM matters.

DKIM: signing each message #

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to each message’s headers. The sending service signs with a private key; you publish the matching public key in DNS. The receiver fetches the key and verifies that the signed headers and body were not altered.

Selectors and keys

The public key lives at <selector>._domainkey.yourdomain. The selector is a label, so one domain can have several keys at once, for example one per sending service. Many providers hand you CNAME records that point to keys they host and rotate for you; Amazon SES Easy DKIM works this way.

Use 2048-bit RSA keys where your DNS provider supports the longer record. If you manage keys yourself, rotate them periodically by publishing a new selector, switching signing to it, and removing the old one after messages in flight have been delivered.

The detail that matters: the d= domain

Every DKIM signature includes a d= tag naming the signing domain. Some services sign with their own domain by default. That signature passes DKIM, but it does not help your DMARC result, because DMARC needs the signing domain to match your From domain. Always set up custom domain signing with each service you use.

DMARC: alignment, policy and reports #

DMARC (Domain-based Message Authentication, Reporting and Conformance) ties SPF and DKIM to the domain your recipients actually see in the From header. A message passes DMARC if either of these is true:

• SPF passes and the envelope sender domain aligns with the From domain, or
• DKIM passes and the d= signing domain aligns with the From domain.

“Aligns” means the domains match exactly (strict) or share the same organizational domain (relaxed, the default). With relaxed alignment, mail.example.com aligns with example.com.

A DMARC record explained

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r

• p= is the policy for failing mail: none (monitor only), quarantine (treat as suspicious, usually spam folder) or reject (refuse).
• rua= is where receivers send daily aggregate reports in XML.
• adkim and aspf set relaxed (r) or strict (s) alignment.
• pct= optionally applies the policy to a percentage of failing mail during rollout.
• sp= optionally sets a different policy for subdomains.

A safe rollout plan #

Jumping straight to p=reject is the classic way to block your own invoices. Work through these stages instead.

1. Inventory every sender. List every system that sends as your domain: your app, your email service, office mail, CRM, helpdesk, billing platform, monitoring alerts. Teams usually find one or two they forgot.
2. Set up SPF and aligned DKIM for each. Prefer DKIM with custom domain signing, since it survives forwarding.
3. Publish DMARC at p=none with a rua address, and collect reports for a few weeks. Use a DMARC report processing tool to make the XML readable.
4. Fix failures the reports reveal: unknown senders you do own, missing DKIM, misaligned envelope domains.
5. Move to p=quarantine, optionally with a low pct that you increase over time.
6. Move to p=reject once reports show legitimate mail consistently passing.

Provider-specific notes #

Amazon SES

Verify your domain with Easy DKIM (three CNAME records) and configure a custom MAIL FROM domain so SPF aligns too. Our guide to the Amazon SES sandbox and sending quotas covers the rest of setting up SES responsibly, and the Amazon SES overview summarizes the service.

Mail from your own servers

Many cloud providers, including DigitalOcean, Hetzner, Linode and AWS EC2, restrict outbound port 25 by default to prevent spam from new servers. The better architecture for most applications is to relay through an email service over an authenticated submission port or an HTTP API, which also gives you managed DKIM and bounce handling. If you do run your own mail server, you need matching forward and reverse DNS (PTR) for the sending IP, plus SPF, DKIM and DMARC as described here, and you should follow your provider’s official process for SMTP access. Our guide to choosing and setting up DigitalOcean Droplets covers one provider’s approach.

Beyond the big three #

• MTA-STS and TLS-RPT tell other servers to require TLS when delivering mail to your domain, and report failures.
• BIMI lets mailbox providers display your logo for DMARC-enforcing domains, typically requiring p=quarantine or p=reject and, for some providers, a verified mark certificate.
• List-Unsubscribe headers, including one-click unsubscribe, are expected by major providers on marketing and bulk mail.

Official and standards references #

The standards are published by the IETF at the RFC Editor: RFC 7208 (SPF), RFC 6376 (DKIM) and RFC 7489 (the original DMARC specification; the IETF has been working on an updated version, so check the RFC Editor for any successor document). The DMARC.org site hosts background material and resources, and the Amazon SES documentation explains Easy DKIM and custom MAIL FROM domains in detail.

Frequently asked questions #

Do I need SPF, DKIM and DMARC if I only send a few emails?

Yes. Mailbox providers check authentication for all senders, and unauthenticated mail is much more likely to be filtered as spam. The records are free to publish and take little time to set up.

Can I have more than one SPF record?

No. A domain name must have only one SPF record. Combine all authorized services into a single record and stay within the limit of 10 DNS lookups.

Why does DMARC fail when SPF and DKIM pass?

DMARC also requires alignment. If SPF passes for your provider’s bounce domain or DKIM is signed with the provider’s domain, neither matches your From domain. Configure a custom MAIL FROM domain and custom DKIM signing.

How quickly should I move to p=reject?

Only after aggregate reports show all legitimate sources passing consistently, which often takes several weeks. Move through p=none and p=quarantine first, increasing coverage gradually.