Key takeaways

  • SPF (RFC 7208): Publishes the list of IP addresses and sending services authorized to send mail using your domain in the envelope sender (Return-Path).
  • DKIM (RFC 6376): Uses an asymmetric key pair to add a cryptographic signature to each message, proving it was authorized by the signing domain and was not altered in transit.
  • DMARC (RFC 7489): Tells receiving servers how to handle mail that fails SPF and DKIM alignment (none, quarantine, or reject) and where to send aggregate reports.
  • Since February 2024, Gmail and Yahoo require bulk senders (Gmail defines this as 5,000+ messages per day to personal Gmail accounts) to authenticate with both SPF and DKIM, publish a DMARC record (at least p=none), and align the From domain with SPF or DKIM.

When a receiving mail server such as Google Workspace, Microsoft 365, or Yahoo Mail accepts a message from contact@yourcompany.com, its filtering stack runs a series of technical checks to decide whether the message really comes from the legitimate owner of that domain or is a spoofing or phishing attempt.

If your domain is missing the required authentication records in DNS (Domain Name System), the message is treated as high risk. It will likely land in the spam folder or be rejected outright at the SMTP level, which your sending platform records as a bounce.

1. The three core email authentication mechanisms

To understand how email security systems work together, it helps to look at the distinct but complementary role each protocol plays:

SPF (Sender Policy Framework)

SPF works like a public allowlist published in your DNS. The record declares which servers, identified by IP address or by an include mechanism pointing to a provider such as Amazon SES, SendGrid, or Mailgun, are permitted to send mail on behalf of your domain. Receivers check SPF against the envelope sender (MAIL FROM / Return-Path) domain, not the visible From address.

DKIM (DomainKeys Identified Mail)

DKIM verifies message integrity. When a message leaves the sending server, a digital signature is generated with a private key and added to the message as a DKIM-Signature header. The receiving server retrieves the matching public key from your DNS and uses it to verify the signature, confirming that the signed headers and body were not forged or modified along the way.

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

DMARC is the layer that ties SPF and DKIM together. It requires the receiving server to check whether the domain in the visible sender address (the Header From) matches the domain authenticated by SPF or DKIM, a check known as alignment. A message passes DMARC if at least one of the two passes and is aligned. DMARC also defines what the receiver should do when authentication fails and provides a channel for aggregate reports (RUA).

2. SPF record structure and syntax

An SPF record is published as a TXT record on the domain used in the envelope sender. For mail sent from your own servers or from Google Workspace, that is usually the root domain:

Record Type: TXT
Host / Name: @ (or yourcompany.com)
Value / Content: v=spf1 include:amazonses.com ~all

What each part of the record means:

  • v=spf1: Declares the SPF version in use. It must be the first term in the record.
  • include:amazonses.com: Authorizes Amazon Simple Email Service (SES) sending IP ranges to send mail for the domain. If you also use SendGrid, the equivalent is include:sendgrid.net. Note that with Amazon SES, SPF only aligns for DMARC when you configure a custom MAIL FROM subdomain (for example, bounce.yourcompany.com) and publish this record on that subdomain along with the MX record SES provides. With SendGrid domain authentication and automated security enabled, SendGrid manages SPF for its return-path subdomain through a CNAME, so a root-level include is not required.
  • ~all (SoftFail): Indicates that mail from servers not on the list should be treated as suspicious but generally still accepted. This is the most common choice, especially while you are still inventorying your sending sources.
  • -all (HardFail): Indicates that mail from unauthorized sources should be treated as a definitive failure. Receivers may reject it, although many large mailbox providers now weigh the DMARC result instead of rejecting on SPF alone.
Important technical note: Under RFC 7208, a domain must publish only one SPF record; multiple records cause a permanent error (permerror). Evaluation is also capped at 10 DNS lookups (counting include, a, mx, ptr, exists, and redirect, including nested lookups). If several services send from the same domain (for example, Google Workspace and Amazon SES), combine them into a single record: v=spf1 include:_spf.google.com include:amazonses.com ~all.

3. Setting up DKIM

DKIM setup typically involves generating an RSA key pair, with 2048-bit keys as the current recommended minimum. When you connect a sending provider through eMailBase:

  1. The provider generates the DNS records for its DKIM selectors. Amazon SES Easy DKIM issues three CNAME records in the form <token>._domainkey.yourcompany.com; SendGrid issues two DKIM CNAME records (s1._domainkey and s2._domainkey) plus one for its return-path subdomain; Mailgun typically provides a TXT record containing the public key.
  2. Sign in to your DNS provider's control panel and create each record exactly as issued.
  3. eMailBase automatically queries DNS and confirms activation once the records have propagated.

4. Rolling out DMARC enforcement safely

Publishing a strict DMARC policy on day one can cause legitimate mail to be rejected if any sending source is not yet fully covered by SPF or DKIM. The DMARC record is published as a TXT record at _dmarc.yourcompany.com, and the standard rollout has three phases:

Phase Policy syntax Operational goal
Phase 1: Monitor v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com Collect aggregate reports and identify every legitimate sending source without affecting delivery.
Phase 2: Quarantine v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@yourcompany.com Apply the quarantine policy (typically delivery to spam) to 25% of failing messages, then raise the percentage as reports confirm legitimate mail is passing. Receiver support for pct varies, and the DMARCbis revision of the standard drops it.
Phase 3: Reject v=DMARC1; p=reject; rua=mailto:dmarc@yourcompany.com Instruct receivers to reject all mail that fails DMARC, blocking unauthorized use of your domain.

5. Verifying and troubleshooting your DNS records

Once the records are in place, you can check them with standard command-line tools:

# Check the SPF record
dig +short TXT yourcompany.com

# Check a DKIM record (replace the selector with your own)
dig +short CNAME selector._domainkey.yourcompany.com

# Check the DMARC record
dig +short TXT _dmarc.yourcompany.com

In an eMailBase workspace, these checks run automatically through the DNS & Deliverability Manager, which flags syntax conflicts and missing records as soon as they appear.

Learn more about responsible sending in the eMailBase Anti-Spam Policy.