SPF, DKIM, DMARC for transactional email, explained for developers

Short Answer

Use all three. SPF authorizes sending servers, DKIM signs the message, and DMARC tells receivers how to evaluate mail that claims to come from your visible From domain.

For transactional email, the practical target is simple: a real OTP, password reset, receipt, or account alert should pass DKIM, pass SPF where possible, and pass DMARC alignment for the domain users recognize.

The Records At A Glance

SPF

TXT record at the envelope sender domain. Lists the services allowed to send mail for that domain.

DKIM

TXT or CNAME record at a selector under _domainkey. Lets receivers verify a message signature.

DMARC

TXT record at _dmarc. Requires SPF or DKIM to align with the visible From: domain.

MX

Not an authentication record, but receivers and tools often check it because it proves the domain can receive mail.

SPF Record

SPF is a TXT record that says which hosts are allowed to send mail using a domain in the SMTP envelope. Your email provider will give you the exact include value.

Name:  @
Type:  TXT
Value: v=spf1 include:spf.provider.example -all

Publish exactly one SPF TXT record per domain.
Include every provider that sends mail for that envelope domain.
Keep SPF DNS lookups within the limit enforced by SPF evaluators.
Use ~all during migration if you are still discovering senders; move toward -all when confident.
Remember that SPF checks the envelope sender, not necessarily the visible From: address.

DKIM Record

DKIM signs the message. The sender adds a DKIM-Signature header, and the receiver looks up the public key in DNS using a selector.

Name:  selector1._domainkey
Type:  CNAME
Value: selector1-yourdomain.provider.example

# Some providers use TXT instead:
Name:  selector1._domainkey
Type:  TXT
Value: v=DKIM1; k=rsa; p=PUBLIC_KEY_HERE

Use the selector and target your provider gives you.
Prefer 2048-bit DKIM keys when supported.
Rotate DKIM keys by adding a new selector before removing the old one.
Make sure the DKIM signing domain aligns with the visible From domain or its organizational domain.

DMARC Record

DMARC is the policy layer. It evaluates whether the message authenticated with SPF or DKIM and whether the authenticating domain aligns with the visible From: domain.

Name:  _dmarc
Type:  TXT
Value: v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r

Start with p=none so you can monitor without rejecting real mail.
Add rua to receive aggregate reports.
Use relaxed alignment unless you have a reason to require exact subdomain matches.
Move to p=quarantine, then p=reject, after all legitimate senders pass.
Do not publish DMARC and ignore reports; the reports are how you find forgotten senders.

Alignment Is The Part People Miss

A message can pass SPF or DKIM and still fail DMARC if the authenticated domain does not align with the domain users see in the From header.

From:        [email protected]
SPF domain:  bounce.provider.example
DKIM domain: auth.example.com

DMARC result:
  SPF alignment:  fail
  DKIM alignment: pass
  Overall:        pass

You do not need both SPF and DKIM alignment to pass DMARC. You need at least one aligned pass. For transactional systems, configure DKIM on your own domain or transactional subdomain so forwarded mail has a better chance of staying authenticated.

Safe Deployment Order

Inventory every service that sends mail as your domain.
Add or fix SPF for the envelope sender domain.
Enable DKIM signing for the transactional sender domain.
Publish DMARC with p=none and a working aggregate report mailbox.
Send test messages to Gmail, Yahoo, Outlook, and your own corporate inboxes.
Inspect delivered headers for SPF, DKIM, DMARC, and alignment results.
Watch reports and bounce logs for at least one normal traffic cycle.
Tighten DMARC policy once legitimate sources are accounted for.

Transactional Email Defaults

OTPs, password resets, receipts, invoices, and account alerts should be treated as operational infrastructure. Use a sender identity that is stable, authenticated, and separate from marketing.

Use a clear From address, such as [email protected] or [email protected].
Use a dedicated transactional stream or subdomain when your provider supports it.
Do not include promotions inside security or verification messages.
Log provider responses, bounces, suppressions, and rate-limit errors.
Include both HTML and plain text versions of every message.

How To Verify It Worked

DNS lookup tools only tell you what is published. The final check is a delivered message header because it shows how a receiver evaluated that exact message.

Authentication-Results:
  spf=pass smtp.mailfrom=bounces.auth.example.com;
  dkim=pass header.d=auth.example.com;
  dmarc=pass header.from=example.com;

If you see dmarc=fail, do not guess. Compare the visible From domain, SPF mail-from domain, and DKIM header.d domain. The mismatch is usually there.

Official References

Check your setup

Validate the records before you ship the OTP flow.

Use the free sendotp.email checker to inspect SPF, DKIM selectors, DMARC, MX, and sender-requirement gaps for your transactional domain.

Open the free DNS checker Debug OTP spam placement

FAQ

What DNS records do I need for transactional email?

At minimum, publish SPF or DKIM for the sending domain. In practice, use SPF, DKIM, and DMARC together so receivers can authenticate the message and check alignment with the visible From domain.

Where do I publish a DMARC record?

Publish DMARC as a TXT record at _dmarc.yourdomain.com. Start with p=none while you confirm all legitimate senders pass alignment, then move to quarantine or reject when you are confident.

Should transactional email use p=none forever?

No. p=none is useful for monitoring and setup. Once all legitimate sources are authenticated and aligned, move toward quarantine or reject to protect the domain from spoofing.

Is DKIM better than SPF for transactional email?

They solve different problems. SPF authorizes sending infrastructure for the envelope domain. DKIM signs the message with a domain. DMARC can pass if either SPF or DKIM passes and aligns, but DKIM often survives forwarding better.