SPF, DKIM, and DMARC: An Email Authentication Guide for Testers

Authentication is the part of email that most testers encounter only when something goes wrong. A message that should land in the inbox instead goes to spam, and the root cause turns out to be a DNS record that nobody updated. SPF, DKIM, and DMARC are the three checks that receiving servers run to decide whether a message from your domain is trustworthy. Understanding them makes email bugs far easier to diagnose.

This guide explains what each mechanism does, how they depend on one another, and how to verify them during testing.

SPF: Authorizing Sending Servers

Sender Policy Framework (SPF) is a DNS record that lists the servers allowed to send email on behalf of your domain. When a receiving server gets mail claiming to be from app.example.com, it checks the connecting server's IP address against the domain's SPF record. If the IP is listed, SPF passes. If not, it fails.

An SPF record lives in a TXT record and follows a simple structure:

v=spf1 include:_spf.mailprovider.com ip4:203.0.113.10 -all

The parts break down like this:

• v=spf1 identifies the record type.
• include: pulls in the authorized servers from another domain, often your email provider.
• ip4: authorizes a specific IP address.
• -all says that any server not listed should be rejected (a hard fail). ~all is a softer fail that marks the message as suspicious.

A common testing mistake is forgetting to add a new sending service to the SPF record. The message sends fine, but it fails authentication at the receiver.

DKIM: Verifying Message Integrity

DomainKeys Identified Mail (DKIM) adds a cryptographic signature to each outgoing message. The sending server signs selected headers and the body with a private key, and publishes the matching public key in DNS. The receiver looks up the public key, verifies the signature, and confirms two things: that the message really came from the domain, and that it was not altered in transit.

DKIM keys are tied to a selector, which appears in the DNS record name:

# Publish the public key under a selector, e.g. "mail"
dig +short TXT mail._domainkey.example.com
# v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4...

Because signing happens per message, DKIM is more resilient than SPF when mail is forwarded. However, if a forwarding service modifies the message body, the signature can break, which is why some legitimate forwarded mail fails DKIM.

When DKIM Breaks

Signatures fail when the message content changes after signing or when the DNS key is misconfigured. Watch for:

• A key that was rotated but not republished in DNS.
• A selector mismatch between the sending configuration and the DNS record.
• A mailing list or forwarder that rewrites the subject line or appends a footer.
• Content filters in your own pipeline modifying the message before it is sent.

DMARC: Setting and Enforcing Policy

Domain-based Message Authentication, Reporting, and Conformance (DMARC) builds on top of SPF and DKIM. It tells receivers what to do when a message fails both checks and, crucially, it enforces alignment: the domain in the visible From header must match the domain that passed SPF or DKIM.

A DMARC record is published in DNS and looks like this:

v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100

The key fields are:

• p= sets the policy: none (monitor only), quarantine (send to spam), or reject (block).
• rua= specifies where aggregate reports are sent.
• pct= sets the percentage of messages the policy applies to.

DMARC is also what protects your domain from spoofing. Without it, an attacker can send mail that looks like it comes from your domain and there is no instruction telling receivers to reject it.

How the Three Work Together

The mechanisms form a chain. SPF validates the sending server. DKIM validates the message itself. DMARC ties the two to the domain the recipient actually sees and defines consequences for failure. A message generally needs to pass SPF or DKIM and satisfy DMARC alignment to reach the inbox reliably.

That interplay matters during testing. A pass on SPF alone is not sufficient if DKIM fails and DMARC alignment cannot be satisfied. Always read the full authentication result from the receiving server.

Reading Authentication-Results

The receiving server records its verdict in the message headers. Send a test message to a Public Inbox and inspect the source:

Authentication-Results: mx.example.com;
  spf=pass smtp.mailfrom=app.example.com;
  dkim=pass header.d=app.example.com;
  dmarc=pass (p=REJECT) header.from=app.example.com

All three passing is the goal. If one shows fail or none, correct that record before investigating anything else.

Testing Authentication in Practice

A repeatable routine keeps this manageable:

1. Send a real message from the application to a disposable inbox.
2. Inspect the raw headers and confirm SPF, DKIM, and DMARC results.
3. If a check fails, query the relevant DNS record directly with dig or nslookup.
4. Fix the record, allow for DNS propagation, and resend.
5. Automate the check so regressions are caught early.

Mail4QA makes the first two steps painless because any address you choose can receive mail. Teams running automated suites can poll a specific message through the Public Mailbox API and assert on its authentication headers as part of a CI pipeline.

Conclusion

SPF, DKIM, and DMARC divide the authentication job cleanly: authorize senders, protect message integrity, and enforce policy. Tester-friendly tools make each check verifiable in minutes. Send test mail to a Mail4QA inbox, read the authentication results in the raw headers, and fix DNS records before they become deliverability incidents.