SPF, DKIM and DMARC: what each record does and how to set them up

What do SPF, DKIM and DMARC each check?

SPF, DKIM and DMARC are three authentication standards published as DNS records. SPF lists the servers allowed to send mail for a domain. DKIM signs each message so the receiver can verify it with a public key in DNS. DMARC checks that SPF or DKIM passed for the domain in the From address and publishes the owner's policy for failures. One detail explains most of the confusion: SPF checks the envelope sender, a return address the reader never sees, while the reader sees the From header. DMARC is the piece that connects what was checked with what the reader sees.

How does alignment tie the three together?

Alignment means the domain that passed SPF or DKIM matches the domain in the From address. A message passes DMARC when at least one of the two passes and is aligned. A message can pass SPF for a sending tool's own domain and still fail DMARC, because that domain is not yours. There are two modes, set with the aspf and adkim tags. Relaxed, the default, accepts the same organizational domain, so mail.example.com aligns with example.com. Strict needs an exact match. RFC 9989 asks domain owners to send mail that produces at least one, and preferably two, aligned identifiers, so align both SPF and DKIM and let one cover for the other.

What do SPF, DKIM and DMARC records look like?

Each record is a TXT entry in your domain's DNS. The examples below use example.com and show the common shape of each record, not values to copy. Your mailbox provider and every tool that sends for you give you their own include line or DKIM key, and those replace the placeholders.

• SPF, published at example.com (example): v=spf1 include:_spf.google.com ~all. This is the value Google Workspace documents for its own servers. Every other sender adds its own include to this same record, never to a second one.
• DKIM, published at s1._domainkey.example.com (example, where s1 is the selector your provider chooses): v=DKIM1; k=rsa; p= followed by the public key the provider generates. You copy the key; you never write it.
• DMARC, published at _dmarc.example.com (example taken from RFC 9989, Appendix B): v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com. It asks receivers not to change how they treat failing mail and to send aggregate reports to that address.

In what order should you set them up?

Set up SPF and DKIM first, then publish DMARC at p=none, read the aggregate reports and tighten the policy only when they show every legitimate source passing. DMARC depends on the other two. If you publish an enforcing policy before every sender is authenticated and aligned, receivers may junk or reject your own legitimate mail.

• List every system that sends email as your domain: the mailbox provider, the CRM, billing, the support desk, the newsletter tool and any prospecting tool. Any sender missing here fails once you enforce.
• Build one SPF record that includes all of them.
• Turn on DKIM signing in each of those systems with your own domain, then publish the public keys they give you.
• Publish DMARC with p=none and a rua address. RFC 9989 calls this state Monitoring Mode.
• Move to p=quarantine, then to p=reject, once the aggregate reports show every legitimate source passing and aligned.

How do you check they work, and when do you leave p=none?

You check SPF, DKIM and DMARC in two places: the full headers of a message you sent, and the DMARC aggregate reports that receivers send to your rua address. The headers give the result for one message. The aggregate reports give results by sending source across all your mail, which shows what would break under enforcement. The reports are XML files, defined in RFC 9990, and are easier to read through a DMARC reporting tool. RFC 9989 also changes this step. RFC 7489 had a pct tag to apply the policy to a share of failing mail; RFC 9989 removes it, noting that receivers rarely applied it accurately for any value other than 0 or 100. In its place, t=y tells receivers you are testing and that you expect one level below your stated policy, so quarantine is treated as none and reject as quarantine.

What do Gmail, Yahoo and Outlook.com require?

Gmail, Yahoo and Outlook.com require SPF, DKIM and DMARC from senders of large volumes. Google and Yahoo have required it from bulk senders since February 2024, and Microsoft from high-volume senders since May 2025. All three accept a DMARC policy of p=none, provided the From domain aligns with SPF or DKIM. Meeting these rules does not guarantee the inbox: the same pages also set limits on spam complaints.

• Gmail: every sender needs SPF or DKIM and a spam rate in Postmaster Tools below 0.3%. Senders of more than 5,000 messages a day to Gmail accounts also need SPF, DKIM and DMARC, with the From domain aligned to SPF or DKIM and a policy that can be none (Google's sender guidelines).
• Gmail, continued: Google's sender guidelines FAQ says mail from the same primary domain counts toward the 5,000 threshold, that a sender who reaches it once is permanently a bulk sender, and that Gmail is ramping up enforcement from November 2025.
• Yahoo: SPF or DKIM for every sender. Bulk senders need both, a valid DMARC policy of at least p=none that passes, a From domain aligned with SPF or DKIM, and a spam rate below 0.3% (Yahoo Sender Hub).
• Outlook.com, which covers hotmail.com, live.com and outlook.com addresses: domains sending more than 5,000 emails a day must pass SPF and DKIM and publish DMARC at p=none or stricter, aligned with SPF or DKIM and preferably both. Microsoft's announcement, updated on 29 April 2025, sets enforcement from 5 May 2025 and gives the rejection code 550 5.7.515.

What are the most common SPF, DKIM and DMARC mistakes?

The mistakes that break SPF, DKIM and DMARC are few and specific: two SPF records on one domain, an SPF record that needs too many DNS lookups, a sending tool left out of SPF, DKIM signed with the vendor's domain instead of yours, weak DKIM keys, and an enforcing DMARC policy published before anyone read the reports. Each has a direct fix.

• Two SPF records, or one with too many lookups. RFC 7208 says a domain must not publish more than one SPF record and caps evaluation at 10 DNS lookups from include, a, mx, ptr, exists and redirect. Past either limit the result is a permanent error and SPF cannot pass. Merge records and drop unused includes.
• A sending tool left out of SPF. Every service that sends as your domain needs its include in the single record.
• DKIM signed with the vendor's domain. A tool that signs with its own domain produces a DKIM pass that does not align with your From address. Set up custom DKIM with your domain in each tool.
• Weak or outdated DKIM keys. RFC 8301 requires RSA keys of at least 1024 bits, recommends 2048, and says rsa-sha1 must not be used for signing or verifying.
• Enforcing too early. Jumping to p=reject before the reports show every legitimate source aligned asks receivers to refuse your own invoices, password resets and support replies.

What changes when you send prospecting email?

Prospecting email uses the same three records with two extra points. Every outreach tool you connect has to be in SPF and sign DKIM with your domain. Many teams also send prospecting from a separate domain so its reputation stays apart from the main one. That is common practice, not a rule, and it guarantees nothing. A separate domain needs its own SPF, DKIM and DMARC, because DMARC is evaluated against the domain in each message's From address. Authentication does not make an email welcome: list quality, relevance and a working opt-out still decide how it is received. For the channel itself, start with what cold email is and how it works, and for the controls to put in place before automating it, read automated B2B cold email. If you would rather not build and maintain the domains yourself, a cold email agency can run that part. Ace Digital's booked meetings service is one option: it includes separate domains and mailboxes, warmed up for weeks before they write to anyone.