How email authentication works: SPF, DKIM and DMARC explained with real records

The problem: anyone can write From#

SMTP, the protocol mail servers speak, was designed in 1982 for a network where everyone trusted everyone. Nothing in it stops a server from claiming to send as billing@yourbank.com. Three later standards, all published as DNS records by the domain owner, close that gap. Each answers one question:

• SPF: is this server allowed to send mail for this domain?
• DKIM: was this message signed by the domain, and has it been changed since?
• DMARC: does either of those checks actually vouch for the domain in the From address the reader sees, and what should happen if not?

Since 2024, Gmail and Yahoo require SPF or DKIM from everyone and all three from bulk senders, so these records are no longer optional for an app that sends email.

The records for one domain#

When you add acme.com to Sukhovei Mail, it generates this plan. These are the real values from our DNS planner, with the DKIM key shortened:

Here is what each one does, in the order a receiving server uses them.

SPF: who may send#

Every SMTP conversation starts with an envelope: MAIL FROM, the address bounces go back to, also called the return path. It is not the From line you see in your mail app. The receiving server takes the domain of the envelope sender, fetches its SPF record and checks whether the connecting IP address is on the list.

bounce.acme.com.  TXT  "v=spf1 include:amazonses.com ~all"

• v=spf1 marks the record as SPF. A domain must have exactly one; two SPF records is an error and fails every check.
• include:amazonses.com authorises Amazon SES to send for this custom return-path domain.
• ~all is the soft-fail policy AWS specifies for a custom MAIL FROM domain; SES is the only service that should send with this return path.

Keep the root SPF record separate

Most domains already have an SPF record for Google Workspace, a CRM or a newsletter tool. Sukhovei Mail does not add itself to that root record because SES uses bounce.acme.com as the envelope sender. Leave the root SPF record with the services that actually send with a root-domain return path:

acme.com.         TXT  "v=spf1 include:_spf.google.com ~all"
bounce.acme.com.  TXT  "v=spf1 include:amazonses.com ~all"

Sukhovei Mail sends through SES with an envelope sender under bounce.acme.com. The TXT record above makes SPF pass, while bounce.acme.com MX 10 feedback-smtp.us-east-1.amazonses.com routes bounces to SES. SES publishes delivery, bounce and complaint events back to Sukhovei Mail, which updates per-recipient status and suppressions.

DKIM: was it changed#

SPF says nothing about the message itself, and it breaks when mail is forwarded, because the forwarding server's IP is not on your list. DKIM fills that gap with a signature. Before sending, Amazon SES hashes the body and a list of headers and signs the result with the BYODKIM key Sukhovei Mail registered for your domain. The signature travels in a header:

DKIM-Signature: v=1; a=rsa-sha256; d=acme.com; s=mb1;
        h=From:To:Subject:Date:Message-ID:...;
        bh=<hash of the body>; b=<the signature>

The receiver reads d= (the signing domain) and s= (the selector), fetches the public key from mb1._domainkey.acme.com, and verifies. If anyone changed a signed header or a byte of the body on the way, verification fails.

• Each domain gets its own 2048 bit RSA key. Sukhovei Mail encrypts the private half at rest and registers it with SES for signing.
• The selector is why two providers can coexist: Google signs with google._domainkey, Sukhovei Mail with mb1._domainkey, and both records sit side by side.
• We sign with d= set to the domain in your From address, which matters for the next step.

DMARC: tie it to the From#

Here is the gap the first two leave. A spammer can send from their own server with their own envelope domain and their own DKIM key, pass both checks for spammer.example, and still put From: you@acme.com in the message. DMARC closes it by requiring that a passing check is for the same domain the reader sees.

_dmarc.acme.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@mailbay.dev"

• p= is the policy for mail that fails: none (deliver and report), quarantine (spam folder) or reject.
• rua= is where receivers send daily aggregate reports: which IPs sent as your domain, and whether they passed.

Sukhovei Mail starts new domains at p=none, so turning on DMARC never blocks your own mail while you find every service that sends as you. When the reports show only mail you recognise, move to quarantine, then reject. If your domain already has a DMARC record, we keep your policy and add our address next to your existing rua. A domain that publishes p=reject; rua=mailto:reports@example.net ends up with p=reject; rua=mailto:reports@example.net,mailto:dmarc@mailbay.dev.

Alignment, the part people miss#

DMARC passes when at least one of SPF and DKIM passes and is aligned: its domain matches the From domain. By default alignment is relaxed, which means the same organisational domain is enough, so bounce.acme.com aligns with acme.com. Strict alignment (aspf=s, adkim=s) needs an exact match.

This is why a common setup fails in confusing ways: SPF passes, DKIM passes, and DMARC still fails, because the service signed with its own domain and used its own envelope domain. Neither check was about you. With Sukhovei Mail, DKIM aligns after SES verifies the identity, and SPF aligns after the custom MAIL FROM records are published, so DMARC can still pass when one check breaks, such as SPF after forwarding.

MX and the return path#

The two MX records are not about authentication. They tell other servers where to deliver mail for your domain: the lower number is tried first. If your domain already receives mail at Google or iCloud, Sukhovei Mail suggests putting its MX on mail.acme.com instead, so your existing mail keeps flowing; see support@ on your own domain.

Check your own domain#

Any terminal can show you what the world sees:

dig +short TXT acme.com                    # SPF (and other TXT records)
dig +short TXT mb1._domainkey.acme.com     # DKIM public key
dig +short TXT _dmarc.acme.com             # DMARC policy
dig +short MX acme.com                     # where mail is delivered

mailbay domain verify acme.com             # every record, live; exits 1 until all pass

DNS shows what you published, not what receivers decide. To see that, send one real message to our free email deliverability test: it runs SPF, DKIM and DMARC on it as a receiving server does, counts your SPF lookups, and gives the exact fix for anything that fails.

For mail you receive, Sukhovei Mail runs the same three checks and stores the results on each message as auth_results, so an agent can refuse to act on a “reset your password” email whose DMARC failed. The record by record setup is in the Domains docs.